EndzoneAPI

Prop history

get_prop_history

Read-onlyIdempotent

Use to see how a player did against his prop line over time: for one market (passing, rushing or receiving yards, passing touchdowns, completions, attempts, interceptions, carries, receptions, anytime or first touchdown, touchdowns scored, or the longest completion, rush or reception), one row per game with the closing line (the median across books, or one book's), the opening line (the same as the close wherever only one capture was taken), the prices, what the player actually recorded from our box scores and the result against the line, plus the over rate, up to 200 games a call. Costs 10 credits for every 25 games already played that a call covers, and at least 10 a call (accounts opened before November 1 2026 pay 10 a call). Set estimate_only to get the price without being charged. 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
`limit`	No	Games to return, oldest first (default 50, max 200). next_from_date says where to continue.
`market`	Yes	The market: player_pass_yds (passing yards), player_pass_tds (passing touchdowns), player_pass_completions (pass completions), player_pass_attempts (pass attempts), player_pass_interceptions (interceptions thrown), player_rush_yds (rushing yards), player_rush_attempts (rush attempts), player_receptions (receptions), player_reception_yds (receiving yards), player_anytime_td (anytime touchdown (over = scores)), player_tds_over (touchdowns scored), player_1st_td (first touchdown scorer (over = scores the game's first touchdown)), player_pass_longest_completion (longest completion), player_rush_longest (longest rush), player_reception_longest (longest reception)
`to_date`	No	Last date, YYYY-MM-DD (the game's date).
`bookmaker`	No	One book's closing line instead of the median across books, e.g. draftkings.
`from_date`	No	First date, YYYY-MM-DD (the game's date).
`player_id`	Yes	Player id (a GSIS id such as 00-0033873) from search_players.
`estimate_only`	No	Return what this call would cost, without charging or running it.

Output Schema

Name	Required	Description	Default
`note`	No
`stat`	Yes
`tool`	No
`count`	Yes
`games`	Yes
`market`	Yes
`credits`	No
`summary`	Yes
`bookmaker`	Yes
`player_id`	Yes
`truncated`	No
`player_name`	Yes
`estimate_only`	No
`next_from_date`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 1, 2026

changedInput schema / properties / market / description

Previous value: -"The market: player_pass_yds (passing yards), player_pass_tds (passing touchdowns), player_pass_completions (pass completions), player_pass_attempts (pass attempts), player_pass_interceptions (interceptions thrown), player_rush_yds (rushing yards), player_rush_attempts (rush attempts), player_receptions (receptions), player_reception_yds (receiving yards), player_anytime_td (anytime touchdown (over = scores))"New value: +"The market: player_pass_yds (passing yards), player_pass_tds (passing touchdowns), player_pass_completions (pass completions), player_pass_attempts (pass attempts), player_pass_interceptions (interceptions thrown), player_rush_yds (rushing yards), player_rush_attempts (rush attempts), player_receptions (receptions), player_reception_yds (receiving yards), player_anytime_td (anytime touchdown (over = scores)), player_tds_over (touchdowns scored), player_1st_td (first touchdown scorer (over = scores the game's first touchdown)), player_pass_longest_completion (longest completion), player_rush_longest (longest rush), player_reception_longest (longest reception)"

changedInput schema / properties / market / enum

Previous value: -[
-  "player_pass_yds",
-  "player_pass_tds",
-  "player_pass_completions",
-  "player_pass_attempts",
-  "player_pass_interceptions",
-  "player_rush_yds",
-  "player_rush_attempts",
-  "player_receptions",
-  "player_reception_yds",
-  "player_anytime_td"
-]New value: +[
+  "player_pass_yds",
+  "player_pass_tds",
+  "player_pass_completions",
+  "player_pass_attempts",
+  "player_pass_interceptions",
+  "player_rush_yds",
+  "player_rush_attempts",
+  "player_receptions",
+  "player_reception_yds",
+  "player_anytime_td",
+  "player_tds_over",
+  "player_1st_td",
+  "player_pass_longest_completion",
+  "player_rush_longest",
+  "player_reception_longest"
+]

Changed1 schema field changedOct 31, 2026

addedInput schema / properties / estimate_only

Added value: +{
+  "description": "Return what this call would cost, without charging or running it.",
+  "type": "boolean"
+}

AddedOct 10, 2026

TDQS

A3.8/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 earns credit by adding what annotations cannot: the credit cost model (10 credits per 25 games, minimum 10, legacy accounts), the free estimate_only preview, and the policy that prices are market information with no stake/payout/recommendation advice. It does not discuss rate limits beyond cost or error behavior, but the added context is substantial.

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

Conciseness3/5

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

Purpose and cost are reasonably front-loaded, but the bulk is a single run-on sentence that re-lists fifteen markets already enumerated in the schema enum (passing, rushing, receiving yards, touchdowns, longest completion/rush/reception), which is wasted length. The cost and responsible-use sentences are the parts that actually earn their place.

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 present the description needn't explain return values, and it goes further anyway by describing row contents and the over rate. Cost, limits, pagination continuation (next_from_date) and the estimate_only escape hatch are all covered, leaving little an agent needs beyond the default of 50 games that lives in the schema.

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 every parameter including bookmaker, estimate_only, limit and the market enum. The description explains the bookmaker choice (median across books vs one book's close) and the one-capture opening-line behavior, but those are largely return-shape semantics rather than parameter meaning, so it lands at 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 gives a specific verb and resource — see how a player performed against a prop line over time — and precisely enumerates the markets, the per-game row contents (closing line, opening line, prices, box-score result, over rate) and the 200-game cap. It is unmistakably a historical prop tool, but it never names a sibling such as get_player_props or get_line_movement to draw the boundary explicitly.

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

Usage Guidelines4/5

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

It opens with an explicit 'Use to ...' framing and explains the estimate_only workflow for pricing a call before spending credits, which is real operational guidance. It still lacks any 'not for X, use Y' exclusion against the many nearby prop/odds tools.

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.