PuckAPI

Prop history

get_prop_history

Read-onlyIdempotent

Use to see how a player did against his prop line over time: for one market (points, goals, assists, shots on goal, blocked shots, goalie saves or anytime goal scorer), 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_points (points), player_goals (goals), player_assists (assists), player_shots_on_goal (shots on goal), player_blocked_shots (blocked shots), player_total_saves (goalie saves), player_goal_scorer_anytime (anytime goal scorer (over = scores))
`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 (e.g. 8478402) 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.

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

A4.3/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: a precise cost model (10 credits per 25 games played, 10-credit minimum, legacy pricing), a 200-game per-call ceiling, pagination continuation via next_from_date, and a compliance constraint forbidding stake, payout or profit calculations. These are behavioral facts the agent could not infer from annotations or schema.

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?

Purpose is front-loaded in the first clause and every sentence carries real information (markets, row contents, cost, estimate_only, compliance). It is dense to the point of being a single run-on sentence, which slightly hurts scanability, but there is no filler to cut.

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?

Given an output schema already documents the return shape, the description covers what remains: cost mechanics, credit-minimizing estimate_only, the 200-game cap and pagination, which markets are valid, and the downstream usage restriction. An agent has everything needed to invoke and price the call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3, and the description earns above it by clarifying semantics the schema only gestures at: the closing line is the median across books unless one bookmaker is given, the opening line mirrors the close where only one capture exists, and 'over rate' is part of the response. It still does not spell out how from_date/to_date interact with limit and paging order beyond what the schema says.

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 and resource: 'see how a player did against his prop line over time', and enumerates the exact markets covered plus the per-game row contents (closing line, opening line, prices, actual result, over rate). It does not name sibling tools such as get_player_props or get_prop_projections, so differentiation is implicit rather than explicit, but the historical 'against the line' framing is distinctive enough to separate it from current-line tools.

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?

Opens with an explicit use case ('Use to see how a player did against his prop line over time') and explains when to set estimate_only (to get the price without being charged). It gives no explicit when-not-to-use guidance and never names the alternative to pick when the agent wants current or projected lines instead of history.

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

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