GridIron Data

Player prop probability (over/under)

get_prop_probability

Read-onlyIdempotent

Returns the probability a player goes over or under a stat line (passing, rushing or receiving yards, TDs, attempts, completions, interceptions, receptions), with fair no-vig American odds for each side, the projected mean and spread, the week's game and betting line, and the model's backtest. Use it to price a player prop or compare a sportsbook line with a fair price. Players on bye or OUT/IR get p_over 0. Model estimate, not betting advice. Pro plan (Free and Basic keys get 403 pro_required).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "stat": "<stat>",
      "line": "<line>"
    },
    "name": "get_prop_probability"
  }
}

Input Schema

Name	Required	Description
`line`	Yes	The line to price, or up to 10 comma-separated lines.
`stat`	Yes	The stat the line is on.
`week`	No	NFL week, 1-18. Default: the current week, or the next one if the player's game this week is already final.
`espn_id`	No	ESPN athlete id, instead of player_id.
`player_id`	No	The player (give this or espn_id). GridIron player id, "First Last#POS", matched case-insensitively. Defenses are "Team Name#DST". Unsure of the id? Call search_players first.

Output Schema

Name	Required	Description
`game`	No	The week's game, with the betting line.
`note`	No	A sentence for the user saying which plan is needed.
`stat`	No	The stat.
`team`	No	Current team code.
`week`	No	Week priced.
`error`	No	Present only when the call failed: what went wrong.
`lines`	No	Per line: the over/under probabilities and fair no-vig American odds.
`model`	No	Method, fitted dispersion and the walk-forward backtest (Brier score, calibration).
`reason`	No	Machine-readable failure reason, e.g. basic_required or pro_required.
`season`	No	Season.
`status`	No	HTTP status of the failed API call.
`position`	No	Position.
`available`	No	false on a bye or when unavailable; every p_over is then 0.
`player_id`	No	GridIron player id ("First Last#POS").
`disclaimer`	No	Model estimate, not betting advice.
`projection`	No	Projected mean and standard deviation for the stat.
`player_name`	No	Player name.
`upgrade_url`	No	Where to see the plans.
`injury_status`	No	Standardized injury status.
`required_plan`	No	The plan that unlocks this data: basic or pro.
`espn_player_id`	No	ESPN athlete id.
`injury_status_raw`	No	Status as the source spelled it.
`unavailable_reason`	No	Why the player is unavailable, when he is.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description still adds real behavior: p_over is 0 for bye or OUT/IR players, output includes no-vig odds and a backtest, and Free/Basic keys receive a 403 pro_required. It also sets expectations honestly with "Model estimate, not betting advice."

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 the core answer, then returns, then usage, then caveats — good ordering with no filler sentences. It is dense in one paragraph and re-lists return fields the output schema already declares, which is mild redundancy but aids quick scanning.

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 5-parameter read-only pricing tool with a full output schema, the description covers the edge cases an agent needs: bye/inactive handling, plan gating with the exact error code, and the model-estimate disclaimer. Return values need not be explained given the output schema, so nothing material is missing.

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 line, stat, week, player_id and espn_id are already documented, including the multi-line comma syntax and the search_players fallback — the description adds no parameter-level detail beyond saying the line is a "stat line." Baseline 3 applies when the schema carries the semantics.

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 (probability a player goes over/under a stat line) and enumerates the supported stat families and the returned quantities (fair no-vig odds, projected mean and spread, game/line, backtest). Nothing here is a restatement of the name; an agent can tell this is a pricing tool rather than a stats or projection dump.

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?

"Use it to price a player prop or compare a sportsbook line with a fair price" gives a clear triggering context, and the plan note plus the bye/OUT/IR rule pre-empt common failure paths. It does not explicitly point at a sibling when the caller actually wants raw projections (e.g. get_projections), so differentiation 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 GridIron Data 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?