The Odds Gap

Middles

middles

Read-onlyIdempotent

Spread and total middles across sportsbooks at the scan: two numbers far enough apart that both bets could win. Prices may have moved since the scan.

Input Schema

Name	Required	Description
`game`	No	The game in plain words, for example 'Lions at Bears' or 'Yankees tonight'.
`pick`	No	A number to put in place of one side of the last middle, for 'what if I took 144.5 instead' (prompt 194).
`text`	No	The reader's words.
`books`	No	The books this person actually has. Omit for the default set.
`stake`	No	The stake on each ticket, for hit and miss dollars.

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.

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / pick

Added value: +{
+  "description": "A number to put in place of one side of the last middle, for 'what if I took 144.5 instead' (prompt 194).",
+  "type": "string"
+}

Changed1 schema field changedOct 8, 2026

addedInput schema / properties / stake

Added value: +{
+  "description": "The stake on each ticket, for hit and miss dollars.",
+  "type": "number"
+}

First observedOct 1, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds a meaningful behavioral caveat — that prices may have moved since the scan — which is not captured by annotations or schema and matters for interpreting results.

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?

Two short sentences, front-loaded with the core concept and followed by the key freshness caveat. Every sentence adds value with no redundancy.

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?

With an output schema and annotations covering return and safety behavior, the description supplies the essential domain definition and a staleness warning. It is nearly complete for correct invocation, though it could improve by routing users relative to sibling tools.

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?

All five parameters have full schema descriptions, so the schema carries the burden of explaining game, pick, text, books, and stake. The description itself adds no additional parameter meaning, which is acceptable given 100% schema coverage but does not exceed the baseline.

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 identifies the specific resource — spread and total middles across sportsbooks — and defines what a middle is, which distinguishes it conceptually from ordinary lines or arbs. However, it lacks an explicit action verb and does not directly contrast itself with sibling tools such as arbs.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives like arbs or game_lines. The phrase 'at the scan' and the price-movement note provide context but do not tell an agent when this tool is the right choice.

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?