GridIron Data

List NFL players

list_players

Read-onlyIdempotent

Returns a page of NFL players (player_id, name, position, team), optionally for one position, paged with next_cursor. Use it to browse a position group; to find a specific player, search_players is faster. Free plan.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_players"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Players per page, 1-100.
`cursor`	No	next_cursor from the previous page; omit for the first page.
`position`	No	Only this position. Pro keys can also list offensive linemen with C, G or OT.

Output Schema

Name	Required	Description
`note`	No	A sentence for the user saying which plan is needed.
`count`	No	Players on this page.
`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.
`players`	No	One page of players with their player_id, name, position and team.
`next_cursor`	No	Pass back as cursor for the next page; absent on the last page.
`upgrade_url`	No	Where to see the plans.
`required_plan`	No	The plan that unlocks this data: basic or pro.

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 and closed-world, so the safety profile is covered. The description adds real context beyond that: results are paginated via next_cursor, the payload shape is known, and the "Free plan." note hints at tier gating on data availability. It stops short of explaining what the free tier actually excludes or how paging terminates.

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?

Two front-loaded sentences that carry scope, alternative routing and paging in minimal space. The trailing "Free plan." fragment is terse to the point of ambiguity and slightly dents an otherwise tight structure.

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 and full annotation coverage, the description needn't explain return values, and it covers paging, filtering and sibling routing. The remaining gap is the unexplained "Free plan." constraint, which leaves an agent unsure whether results are truncated on the free tier.

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 coverage is 100%, so all three parameters (limit, cursor, position) are already documented in the schema, including the Pro-key note for C/G/OT. The description only reiterates position filtering and cursor paging without adding format or default detail, 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 page of NFL players") and names the exact fields returned (player_id, name, position, team). It also distinguishes itself from search_players by scope (browse a position group vs. find a specific player), so an agent can pick it without opening the schema.

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

Usage Guidelines5/5

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

Explicitly says when to use it ("browse a position group") and names the alternative with its condition ("to find a specific player, search_players is faster"). The optional position filter and cursor paging are framed in usage terms rather than restating types.

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?