Skip to main content
Glama
jolfr

fantasy-mcp

by jolfr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Get Player

get_player

Get a full ESPN fantasy football player profile: injury status, league ownership, season stats, outlook, and game log. Use it to evaluate a player or decide whether to claim them.

Instructions

Full profile for one player: status, league ownership, season numbers, outlook, game log.

Use this for "tell me about X", "how has X been doing", "who has X in my league", or "is X worth a claim". Pass exactly one of: name (full name is best; a partial name works if it matches one active player) or player_id (from any other tool's rows -- prefer this when you have it).

Returns: player_id, name, position, pro_team, injury_status, injured, eligible_slots; league_status (ONTEAM / FREEAGENT / WAIVERS) and owned_by (the league team rostering them, or null); ownership across all ESPN leagues (percent_owned, percent_started, percent_change = trend, adp); season {year, projected, points, positional_rank}; last_season {year, points}; outlook (ESPN's written preseason summary); game_log newest first, each week with points, projected (null until ESPN publishes it), and stats -- raw counts such as rush_yds, targets, pass_td, fg_made_40_49, dst_sacks (zero-valued stats omitted). Covers this season and last. No news articles or opponent-matchup ratings. Name lookup uses a snapshot of ESPN's active-player list taken when the server started; a player signed since then may not resolve by name but still works by player_id. In clients that support MCP Apps this renders as a card; the JSON profile is always returned as text. headshot_url points at ESPN's CDN (team logo for a D/ST) and is not verified to exist.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
player_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden, and it does so thoroughly. It discloses the name lookup snapshot limitation, game log ordering, zero-valued stat omission, headshot_url verification caveat, season coverage, and rendering behavior. This is far beyond what annotations could provide.

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 long but every sentence carries operational value: usage conditions, parameter semantics, full return structure, caveats, and rendering notes. It is front-loaded with the core purpose and usage before diving into field details.

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?

Given the tool's complexity, zero annotations, and no output schema, the description is remarkably complete. It covers inputs, output fields, data provenance, limitations, and return format, leaving an agent with enough information to invoke the tool correctly and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description fully compensates by explaining both parameters: name semantics ('full name is best; a partial name works if it matches one active player') and player_id semantics ('from any other tool's rows -- prefer this when you have it'). It also clarifies the relationship between them with 'Pass exactly one of'.

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?

The description states a specific verb and resource: 'Full profile for one player' with a detailed list of contents including status, league ownership, season numbers, outlook, and game log. It clearly distinguishes this from siblings like get_free_agents and get_my_team by focusing on a single player's profile.

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?

The description gives explicit use cases ('tell me about X', 'how has X been doing', 'who has X in my league', 'is X worth a claim') and parameter selection guidance. It also states exclusions ('No news articles or opponent-matchup ratings'), but does not explicitly name sibling tools as alternatives, leaving some routing to inference.

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

Deploy Server

Other Tools