The Odds Gap

Futures Prices

futures_odds

Read-onlyIdempotent

Season-long futures such as the Super Bowl, World Series, Stanley Cup, NBA and college titles: the highest price we saw on a team, or the top of one futures market, with the scan time. Prices may have moved since the scan.

Input Schema

Name	Required	Description
`team`	No	One entrant, if they named one.
`text`	No	The person's own words. This is what names the market, because a futures market has no id anybody would ever say out loud.
`books`	No	The books this person actually has. Omit for the default set.
`sport`	No	The league, if no market is named.
`stake`	No	A stake to pay out at the best price.
`teams`	No	Two or more entrants asked together.
`market`	No	A market phrase, if it is separable from the rest of the sentence.
`compare`	No	Books the person named, to say each one's price.

Output Schema

Name	Required	Description
`ok`	Yes	True when the tool produced an answer.
`card`	No	The same answer, structured, when there is one.
`page`	Yes	The matching page on theoddsgap.com.
`tool`	No
`as_of`	No	When the prices were scanned, Eastern Time.
`stale`	No	True when that scan is older than usual for our hourly snapshot.
`answer`	Yes	The answer in plain sentences.
`options`	No	When the question could mean more than one thing: whole questions to ask again with.
`warnings`	No
`state_note`	No	Where to check what is legal for you.
`decline_kind`	No	Set when the question is one we do not answer, and which kind.
`free_left_today`	No
`responsible_gambling`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 8, 2026

addedInput schema / properties / compare

Added value: +{
+  "description": "Books the person named, to say each one's price.",
+  "type": "array"
+}

addedInput schema / properties / sport

Added value: +{
+  "description": "The league, if no market is named.",
+  "type": "string"
+}

addedInput schema / properties / stake

Added value: +{
+  "description": "A stake to pay out at the best price.",
+  "type": "number"
+}

addedInput schema / properties / teams

Added value: +{
+  "description": "Two or more entrants asked together.",
+  "type": "array"
+}

First observedOct 1, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely useful behavior beyond them: it returns the highest price seen with a scan time and warns that 'prices may have moved since the scan.' That staleness disclosure is exactly the kind of context an agent needs.

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

Conciseness4/5

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

Two tight sentences with the resource and return semantics front-loaded, and the staleness caveat placed last. No filler, though the sentence is dense enough that it reads more as one long clause than clearly separated points.

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

Completeness4/5

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

An output schema exists so return shape need not be explained, and annotations carry the safety profile. The description supplies the remaining behavioral context (scan-based pricing, potential staleness) for an 8-param tool with full schema coverage, leaving little missing.

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% and all 8 parameters are documented in the schema (team, text, books, sport, stake, teams, market, compare). The description adds no parameter syntax or format detail beyond that, so the baseline 3 applies.

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

Purpose4/5

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

The description names the specific resource (season-long futures such as Super Bowl/World Series/Stanley Cup) and the value returned (highest price on a team or top of a futures market), so an agent can distinguish it from game_lines or player_prop. It stops short of explicitly naming those siblings as alternatives.

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

Usage Guidelines3/5

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

The phrase 'season-long futures' implies the context of use, but there is no explicit when-to-use/when-not guidance and no alternative tool named, even though game_lines and player_prop are close siblings. Usage is inferable but not stated.

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

All The Odds Gap tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?