The Odds Gap

Game Lines

game_lines

Read-onlyIdempotent

One game's moneyline, spread or total: both sides on the consensus number, or which side the market has as the favorite. Name the game in plain words, for example Lions at Bears. Shows the scan time and a link to the game's page. Prices may have moved since the scan.

Input Schema

Name	Required	Description
`game`	Yes	The game in plain words, for example 'Lions at Bears' or 'Yankees tonight'.
`line`	No	The spread or total the bet is at. Omit for a moneyline, or to use the consensus line.
`side`	No	home or away for a moneyline or spread; over or under for a total.
`team`	No	A known team with no game on the board.
`books`	No	The books this person actually has. Omit for the default set.
`market`	No	ml, spread or total.
`favored`	No	Who the market favors, as a price.
`markets`	No	Game-line markets to show, both sides each.

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 14, 2026

addedInput schema / properties / markets

Added value: +{
+  "description": "Game-line markets to show, both sides each.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Changed1 schema field changedOct 7, 2026

addedInput schema / properties / team

Added value: +{
+  "description": "A known team with no game on the board.",
+  "type": "string"
+}

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 declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds meaningful context beyond that: it shows the scan time and a page link, and warns that prices may have moved since the scan.

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?

Three short sentences, front-loaded with what the tool returns and followed by the input hint and the freshness caveat. Little waste, though the closing freshness note could be tighter.

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 covering return values and annotations covering safety, the description only needs to explain scope and input style, which it does. The lack of explicit routing to sibling tools is the only notable gap.

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 the schema already documents all 8 parameters, including the plain-words game format and the line/side semantics. The description's mention of 'Name the game in plain words' overlaps rather than extends the schema, so 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?

States a specific verb+resource: it returns one game's moneyline, spread, or total, both sides on the consensus number or the favored side. The 'one game's' scope implicitly distinguishes it from the slate tool but no sibling is named explicitly.

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?

'Name the game in plain words, for example Lions at Bears' gives invocation guidance, but there is no explicit when-to-use versus alternatives (e.g. slate for all games) and no exclusions. Usage is implied rather than 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?