DraftCall

Get one NFL player

get_player

Read-onlyIdempotent

A single player's fantasy profile: positional rank, points per game in all three scoring formats, season stats, games played, and bye week.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	Player name, e.g. "Puka Nacua".

Output Schema

TableJSON Schema

Name	Required	Description
`adp`	No	Consensus draft position in the requested format, or null when the board does not have him.
`ppg`	Yes	Points per game in each scoring format.
`url`	Yes	The draftcall.io page these figures came from. This is the citation to use.
`name`	Yes
`rank`	Yes	Rank within the position, by points per game.
`slug`	No	URL segment for this player on draftcall.io.
`team`	Yes	Team abbreviation.
`tier`	No	The tier this player sits in at his position, or null when he is outside the ranked pool.
`stats`	No	Season totals for the fields that apply to the position.
`byeWeek`	No
`position`	Yes	QB, RB, WR, TE, K or DEF.
`efficiency`	No	Per-game and per-target rates. Each is null where its inputs do not apply.
`gamesPlayed`	Yes
`refreshed_at`	Yes	When this dataset was last refreshed, as an ISO 8601 timestamp.
`stats_season`	Yes	The completed NFL season every figure in this result describes.

TDQS

A3.7/5.0

Behavior3/5

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

The annotations already establish that the tool is read-only, idempotent, and non-destructive, so the description does not need to repeat those traits. The description adds useful context about what data the profile contains, but it does not disclose additional behavioral constraints such as authentication, rate limits, or error conditions.

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?

The description is a single efficient sentence that front-loads the core scope and then lists the specific profile attributes. There is no wasted wording, and the structure makes the tool's purpose immediately understandable.

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 one-parameter tool with a full input schema, an output schema, and strong read-only annotations, the description provides enough information for an agent to call it appropriately. The included list of return fields covers what an agent would likely need to know about the tool's output.

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?

The input schema provides 100% coverage of the single 'name' parameter, including an example value. The description does not add meaning beyond the schema, but with full schema coverage, the baseline score of 3 is appropriate.

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?

The description clearly identifies the tool's scope as a single player's fantasy profile and enumerates the specific stats returned, such as positional rank, points per game, and bye week. It distinguishes itself from compare_players and search_players through the word 'single', but it does not name a sibling or use an explicit action verb like 'gets' or 'retrieves'.

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

Usage Guidelines3/5

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

The description implies that this tool should be used when you need a detailed profile for one known player, especially compared to search or comparison tools. However, it provides no explicit guidance about when not to use it or which sibling tool would be a better fit for related needs.

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

All DraftCall tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct query type: single-player lookup, two-player comparison, rankings, scarcity, ADP gaps, schedule, bye conflicts, weekly matchup, search, and claim verification. Even related tools like compare_players and get_player have clearly separated purposes that an agent can reliably distinguish.

Naming Consistency4/5

Seven tools follow the get_ noun pattern, while search_players, compare_players, and verify_claim use verb_noun without get. The convention is still highly readable and predictable, with only minor deviations.

Tool Count5/5

Ten tools is well-scoped for a fantasy football data server. Each tool covers a meaningful slice of draft, in-season, and fact-checking workflows without unnecessary overlap or bloat.

Completeness4/5

The set covers player lookup, head-to-head comparison, rankings, scarcity, schedule, bye conflicts, weekly matchups, and stat verification. A direct standalone ADP lookup and projections are missing, but agents can work around those gaps using the provided tools.

Get one NFL player

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources