Give your agent data it can explain

“Compare this player across platforms” sounds like a single question. Underneath it are several decisions: identify the player, select the event, choose the market period, resolve the offer type, and check whether the observations are current enough to compare.

An agent should not have to invent those decisions from a pile of loosely labeled numbers. Give it a small set of well-defined tools and structured results that retain the evidence behind each answer.

Use MCP as a connection, not a source of truth

The Model Context Protocol gives AI applications a standard way to connect to servers that expose tools and context. The official architecture guide describes the roles of hosts, clients, and servers. The protocol does not determine whether a sports observation is fresh, whether two players are the same person, or whether two markets are comparable. Your data model still has to answer those questions.

Think of the MCP server as another interface over a carefully defined service. An application calling the REST API and an agent calling a tool should receive compatible identities, status definitions, and timestamps.

Give tools a narrow purpose

A tool named “get everything” leaves too many choices implicit. Prefer a sequence with bounded inputs: find a player, list relevant events, retrieve a specified market, and inspect its history. Limit result counts, support pagination, and return an explicit indication when additional pages exist.

For example, a comparison tool could require a canonical player ID, event ID, stat, and period. Its result could group observations by source while preserving the original variant. That design lets the agent explain why a row is included and when a row was excluded.

{
  "example": true,
  "query": {
    "player_id": "player_example",
    "event_id": "event_example",
    "stat": "points",
    "period": "full_game"
  },
  "observations": [],
  "status": "unavailable",
  "reason": "No verified observations for this request"
}

This is an illustrative response shape, not a live GetOdds endpoint. Its most important property is that it gives the agent a truthful next step when there is no verified answer.

Make missing data useful

Distinguish an unsupported market from a source outage, a stale observation, and a player who has no matching offer. Those conditions should produce different explanations. A model that receives only an empty list is forced to infer why it is empty.

Return readable status notes alongside stable machine-readable codes. If one source fails, keep successful observations visible with a partial-result flag. The agent can then say exactly which sources were checked instead of presenting a partial result as complete coverage.

Keep credentials and expensive work under control

Store service credentials on the server or in the client’s supported secret configuration. Do not embed a production key in a public page, a prompt example, or a generated report. Start with read-only tools for exploration, and make each tool’s parameters and scope explicit.

Bound requests and paginate intentionally. A question about one player should not trigger an unrestricted scrape of every league. Keep a record of source requests and their purpose so unexpected usage can be investigated without relying on the agent’s prose.

Return evidence with the answer

The final answer should preserve the source, market period, variant, and observation time. If the user asks for a recommendation, separate the retrieved observations from whatever reasoning or model is applied to them. A difference between two lines is an observation, not proof of a profitable opportunity.

When an agent can explain what it retrieved, when it retrieved it, and what remains unknown, the connection becomes useful beyond the first impressive demo.