GridIron Data

Player profile

get_player

Read-onlyIdempotent

Returns one player's profile by id: name, team, position, injury status, jersey and cross-system ids, plus per-season data on Basic and above. Use it to check a player's current team or injury status. Free plan (profile fields only; season data needs Basic).

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>"
    },
    "name": "get_player"
  }
}

Input Schema

Name	Required	Description	Default
`season`	No	Only include this season's data. Default: every season.
`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
`ids`	No	Other systems' ids (gsis, pfr, pff, nfl, espn, sleeper) from the nflverse crosswalk.
`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.
`status`	No	HTTP status of the failed API call.
`seasons`	No	Season year -> that season's data (Basic and above).
`position`	No	Position.
`free_plan`	No	Present on free keys: what the free plan includes.
`player_id`	No	GridIron player id ("First Last#POS").
`updated_at`	No	When the record last changed.
`player_name`	No	Player name.
`upgrade_url`	No	Where to see the plans.
`vs_opponent`	No	Team code -> career matchup history (Basic and above).
`required_plan`	No	The plan that unlocks this data: basic or pro.
`espn_player_id`	No	ESPN athlete id.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds genuinely new behavioral context the annotations cannot convey: a plan gating rule ('Free plan (profile fields only; season data needs Basic)') that changes what an agent will actually receive for the same call. It does not describe response shape, but an output schema exists to handle that.

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?

Three tight sentences, front-loaded with the return content before the usage hint and the plan caveat. The plan restriction is stated twice ('per-season data on Basic and above' and 'season data needs Basic'), a small redundancy that costs a perfect score.

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?

For a two-parameter, read-only lookup with an output schema and full annotation coverage, the description supplies what is otherwise missing: field inventory, a primary use case, and the plan-tier limitation. The only residual gap is not pointing at get_player_by_espn_id / get_player_by_gsis_id when the caller has a different id system, though the schema's 'First Last#POS' guidance and search_players pointer largely mitigate that.

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?

With 100% schema description coverage the baseline is 3, and the description earns a bump by explaining that season-scoped data is tier-gated ('per-season data on Basic and above'), which tells the agent why the `season` parameter may return nothing useful on a free plan. The id format detail itself is left entirely to the schema, which is appropriate given full coverage.

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?

Opens with a specific verb and resource ('Returns one player's profile by id') and enumerates the returned fields (name, team, position, injury status, jersey, cross-system ids, per-season data), so the agent knows exactly what it gets. It does not explicitly contrast itself with the id-specific siblings (get_player_by_espn_id, get_player_by_gsis_id); the distinguishing detail (GridIron id) is carried by the schema rather than the description.

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 check a player's current team or injury status' gives a concrete use case, and the plan-tier note signals the boundary between free profile fields and paid season data. It stops short of naming alternatives for stat-heavy questions (e.g. get_player_stats), so the routing guidance is clear but not exhaustive.

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?