EndzoneAPI

Market odds

get_market_odds

Read-onlyIdempotent

Use for the extra betting markets of a game as history: the 1st half and 1st quarter winner, point spread and total, the 2nd half total, and the 2nd, 3rd and 4th quarter totals. Pass game_id (from get_schedule or get_games) and market. For each sportsbook it returns the opening line (the first one we captured) and the closing line (the last one before the game started), each as the list of outcomes with their point and American price, plus captured_at and minutes_before_start (negative when the last capture came after our scheduled start, which the sportsbooks' listed start can run past). Most books were captured once, so opening and closing are often the same line. Held from the 2023 season for the larger sportsbooks only; not every game has every market. Costs 10 credits a call; a game with no lines is refunded. Set estimate_only to get the price without being charged. For the full-game moneyline, spread and total use get_odds. Prices are market information: never work out a stake, payout or profit, recommend a bet, or send the user to a sportsbook.

Input Schema

Name	Required	Description
`market`	Yes	The market: h2h_h1 (1st half winner), spreads_h1 (1st half point spread), totals_h1 (1st half total points), h2h_q1 (1st quarter winner), spreads_q1 (1st quarter point spread), totals_q1 (1st quarter total points), totals_q2 (2nd quarter total points), totals_q3 (3rd quarter total points), totals_q4 (4th quarter total points), totals_h2 (2nd half total points)
`game_id`	Yes	Game id from get_schedule or get_games.
`bookmaker`	No	One bookmaker key, e.g. draftkings, fanduel, pinnacle.
`estimate_only`	No	Return what this call would cost, without charging or running it.

Output Schema

Name	Required	Description	Default
`note`	No
`tool`	No
`books`	Yes
`count`	Yes
`label`	Yes
`market`	Yes
`credits`	No
`game_id`	Yes
`estimate_only`	No
`scheduled_start`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only cover the safe-read profile, and the description adds substantial operational context: 10-credit cost, refund when a game has no lines, 2023-season data retention limited to larger books, incomplete market coverage per game, and the meaning of a negative minutes_before_start. It also flags the domain restriction (never compute stakes/payouts or recommend bets), which is behavior an agent cannot infer from annotations.

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?

Front-loaded with purpose and the sibling routing, then costs and caveats, which is the right order. It repeats the market enumeration already present in the enum, which is the one clearly redundant passage.

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

Completeness5/5

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

For a paid, historical, filtered-odds tool the description covers cost, refunds, data availability limits, line semantics and the parameter source. An output schema exists, yet the explanation of opening/closing lines and outcomes adds needed interpretation rather than duplicating structure.

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 baseline is 3, and the description does add value by sourcing game_id and explaining estimate_only's billing behavior. However, it never mentions the optional bookmaker filter, leaving one parameter's intent to the schema alone.

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

Purpose5/5

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

States a specific verb and resource ('extra betting markets of a game as history') and enumerates the exact markets covered. It also explicitly separates itself from get_odds, which handles full-game moneyline/spread/total, so an agent can pick the right tool 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.

Usage Guidelines5/5

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

Gives explicit routing: use this for derivative markets, use get_odds for full-game lines, and get game_id from get_schedule or get_games. It also names a real alternative entry point (estimate_only) for price checking before committing.

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

All EndzoneAPI 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.