GridIron Data

Player season stats

get_player_stats

Read-onlyIdempotent

Returns a player's actual stats for one season (2020 to now): fantasy points week by week and in total in the chosen scoring, plus the raw stat line and snap share each week. Use it for "how did X do" questions, game logs and comparisons with projections. Basic plan and above.

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": {
      "player_id": "<player_id>",
      "season": "<season>"
    },
    "name": "get_player_stats"
  }
}

Input Schema

Name	Required	Description	Default
`season`	Yes	Season year, 2020 or later.
`scoring`	No	Fantasy scoring: ppr (full PPR, the default), half (half-PPR) or standard.	ppr
`player_id`	Yes	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
`note`	No	A sentence for the user saying which plan is needed.
`team`	No	Current team code.
`error`	No	Present only when the call failed: what went wrong.
`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.
`scoring`	No	Scoring used.
`position`	No	Position.
`player_id`	No	GridIron player id ("First Last#POS").
`player_name`	No	Player name.
`snap_counts`	No	Snap counts.
`upgrade_url`	No	Where to see the plans.
`weekly_stats`	No	Week -> that week's stat line, points and snap share (box score from 2025).
`injury_status`	No	Current injury status.
`required_plan`	No	The plan that unlocks this data: basic or pro.
`season_points`	No	Total fantasy points for the season.
`season_totals`	No	Season stat totals.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds two things the annotations cannot: the data floor of '2020 to now' and the access-tier constraint 'Basic plan and above', which an agent needs before promising a result. It does not discuss errors for out-of-range seasons, but the schema pattern partly covers that.

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?

Two sentences: the first leads with what is returned and its scope, the second with when to use it, closing with the plan requirement. No filler wording, and the most decision-relevant content is front-loaded.

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 read-only, closed-world retrieval tool with an output schema, fully documented parameters, and annotations covering safety, the definition supplies everything an agent needs: scope, contents, season range, use cases, and the plan gate. 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%, with season bounds, scoring enum values, and player_id format plus a pointer to search_players all documented in the schema. The description echoes 'one season' and 'chosen scoring' without adding syntax, valid values, or defaults beyond what the schema already states, so baseline 3 applies.

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 ('Returns a player's actual stats for one season') and enumerates the payload: weekly and total fantasy points in the chosen scoring, raw stat line, and snap share. The phrase 'comparisons with projections' implicitly contrasts it with get_projections, and 'actual stats' signals this is historical rather than projected data.

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?

Explicitly names the use cases: 'how did X do' questions, game logs, and comparisons with projections. That is clear positive guidance, but there is no negative guidance (e.g. 'for future weeks use get_projections') and no mention of when the sibling get_snap_share or get_player would be preferable.

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?