Find and compare sports odds and data APIs, and read the SportsAPIs.dev review of each one.
Scored across 3 tools
Each of the three tools targets a distinct intent: shortlist by filters, side-by-side comparison of 2-4 named providers, and deep detail on one named provider. Descriptions go further by stating explicit negative boundaries (e.g., compare is not for betting odds; find is not for predictions or a specific match), leaving almost no room for misselection.
All three names follow a clean verb_noun snake_case pattern: compare_sports_apis, find_sports_apis, get_sports_api_details. The singular/plural variation (sports_apis vs sports_api) tracks the actual cardinality of the target, so it aids rather than breaks predictability.
Three tools is lean but each maps to a real developer workflow (discover, compare, inspect), so nothing is redundant. It sits at the low end of the comfortable range, though the narrow read-only directory domain justifies the small surface.
The domain is a read-only research directory, and the surface covers its core lifecycle: filtered discovery, comparison, and full per-provider detail with review text and alternatives. The notable gap is that there is no unfiltered browse/list-all tool, since find_sports_apis intentionally returns nothing when given no criteria.
Use this when a developer names two to four sports odds or sports data API providers and wants them compared, for example "The-Odds-API vs OddsPapi" or "SportsGamesOdds or SportsData.io for player props". Returns a side-by-side table of researched feature support (pregame, live, Bet365, Pinnacle, closing odds, futures, same game parlay, deeplinks, settlement, stats, schedules, WebSocket, MCP server, esports), pricing scale, free tier, sports mentioned in our reviews, the differences between them, and the SportsAPIs.dev review URL for each. Providers must be in the SportsAPIs.dev directory. Do not use this to compare betting odds or sportsbook prices for a game.
| Name | Required | Description | Default |
|---|---|---|---|
| providers | Yes | Two to four provider names as developers write them, for example ["The-Odds-API", "OddsPapi", "SportsGamesOdds"]. |
| Name | Required | Description |
|---|---|---|
| notes | No | |
| providers | Yes | |
| next_steps | No | Which tool to call for the likely follow-up questions. |
| differences | Yes | |
| shared_confirmed | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructivedHint=false and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: a hard precondition ('Providers must be in the SportsAPIs.dev directory') and an explicit non-goal about game-level odds comparison, which tells the agent what will and won't work.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the usage trigger, then the examples and the exclusion. The long enumeration of returned feature types is somewhat wasteful because an output schema already exists, but it reads as agent-matching vocabulary rather than pure repetition, so the length is mostly earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values, yet it still gives the trigger, examples, a provider-directory precondition, and a clear exclusion. For a single-parameter, fully-described schema tool this covers everything an agent needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the 3-point baseline applies, but the description adds a validation constraint not present in the schema ('Providers must be in the SportsAPIs.dev directory') and clarifies the two-to-four cardinality. That extra constraint on valid values justifies going above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (compare) and resource (sports odds/data API providers) with the exact scope ('two to four'), and the examples plus the 'side-by-side table' framing make it clearly distinct from find_sports_apis (discovery) and get_sports_api_details (single provider). An agent can disambiguate from siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit trigger ('Use this when a developer names two to four ... providers and wants them compared') plus a concrete exclusion ('Do not use this to compare betting odds or sportsbook prices for a game'). It stops short of naming the sibling alternatives (find_sports_apis / get_sports_api_details) for the excluded or single-provider cases, so it is not fully self-routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when a developer asks which sports odds API, sports data API, sportsbook odds feed, live odds API, esports odds API, player props API, or free sports API to use for an app, model, or odds comparison tool. Filters the providers researched by SportsAPIs.dev by sport, required features (live odds, WebSocket streaming, Bet365 or Pinnacle odds, historical odds, player props, stats, live scores, MCP server), free tier, price tier and region. Returns a ranked short list with a one-line reason and the SportsAPIs.dev review URL for each provider. Ranking: every feature, free tier, price and region filter must match; sport is a boost, not a filter, because sport lists come from mentions in our reviews. Featured partners of SportsAPIs.dev rank first and are labelled as featured partners. Within each group, providers whose review names the sport come first; with a free tier or price tier filter, cheaper paid plans come next. Other ties follow a daily rotation, so no provider is always first. Features the user did not ask for do not change the order. With no sport, feature, book, league, market, budget or region at all, it returns no providers and asks what the user needs. Optional books, leagues and markets filters (for example "DraftKings", "NBA", "player points") keep only providers in the SportsAPIs.dev Coverage Map that carry every requested value, so use them only when the user needs a specific book, league or market confirmed. Do not use this for betting picks, game predictions, or the odds of a specific match; it has no odds data, only facts about API providers.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | "odds" for odds and betting-market APIs, "data" for scores, stats and schedules APIs with no odds. Default "any". | |
| books | No | Sportsbooks, exchanges or prediction markets the API must carry odds from, as canonical ids or display names, case-insensitive, for example "DraftKings", "bet365" or "Kalshi". Every value must be carried for a provider to match. Only providers in the SportsAPIs.dev Coverage Map (probed with our own API keys or listed from their docs) can match, so use sport and needs for a general question: https://sportsapis.dev/odds-api-coverage | |
| limit | No | How many providers to return. Default 5. | |
| needs | No | Features the API must have. Every listed need must be confirmed for a provider to appear. | |
| sport | No | Sport or league the developer needs, for example "NFL", "soccer", "tennis", "esports", "college football", or "prediction markets" for Kalshi, Polymarket and similar venues. Boosts providers whose review names that sport; it does not exclude the rest. | |
| region | No | Bookmaker focus: "usa" for US sportsbooks and Bookmaker.eu feeds, "international" for European and Asian books including Pinnacle feeds. Default "any". | |
| leagues | No | Leagues the API must carry odds for, as canonical ids or display names, case-insensitive, for example "NBA", "EPL" or "Premier League". Every value must be carried for a provider to match. Only providers in the SportsAPIs.dev Coverage Map (probed with our own API keys or listed from their docs) can match, so use sport and needs for a general question: https://sportsapis.dev/odds-api-coverage | |
| markets | No | Bet markets the API must carry, as canonical ids or display names, case-insensitive, for example "player points", "spreads" or "anytime touchdown". Every value must be carried for a provider to match. Only providers in the SportsAPIs.dev Coverage Map (probed with our own API keys or listed from their docs) can match, so use sport and needs for a general question: https://sportsapis.dev/odds-api-coverage | |
| free_tier | No | true = only providers with a confirmed free tier or free plan. | |
| max_price_tier | No | Highest acceptable entry price tier on a 1 to 5 scale (1 = about $20/mo, 5 = $1000+/mo). Example: 2 keeps providers whose cheapest paid plan is tier 2 or lower. | |
| exclude_providers | No | Provider names already shown in this chat. Use it when the user asks for more or other options: these providers are skipped, so the result and the cards show new ones. |
| Name | Required | Description |
|---|---|---|
| notes | No | |
| results | Yes | |
| next_steps | No | Which tool to call for the likely follow-up questions. |
| directory_url | Yes | |
| total_matches | Yes | |
| filters_applied | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the readOnly/openWorld annotations: it discloses the ranking algorithm, that featured partners are promoted and labelled, that ties rotate daily, that the sport is a boost rather than a filter, that books/leagues/markets only match coverage-map providers, and that an empty query returns nothing and asks a clarifying question. These are exactly the non-obvious behaviours an agent needs to set user expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the trigger sentence and the negative boundary at the end, with ranking rules in the middle; every sentence carries information. It is on the long side and partially restates the books/leagues/markets coverage-map caveat three times, which is redundant given the schema repeats it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter, all-optional tool with an output schema, this covers trigger, exclusions, ranking, empty-result behaviour and coverage limits — nothing an agent needs in order to call it or interpret the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so 3 is the baseline; the description earns above that by explaining the interaction rules the schema cannot express — every feature/free-tier/price/region filter must match, while sport only boosts, and unrequested features never reorder results. It still leaves the semantics of exclude_providers and max_price_tier to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a concrete use case (a developer asking which sports odds/data API to use) and enumerates the query shapes it covers, so the verb and resource are unambiguous. It never names compare_sports_apis or get_sports_api_details, so the agent must infer the boundary with siblings from their own definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit negative boundary — 'Do not use this for betting picks, game predictions, or the odds of a specific match' — plus guidance to prefer sport/needs over books/leagues/markets for general questions. It does not name a sibling tool to use instead, so the when-to-use-this-vs-alternative routing is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when a developer asks about one specific sports odds or sports data API by name, for example "Is The-Odds-API free?", "Does OddsPapi have a WebSocket?", "OddsJam API pricing", or "Sportradar API review". Returns everything the SportsAPIs.dev review page records: feature support, pricing tiers from our review, free tier, sports mentioned, strengths, the full review text, FAQs, alternatives in the directory, and the review URL. The provider must be in the SportsAPIs.dev directory. Do not use this for a sportsbook, a league, or a betting question.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | Provider name or slug, for example "OddsPapi", "the odds api", "sportsdata-io". |
| Name | Required | Description |
|---|---|---|
| faqs | No | |
| name | Yes | |
| coverage | No | What the SportsAPIs.dev Coverage Map records for this provider, with the date we checked it. Null when the provider is not in the map. |
| features | Yes | |
| next_steps | No | Which tool to call for the likely follow-up questions. |
| review_url | Yes | |
| alternatives | No | |
| provider_url | Yes | |
| pricing_summary | No | |
| review_sections | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive and closed-world, and the description is consistent with that while adding real value: it enumerates the returned content and states the directory-membership constraint that determines success. It does not say what happens when a provider is missing (empty result vs. error), which is the main remaining unknown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the trigger condition, then scope, then the constraint and exclusion; almost every clause carries information. The long enumeration of returned fields is partly redundant given an output schema exists, which keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with full schema coverage, complete annotations and an output schema, the description covers what an agent needs: when to call it, what it will not answer, and the directory-membership precondition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already explains that the value is a name or slug, with its own examples. The description's example queries hint at the mapping from a user question to a provider name but add no syntax or normalization detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Returns everything the SportsAPIs.dev review page records' for one provider) and scopes it to a single named provider, which is what separates it from the directory-wide find_sports_apis and compare_sports_apis. An agent can distinguish intent without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete trigger queries ('Is The-Odds-API free?', 'OddsJam API pricing'), an explicit exclusion ('Do not use this for a sportsbook, a league, or a betting question'), and a prerequisite (provider must be in the directory). It stops short of naming its siblings as the alternative for comparison or search requests, leaving that routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_sports_apis3 fields changedInput schema / properties / booksAdded value: +{
+ "description": "Sportsbooks, exchanges or prediction markets the API must carry odds from, as canonical ids or display names, case-insensitive, for example \"DraftKings\", \"bet365\" or \"Kalshi\". Every value must be carried for a provider to match. Only providers in the SportsAPIs.dev Coverage Map (probed with our own API keys or listed from their docs) can match, so use sport and needs for a general question: https://sportsapis.dev/odds-api-coverage",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / leaguesAdded value: +{
+ "description": "Leagues the API must carry odds for, as canonical ids or display names, case-insensitive, for example \"NBA\", \"EPL\" or \"Premier League\". Every value must be carried for a provider to match. Only providers in the SportsAPIs.dev Coverage Map (probed with our own API keys or listed from their docs) can match, so use sport and needs for a general question: https://sportsapis.dev/odds-api-coverage",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / marketsAdded value: +{
+ "description": "Bet markets the API must carry, as canonical ids or display names, case-insensitive, for example \"player points\", \"spreads\" or \"anytime touchdown\". Every value must be carried for a provider to match. Only providers in the SportsAPIs.dev Coverage Map (probed with our own API keys or listed from their docs) can match, so use sport and needs for a general question: https://sportsapis.dev/odds-api-coverage",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}get_sports_api_details1 field changedOutput schema / properties / coverageAdded value: +{
+ "description": "What the SportsAPIs.dev Coverage Map records for this provider, with the date we checked it. Null when the provider is not in the map.",
+ "properties": {
+ "books": {
+ "items": {
+ "properties": {
+ "group": {
+ "description": "\"us\", \"offshore\", \"global\", \"uk-ireland\", \"europe\", \"australia-nz\", \"canada\", \"latam\", \"asia\", \"exchange\", or null for a book our book list does not map yet.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "docsCheckedOn": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "families": {
+ "items": {
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "family": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "finderUrl": {
+ "description": "The provider on the SportsAPIs.dev Coverage Map.",
+ "type": "string"
+ },
+ "lastProbe": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "leagues": {
+ "items": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "live": {
+ "type": "boolean"
+ },
+ "method": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "sport": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "liveLeagues": {
+ "description": "Leagues with live odds. Empty means not checked yet, not none.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "rawMarketCount": {
+ "description": "Markets the provider names that our market list does not map yet.",
+ "type": "integer"
+ },
+ "source": {
+ "description": "\"probe\" = checked with our own API key, \"docs\" = read from the provider docs, \"manual\" = reported by the provider.",
+ "type": "string"
+ },
+ "verifiedLabel": {
+ "description": "The checked date as a phrase, for example \"Verified 28 October 2026\".",
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+}find_sports_apis1 field changedInput schema / properties / sport / descriptionPrevious value: -"Sport or league the developer needs, for example \"NFL\", \"soccer\", \"tennis\", \"esports\", \"college football\". Boosts providers whose review names that sport; it does not exclude the rest."New value: +"Sport or league the developer needs, for example \"NFL\", \"soccer\", \"tennis\", \"esports\", \"college football\", or \"prediction markets\" for Kalshi, Polymarket and similar venues. Boosts providers whose review names that sport; it does not exclude the rest."find_sports_apis2 fields changedInput schema / properties / exclude_providersAdded value: +{
+ "description": "Provider names already shown in this chat. Use it when the user asks for more or other options: these providers are skipped, so the result and the cards show new ones.",
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 40,
+ "type": "array"
+}Output schema / properties / results / items / properties / logo_urlAdded value: +{
+ "description": "The provider's logo, from the SportsAPIs.dev directory. The cards show it.",
+ "type": [
+ "string",
+ "null"
+ ]
+}find_sports_apis1 field changedOutput schema / properties / results / items / properties / logo_urlRemoved value: -{
- "description": "The provider's logo, from the SportsAPIs.dev directory. Use this image when you show the provider's logo.",
- "type": [
- "string",
- "null"
- ]
-}compare_sports_apis1 field changedOutput schema / properties / next_stepsAdded value: +{
+ "description": "Which tool to call for the likely follow-up questions.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}find_sports_apis2 fields changedOutput schema / properties / next_stepsAdded value: +{
+ "description": "Which tool to call for the likely follow-up questions.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / results / items / properties / logo_urlAdded value: +{
+ "description": "The provider's logo, from the SportsAPIs.dev directory. Use this image when you show the provider's logo.",
+ "type": [
+ "string",
+ "null"
+ ]
+}get_sports_api_details1 field changedOutput schema / properties / next_stepsAdded value: +{
+ "description": "Which tool to call for the likely follow-up questions.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}compare_sports_apisfind_sports_apisget_sports_api_detailsSports odds, player props and source coverage for AI assistants. Connect with your own API key.
Live odds, cross-book +EV and graded player-prop results across 37 books. Hosted endpoint included.
Live sports data: scores, play-by-play, box scores, odds and props. No key needed to start.
The Odds API MCP — sportsbook odds across 70+ books, 30+ leagues
Add one secure layer between your agents and this server.
