The Odds Gap

Team Results on The Odds Gap

team_record

Read-onlyIdempotent

A team's finished games tracked on The Odds Gap and its next game. Not an official league record.

Input Schema

Name	Required	Description	Default
`team`	Yes	The team as typed.
`text`	No	The reader's words, for an ATS, over/under or trends record.

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

addedInput schema / properties / text

Added value: +{
+  "description": "The reader's words, for an ATS, over/under or trends record.",
+  "type": "string"
+}

First observedOct 1, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds one useful piece of context—that this is not an official league record—which helps set expectations about data reliability. No other behavioral details like rate limits or auth needs are mentioned.

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?

The description is two concise, front-loaded sentences. The first sentence describes the returned content, and the second immediately disambiguates with a caveat. Every sentence earns its place with zero waste.

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?

Given a simple read-only tool with a rich output schema and comprehensive annotations, the description is nearly complete. It clarifies scope ('not official'), but could further explain what 'The Odds Gap' is or what the 'text' parameter affects, though the schema already covers those.

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 parameter definitions are fully documented in the schema. The description adds no meaning beyond what the schema already provides for the 'team' and 'text' parameters. Baseline 3 is appropriate when schema does the heavy lifting.

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 specifies the resource (a team's finished games and next game) and distinguishes it from an official league record. However, it lacks an explicit verb like 'retrieve' or 'get', leaving the action implicit. Sibling differentiation is implied through the 'not official' caveat, but not directly contrasted with other tools.

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?

No guidance is provided on when to use this tool versus alternatives like past_game or game_lines. The description merely states what content it returns without any context about suitable use cases or prerequisites.

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?