espn-mcp

by HamCops

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation3/5
Tools are mostly distinct, but there is overlap between get_draft_context and get_draft_state (context bundles state), and between get_available_players and get_value_board (both relate to player rankings). These could confuse an agent into choosing the wrong one.
Naming Consistency4/5
Most tools follow a get_verb_noun pattern, but there are exceptions like next_pick and reset_draft, and refresh_board/refresh_draft_order which use a different verb. This slight inconsistency reduces clarity but the pattern is largely predictable.
Tool Count4/5
14 tools is reasonable for a fantasy draft assistant, covering state queries, player info, and pick management. There is some redundancy (e.g., get_draft_context vs get_draft_state) but the count is not excessive.
Completeness5/5
The tool set covers the full draft workflow: league settings, draft state, available players, roster, player details, pick recording (single/batch), undo, cache refresh, and reset. No major gaps are apparent for a fantasy draft scenario.
Average 4/5 across 13 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It lists the data categories bundled, implying a read-only aggregation operation, but it never explicitly states that it is non-destructive or that it does not modify any state. It also does not mention performance or rate-limit implications despite aggregating many data points.
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 two concise sentences, front-loaded with the key phrase 'One-call snapshot'. It lists the bundled components in a clear, scannable list and wastes no words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the main content categories, it omits the parameter explanation and provides no hint about the output structure. Since there is no output schema, the agent is left without information on how the response is formatted or how to interpret the bundled data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the tool description does not mention the 'top_per_position' parameter at all. The agent has no guidance on how to set this value beyond its name and default, making correct invocation a guess.
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 clearly states it is a 'One-call snapshot' that bundles draft state, roster needs, best available players, ADP fallers, etc. This makes the purpose unambiguous and distinguishes it from sibling tools that focus on individual data sources like get_draft_state or get_available_players.
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?
It explicitly says 'when you are on the clock' and 'everything needed to make a pick inside a 60-90 second clock', conveying the ideal usage scenario. However, it does not explicitly mention when not to use it or direct to alternatives for more granular data, leaving some ambiguity about edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states the output contents and that the tool is intentionally lightweight, but it does not mention potential limitations, error conditions, or whether it performs any side effects. Some transparency is present, but not comprehensive.
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 two sentences, direct, and front-loaded. It conveys the purpose and key output details without unnecessary jargon or filler, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no output schema, the description should clarify the parameter's role and possibly outline output format or caveats. It explains the overall purpose but leaves the parameter ambiguous and omits edge-case behavior, making it incomplete for a tool that requires user input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'candidates', is not described in the schema or the description. The schema provides only type and default, with zero coverage. The description does not compensate, leaving the parameter's meaning entirely unclear.
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 clearly states that this is the go-to call when making a pick, and specifies exactly what it returns: best available players, roster fit, tier cliff, and time until next turn. This distinguishes it from general draft tools despite not explicitly naming siblings.
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?
It explicitly says to use it 'when you are on the clock' and notes it is 'deliberately small' for a 60-second draft clock, giving a clear temporal trigger. However, it could more explicitly contrast with sibling tools like get_draft_context or record_pick to fully guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to indicate side effects or safety. The description does not explicitly state that this is a read-only operation with no modifications, nor does it disclose any potential limitations or errors. Since annotations are absent, the description carries the full burden for behavioral transparency and falls short.
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 two sentences, concise and directly to the point. It efficiently conveys the output content and the search options without unnecessary fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides adequate detail on what is returned and how to search. However, it leaves ambiguity about whether at least one parameter must be provided, what happens if both are given, or behavior when neither is supplied. These gaps make it incomplete for fully guiding an agent in some edge cases.
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?
The description adds meaningful semantics to both parameters: 'name' is explicitly described as a partial match, and 'player_id' is described as exact. This clarifies the expected input format and behavior beyond the raw schema types, covering all parameters present in the schema.
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 clearly states the tool's purpose: retrieving full detail on one player, listing the specific attributes (projection, VORP, tier, ADP, injury status). It distinguishes itself from sibling tools by focusing on a single player and mentions the search methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It does not mention that this should be used for single-player lookups while other tools handle lists, rosters, or draft context. The 'when to use' information is only implicitly conveyed through the tool name and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to fall back on, the description carries the full burden of disclosing behavior. It states that a pick is removed, but it does not mention permanence, error conditions when no manual pick exists, or any side effects beyond removal.
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, focused sentence with no filler. It immediately states the action and the target, making it highly concise and well-structured.
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 tool with no parameters and no output schema, the description provides enough context to understand the core operation. It could mention what happens when there is no manual pick to remove, but that is a minor gap for such a simple action.
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?
The tool has zero parameters and an empty input schema, so parameter descriptions are unnecessary. The baseline of 4 applies because no parameter guidance is needed.
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 uses a specific verb ('Remove') and a precise object ('the most recently manually recorded pick'), making the tool's purpose immediately clear and distinguishable from siblings like record_pick or reset_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives, such as record_pick or reset_draft. The qualifier 'most recently manually recorded' implies a condition, but there is no direct 'use this when' or 'do not use for' instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only, side effects, or data persistence. It only states what the tool returns, leaving the user to infer whether it modifies state or has other implications.
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 succinct and well-organized. It uses a short introductory phrase, then a clear bullet-like list of parameters with no redundant or extraneous information.
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?
The description gives enough context for a simple read operation: it confirms the output is a ranked list of undrafted players. It lacks details on returned fields or error handling, but given the low complexity and absence of an output schema, the information is adequate.
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?
All three parameters are fully described: position lists allowable values and the omit-all behavior, limit explains its purpose, and sort_by enumerates all options with explanations. This provides complete semantic coverage beyond the bare schema.
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 clearly states the tool's function: 'Undrafted players, ranked.' It then enumerates each parameter with its meaning and valid values, leaving no ambiguity about what the tool does.
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 explains how to use each parameter (e.g., position options, sort_by choices, limit meaning) and indicates defaults. However, it does not explicitly state when to prefer this tool over similar siblings like get_player or get_roster, so guidance on tool selection is lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the refresh behavior and the caching rationale, which is useful context beyond the name. However, it doesn't state side effects (presumably none) or the return format, leaving some gaps.
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 with no waste. The primary action is front-loaded, and the usage context follows. Every word earns its place.
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 zero-parameter refresh tool, the description explains what it does, when to call it, and why (caching issue). It doesn't describe output, but the purpose implies the returned draft order. This is adequate for correct agent invocation.
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?
The tool has 0 parameters, so the description need not add parameter details. Per guidelines, baseline is 4 when no parameters exist. The description appropriately avoids extraneous parameter information.
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 states a specific action ('Re-read the draft order and your slot') with a clear resource. It distinguishes itself from siblings by the refresh nature, though it doesn't explicitly name alternatives. The purpose is unambiguous.
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?
It provides explicit guidance on when to call: 'after a randomized draft order is drawn' and explains the caching scenario. It doesn't mention alternatives, but the context is clear enough for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It states it returns a team's roster and unfilled starting slots, which implies a read-only operation, but it does not explicitly say it is read-only, mention any side effects, or describe error conditions (e.g., invalid team_id). It also does not mention authentication requirements, which are implied by 'your team.' This is minimal but not contradictory.
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 two sentences with no filler. The core purpose is front-loaded, followed by the default behavior. Every word earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should outline what the response contains. It says 'current roster' and 'unfilled starting slots,' which is the key information, but it does not describe the structure, whether player details are included, or any edge cases (e.g., empty roster, invalid team). Given the low complexity (one optional param), this is adequate but leaves room for improvement.
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?
The only parameter, team_id, has zero schema description coverage. The description adds meaning by explaining that it defaults to ESPN_TEAM_ID when null, which is valuable. However, it does not elaborate on what team_id represents or the valid range/format, leaving some ambiguity. It compensates for the schema gap reasonably well but could be more explicit.
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 clearly states a specific verb ('get') and resource ('roster'), and goes further by specifying it also reports which starting slots are unfilled. It distinguishes itself from sibling tools like get_available_players and get_player by focusing on the team's current roster and lineup status. The purpose is unambiguous and immediately understood.
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 provides clear context by noting that it defaults to your team (ESPN_TEAM_ID), which implicitly tells the agent when no team_id is provided. It does not explicitly name alternatives or state when not to use it, but given the sibling set, the use case is evident. It lacks explicit exclusions or 'use instead' guidance, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It does mention merge behavior and ambiguous-name handling, but it does not disclose side effects, whether existing picks can be overwritten, or what errors/responses might occur.
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 concise, well organized, and free of unnecessary detail. The Args section maps cleanly to the schema parameters and adds useful guidance without bloat.
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?
The description provides sufficient context for typical use: when to call it, how merging works, and how ambiguous names are handled. It lacks output/error expectations and explicit differentiation from record_picks, but the core usage context is present.
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?
The description adds meaning to all three parameters, including acceptable formats, defaults, and the difference between player name and player ID. It does not explicitly state that player and player_id are mutually exclusive, though the phrasing strongly implies it.
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 clearly states the tool's purpose: manually recording a pick when ESPN is not reporting draft data. It also provides concrete use cases and distinguishes the action from normal draft-state retrieval.
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 explains when to use the tool (live draft reporting gaps or off-ESPN drafts) and notes how recorded picks merge with ESPN data. However, it does not explicitly differentiate this singular record_pick tool from the sibling record_picks tool, which could cause ambiguity in batch scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It clearly indicates a destructive bulk reset ('clear all') but does not mention whether the action is reversible or if it affects other draft data. This is acceptable but not fully transparent.
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 extremely concise: two short sentences that state the action and the recommended usage context. There is no unnecessary fluff or redundancy.
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?
The description is complete enough for this simple tool. It clearly states what is cleared and when to use it. However, it does not describe the post-condition (e.g., draft becomes empty), which would slightly enhance completeness. Still, given the simplicity, it is nearly complete.
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?
The tool takes no parameters (schema coverage 100% with zero params), so the baseline score of 4 applies. The description correctly omits any parameter details since none exist.
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 'Clear all manually recorded picks' uses a specific verb ('clear') and a clear resource ('manually recorded picks'), distinguishing it from sibling tools like record_pick and undo_pick. It unambiguously states the action performed.
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 phrase 'Use before a new draft' provides explicit guidance on when to invoke this tool. It could be more detailed about when not to use it, but the primary use case is clearly communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two behavioral aspects: the tool is never cached, and it is safe for frequent polling. These facts imply a read-only, low-risk operation, giving the agent confidence about side effects and performance.
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 extremely concise, consisting of two short sentences. Every word adds value, covering the tool's output and usage guidance without any fluff.
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?
The description provides sufficient context about what the tool returns and how frequently it can be called. It omits details about the output format or potential error conditions, but for a simple state retrieval tool, the information is adequate.
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?
The tool takes no parameters, so there is nothing to describe. The schema already reflects this, and the description adds no unnecessary parameter details. Perfect score 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 states the tool returns live draft state including picks made, who is on the clock, and the user's next picks. Though it uses a noun phrase instead of an explicit verb, the intention is unambiguous and distinct from sibling tools like get_draft_context.
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 explicitly notes the tool is never cached and is safe to poll every few seconds during a live draft. This provides clear guidance on when to use it, though it does not contrast with alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses what information the tool returns (startable player counts per position and the last startable player's projection). It does not mention side effects, but given the nature of the content, it is inferred to be read-only. No annotations are present, so the description carries the burden adequately.
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 concise, consisting of two sentences. It front-loads the main purpose ('Replacement levels and tier structure') and then elaborates with specific details, maintaining clarity without unnecessary verbosity.
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?
The description adequately explains the tool's output conceptually, covering key aspects such as player counts per position and projections. However, it does not define 'replacement levels' explicitly, which might be assumed domain knowledge. Still, it is sufficient for an agent to understand the tool's function.
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?
The input schema is empty, so there are no parameters to describe. The description correctly omits any parameter details, and there is no missing information in this dimension.
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 clearly states the tool's purpose: providing replacement levels and tier structure for the league. It expands on this by explaining why rankings look the way they do, which is a specific and unambiguous function.
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 does not explicitly state when to use this tool versus the sibling tools (e.g., get_draft_state, get_available_players). It implies a use case for understanding rankings, but lacks direct contrast or guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It mentions that it forces a re-fetch and that the pool is cached for a TTL, which explains the operation's effect. It does not mention potential side effects like performance cost or return format, but the core behavior is transparent.
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 two sentences, tightly focused on the action and its trigger condition. It front-loads the primary purpose and avoids any extraneous detail. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does and when to use it, but there is no output schema and the description does not mention what the tool returns (e.g., status, updated data). This omission could leave an agent uncertain about the result. Given the simple nature of the tool, this is a minor gap but still incomplete.
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?
The tool has zero parameters, so the schema trivially covers everything. The description adds no parameter explanation, which is appropriate given there are none. The baseline for 0 params is 4, and the description does not need to elaborate further.
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 clearly states the tool's function: forcing a re-fetch of the player pool, projections, and value math. It also provides the rationale for why this is needed (caching, staleness). This is a specific and unambiguous purpose.
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 explicitly says when to call the tool: when projections change (injury news, depth chart move) or the cache looks stale. It does not explicitly contrast with sibling tools like get_available_players, but the 'call this if...' condition gives clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation by describing a static league format and advising a single call, but it does not explicitly state that it has no side effects or that it can be called safely multiple times. The note about calling once suggests idempotence, but not explicitly. A getter typically needs to disclose read-only status, which is absent.
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 two sentences, front-loads the core content (what the tool returns), and then gives usage guidance. There is zero waste; every sentence earns its place.
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?
With no parameters and no output schema, the description must explain what the tool returns and when to use it. It lists the key attributes and explains the foundational nature of the tool. This is complete for a zero-parameter getter with no side effects.
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?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific information, but none is needed. It correctly avoids redundant content.
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 explicitly states the tool returns league format details (team count, scoring rules, starting lineup, draft type). This is a clear, specific resource that distinguishes it from siblings like get_draft_state or get_roster, which deal with different aspects of the draft.
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?
It explicitly instructs to call this once at the start of a session and explains why: every other tool's numbers are relative to this league's shape. This provides clear timing and dependency guidance, making it obvious when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains that picks persist, only new names are appended, duplicates are ignored (idempotent re-sending), order is preserved, and unrecognized or ambiguous names are reported without blocking the rest. These are critical behavioral traits that go beyond the schema and give the agent full transparency into side effects and error handling.
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?
The description is three short paragraphs, each with a distinct purpose: the core function, the live-draft context, and the sync/error behavior. It is front-loaded with the main purpose and keeps each sentence informative without fluff. It could be slightly more concise, but the structure is logical and easy to scan.
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 tool with only one parameter, no output schema, and no annotations, the description is remarkably complete. It covers when to use (live draft, since ESPN delays publication), how to use (incremental vs full sync), and what to expect (duplicates ignored, ambiguous names reported). An agent has everything needed to call the tool correctly without further clarification.
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?
The schema has a single 'players' parameter with 0% description coverage, so the description must compensate. It does so by explaining that the array contains player names, that the order matters (draft order), and that names may be ambiguous or unrecognized and will be reported. While it does not specify the exact name format (e.g., first/last, team abbreviations), it adds meaningful semantics about ordering and error handling, which is more than the bare schema provides.
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 clearly states the tool records multiple picks by name in draft order, using a specific verb ('Record'), a resource ('picks'), and a scope ('several at once'). It implicitly distinguishes from the singular sibling record_pick by emphasizing 'several picks at once' and 'in draft order', giving an agent unambiguous understanding of its function.
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?
The description provides explicit usage context: it is the fast path during a live draft because ESPN does not publish picks, and it explains the incremental sync strategy ('only ever send the picks made since your last call'). It also clarifies that re-sending the entire history is intended for syncing, which informs when to use this tool versus alternatives. While it does not name record_pick directly, the guidance is clear enough for an agent to select the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

espn-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![espn-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/HamCops/espn-mcp/badges/card.svg)](https://glama.ai/mcp/servers/HamCops/espn-mcp)

Score Badge

Copy to your README.md:

[![espn-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/HamCops/espn-mcp/badges/score.svg)](https://glama.ai/mcp/servers/HamCops/espn-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/HamCops/espn-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server