Skip to main content
Glama
Sign In
Odds-API MCP Server

Odds-API MCP Server

Official
by odds-api-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Odds summary (best, average, fair)

get_odds_summary
Read-onlyIdempotent

Compare bookmaker prices and calculate average, median, worst, and margin-free fair odds per market line, showing bookmakers with favorable prices.

Instructions

Best, average, median, worst and margin-free fair price per market line across bookmakers, with which bookmakers have the best price. The compact way to answer 'where is the best price' or 'what is the fair price'. Pass one eventId, or up to 10 comma-separated ids (one request). Growth plan and above; lower plans get a sample response marked demo: true, which is not real data, so tell the user.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "eventId": "<eventId>"
    },
    "name": "get_odds_summary"
  }
}

Input Schema

NameRequiredDescriptionDefault
linesNomain (default): each market's main line. all: every line priced by 3+ bookmakers
eventIdYesOne event ID, or up to 10 comma-separated event IDs
marketsNoComma-separated market names, case-insensitive, max 20. Default ML,Spread,Totals
bookmakersNoOptional: restrict to some of the key's selected bookmakers
includeExchangesNoAdd a separate block with the best exchange back price per outcome and its liquidity

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.3

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds genuinely new behavioral context: Growth plan and above is required, and lower plans receive a sampled response flagged demo: true that is not real data and must be disclosed to the user. That is exactly the kind of gating and degraded-response behavior an agent cannot infer from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the returned metrics, then the use case, then the invocation form, then the plan caveat — no filler sentences. Every clause carries distinct information the agent needs before calling.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing the result and does so: the metric set per market line, bookmaker attribution for best price, and the optional exchange block via includeExchanges. Plan gating and the demo:true fallback close the remaining gap an agent would otherwise hit at call time.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so lines, markets, bookmakers and includeExchanges are already fully documented with defaults and enums. The description only adds the cost-relevant nuance that up to 10 eventIds are handled in one request; it says nothing extra about markets syntax or what includeExchanges returns beyond what the schema states, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and the exact aggregates returned: 'best, average, median, worst and margin-free fair price per market line across bookmakers', plus bookmaker attribution. The 'compact way to answer where is the best price' framing separates it from the raw per-bookmaker pricing siblings (get_odds, get_multi_odds) without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete usage contexts ('where is the best price', 'what is the fair price') and states the batching rule (one eventId, or up to 10 comma-separated in a single request) plus the plan prerequisite. It stops short of explicitly naming an alternative tool to use for raw prices or for value/arbitrage questions, so there is no true when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools