ESPN Fantasy Basketball MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes: schedule, teams, rosters, free agents, matchups, draft status, player stats, comparisons, trade analysis, and trends. However, 'get_free_agents' and 'get_available_players' could be confused (one is for waiver wire, the other for draft), and the three draft advisory tools ('should_i_bid', 'who_should_i_target_next', 'analyze_my_draft_strategy') overlap in context though they produce different outputs.
Naming Consistency4/5
The majority follow a clear 'get_' or 'analyze_' + noun pattern, such as get_league_teams, get_player_stats, and analyze_trade_proposal. A few deviating question-style names (should_i_bid, who_should_i_target_next) stand out but are still readable and follow a similar snake_case style.
Tool Count5/5
14 tools is a well-scoped set for a fantasy basketball analytics server. Each tool addresses a meaningful aspect of the domain without redundancy, and the count falls comfortably in the ideal range.
Completeness4/5
The server covers most core read and analysis workflows: schedule, rosters, matchups, draft, free agents, player stats, comparisons, trends, and trade evaluations. It lacks write operations like adding players or setting lineups, but for an advisory/analytics assistant this is a reasonable scope with only minor gaps.
Average 4.1/5 across 14 of 14 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden, but it only mentions inputs and return type. It does not disclose whether this makes external API calls, any side effects, rate limits, or that it requires authentication for private leagues beyond the parameter names. The 'Analyze' verb implies read-only, but this is not explicit.
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 organized with a clear one-line summary followed by a structured Args section. It is slightly verbose due to repeating defaults, but the structure makes it easy to scan. Every sentence earns its place, though the parameter details could be trimmed.
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?
Without an output schema, the description mentions the return contains 'punt strategy analysis, spending summary, and recommendations', but does not specify exact fields. It also lacks context on prerequisites (e.g., whether a draft must be in progress) or assumptions about league type (auction vs snake). This is adequate but has gaps.
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 description coverage is 0%, so the description must compensate, and it does excellently. Each parameter is explained with its optionality, environment variable fallback, and purpose (e.g., emspn_s2 and swid for private league auth). This adds significant meaning 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 'Analyze your current draft strategy and spending patterns', which is a specific verb+resource. It distinguishes from siblings like get_draft_status (which fetches status) and should_i_bid (which gives bidding advice) by focusing on overall strategy and spending analysis.
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 any guidance on when to use this tool versus the sibling analysis tools. It lacks explicit exclusions or alternative recommendations, so an agent would not know if this is the right tool for a given task.
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 transparency burden. It usefully discloses that all parameters are optional with environment variable fallbacks, and that espn_s2 and swid are authentication cookies for private leagues. It also states the return type. However, it does not mention potential side effects, limitations, or the nature of the recommendation logic, leaving some behavior implicit.
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 well-structured with a clear one-sentence purpose, an Args list, and a Returns line. It is appropriately sized for a tool with 5 parameters. Minor repetition of the 'optional' pattern is acceptable but could be slightly tighter.
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 covers all inputs and states the return is a dictionary with recommendation and reasoning, but there is no output schema and the return format is vague. It does not explain what factors drive the recommendation or how it relates to the sibling tools. Given the tool's complexity and lack of annotations, more detail on expected outputs and selection context would improve completeness.
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 schema provides no descriptions (0% coverage), so the description must compensate. It does so thoroughly, explaining every parameter (team_id, league_id, year, espn_s2, swid), including their types, optionality, environment variable fallbacks, and purpose. This is a strong addition beyond the bare schema.
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's function: 'Get recommendation on which player to target/nominate next.' This provides a specific verb+resource combination that is distinct from siblings like get_free_agents or should_i_bid. However, it does not explicitly differentiate itself from similar analysis tools such as analyze_my_draft_strategy.
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 gives no guidance on when to use this tool versus alternatives. It does not mention suitable contexts, prerequisites, or exclusions. The name and brief description imply its use case, but there is no explicit 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?
With no annotations, the description carries the transparency burden but only partially. It discloses that parameters fall back to environment variables (e.g., ESPN_TEAM_ID), that cookies are needed for private leagues, and that it returns a dictionary with players and positions. However, it does not mention read-only nature explicitly, error cases, or any side effects, missing opportunities for richer behavioral context.
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 front-loaded with a one-sentence purpose, followed by a structured Args list and a Returns section. It is efficient for a 6-parameter tool, with no fluff. The Args list is necessary given the zero schema coverage, so the length is justified.
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?
Given there is no output schema, the description provides a return type ('Dictionary with team roster including all players and positions'), and covers all parameters. However, it lacks usage context (e.g., when to prefer this over get_available_players) and edge-case behavior, but for a simple roster-fetch tool it is relatively complete.
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 has 0% description coverage, and the description fully compensates by explaining each parameter's meaning, optionality, and env var defaults. For example, team_id is 'Team ID to get roster for', year defaults to 2025 if not provided, and espn_s2/swid are for private league authentication. This adds significant value beyond the raw 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 states 'Get roster for a specific team' with a clear verb and resource, and specifies the domain (ESPN Fantasy Basketball league). This distinguishes it from sibling tools like get_league_teams (lists teams) and get_available_players, as it focuses on a single team's roster.
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 on when to use this tool versus alternatives, nor any exclusions or context such as 'use for viewing active players'. The description only restates the purpose and parameter definitions, leaving the agent to infer appropriate usage from the name and siblings.
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 provided, the description carries the full burden of behavioral disclosure. It discloses authentication needs for private leagues (espn_s2, swid), environment variable fallbacks, and default behavior for size. It also states the return type (list of dictionaries). This is useful context beyond the schema, though it does not detail error conditions or rate limits.
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 appropriately structured with 'Args' and 'Returns' sections. It is somewhat lengthy but each sentence adds value, covering all parameters and return type without fluff. The use of bullets or separators would improve scannability, but it remains efficient.
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 (6 parameters, multiple env vars, optional auth) and the presence of an output schema, the description is complete enough for an agent to invoke it correctly. It covers all parameters, defaults, return structure, and mentions max size, leaving no critical gaps.
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 description coverage is 0%, so the description is the only source of parameter meaning. It fully compensates by explaining each of the 6 parameters: league_id, year, size, position_id, espn_s2, and swid, including optionality and env var usage. This is comprehensive and clear.
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 it retrieves free agents/waiver wire players from an ESPN Fantasy Basketball league, using a specific verb and resource. However, it does not explicitly distinguish this from the sibling tool 'get_available_players', which could overlap in functionality.
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 provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios like 'use for free agent pickups' or 'use get_available_players for a broader query'. The parameter defaults are noted, but usage context is absent.
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 mentions that espn_s2 and swid are for private leagues and describes the return value, but does not explicitly state that the operation is read-only, nor does it mention behavior on errors, invalid IDs, or authentication failures. The description adds some context but lacks explicit behavioral disclosure.
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 well-structured with a one-sentence summary followed by Args and Returns sections. It is concise, with no fluff, and each parameter is listed on its own line with clear semantics. Front-loaded with the main purpose.
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 6 parameters, no output schema, and no annotations, the description covers parameter semantics and high-level return value (dictionary with trade analysis, recommendation, and category impact). It could provide more detail on the returned structure or possible failure modes, but it is sufficiently complete for the complexity.
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 description coverage is 0%, but the description compensates fully by explaining each parameter: your_player_ids (players you trade away), their_player_ids (players you receive), league_id (optional with env var), year (optional with env var and default), and authentication cookies. It also clarifies the purpose of each parameter beyond type information, which is essential for correct use.
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 action ('Analyze a trade proposal') and resource (trade proposal). It distinguishes from sibling tools: none of the siblings specifically analyze trade proposals, making the purpose unambiguous.
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 when to use the tool (when analyzing a trade proposal) but does not explicitly contrast it with alternative tools or state exclusions. No mention of scenarios where another tool would be more appropriate.
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 clearly indicates a read operation ('Get') and describes the return type as a dictionary with draft status, picks, and state. It also notes authentication needs for private leagues via cookies, adding some context, but does not explicitly state it is read-only or discuss error behavior.
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 and well-structured: a single-purpose opening sentence, followed by a clear list of arguments and a returns statement. Every sentence adds value with no repetition or 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?
For a simple read-only status tool with four optional parameters and no output schema, the description covers the essential aspects: purpose, parameters, auth, and return type. It could provide more detail on what 'draft status' includes beyond picks and progress, but it is largely complete for this tool's complexity.
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 has zero descriptions, but the description fully compensates by explaining each parameter: league_id, year, espn_s2, and swid, including env var fallbacks, defaults, and purpose. This adds significant meaning 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 'Get current draft status including all picks and progress,' which is a specific verb-resource combination. It distinguishes from sibling tools focused on schedules, teams, rosters, free agents, and matchups.
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 use when you need draft status but provides no explicit guidance on when to use alternatives or when not to use this tool. It mentions optional parameters and env var fallbacks, giving some context, but lacks exclusionary guidance.
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 provided, the description carries the full burden of behavioral disclosure. It responsibly documents authentication requirements for private leagues (espn_s2, swid), environment variable fallbacks, and default year behavior, which are meaningful traits. However, it does not disclose error handling or what happens if a player lookup fails, and the Returns line is generic.
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 and well-structured: a one-line summary, followed by a compact Args list, and a brief Returns line. Every sentence serves a purpose, and the format is easy to scan for an AI agent.
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?
Given the tool's moderate complexity (6 params, no output schema, no annotations), the description covers all parameters and provides a high-level return type. However, the Returns description 'Dictionary with comprehensive player statistics across all categories' is vague about the actual structure, and there is no mention of potential errors or edge cases. This prevents a perfect score.
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 schema provides zero description coverage, but the description's Args section fully explains every parameter, including optionality, defaults, and possible values (e.g., timeframe enumerates 'season', 'projections', 'last_7', 'last_30'). This adds substantial meaning beyond the bare schema field names and compensates for the 0% schema coverage.
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 opening sentence 'Get comprehensive player statistics for specified timeframe' clearly states a specific action (get) and resource (player statistics) with a defined scope (timeframe). This distinguishes the tool from siblings like get_team_roster or get_nba_schedule, which serve different purposes.
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 provides no guidance on when to use this tool versus alternatives. It simply lists parameters without explaining typical use cases, prerequisites, or scenarios where another tool would be more appropriate. Sibling tools like compare_players or get_trending_players are not mentioned in any cross-referencing way.
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 provided, the description discloses important behavioral details: it explains optional parameters, env var fallback (ESPN_LEAGUE_ID, ESPN_YEAR), defaults (9-cat), and authentication requirements for private leagues (espn_s2, swid). However, it does not explicitly state that this is a read-only operation or describe error handling, but the read nature is evident from the verb 'compare.' This provides meaningful context beyond schema.
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 structured with an overall summary, Args list, and Returns mention. Each line adds value, but the list format makes it longer than necessary for a simple tool. Still, it is well-organized and not padded; a score of 4 reflects appropriate sizing with a slight efficiency loss from the docstring format.
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?
Given that there is no output schema and no annotations, the description covers all six parameters, their defaults, and auth, and summarizes the return as a dictionary with winner by category. It does not detail edge cases like invalid player IDs or what 'winner' means, but it is sufficient for the tool's moderate complexity.
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 schema has zero parameter descriptions (0% coverage), so the description's Args section is the sole source of parameter semantics. It explains player_ids as ESPN IDs, league_id with env var fallback, year with default, categories with default, and auth cookies—far exceeding schema info.
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 begins with a clear, specific verb phrase 'Compare multiple players across statistical categories,' identifying the resource (players) and scope (statistical categories). This distinguishes it from sibling tools like get_player_stats that focus on single players or league-level queries, and from advisory tools like analyze_trade_proposal.
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 usage by stating 'Compare multiple players,' but it offers no explicit guidance on when to choose this over alternatives. There is no mention of exclusions, such as 'use get_player_stats for a single player's stats.' Usage context is inferred rather than stated, earning a 3.
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 transparency burden. It explains env var fallbacks, optional authentication cookies for private leagues, and the return shape. However, it does not disclose potential errors or network behavior, but for a read operation this is adequate.
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 docstring is compact and structured with Args/Returns sections. Every sentence provides necessary information without 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 covers the tool's purpose, all parameters, auth for private leagues, and return data. It lacks error handling details but is complete for a simple read-all operation.
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%, so the description must explain all parameters. It does: league_id, year, espn_s2, swid, each with purpose, optionality, and env var defaults. This adds significant value beyond the schema's bare type definitions.
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 'Get all teams in an ESPN Fantasy Basketball league,' which clearly identifies the action and resource. This distinguishes it from siblings like get_team_roster (single team) and get_free_agents (different entity type).
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 use when needing all teams in a league but does not explicitly contrast with alternatives or state exclusions. It provides context on optional parameters and authentication but lacks clear 'use this instead of X' guidance.
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 default behavior (defaults to today) and return format, but does not explicitly state that this is a read-only operation or mention error handling for invalid dates. This is adequate but not rich.
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, using two short sentences and a clear Args/Returns structure. Every line adds value without unnecessary verbosity.
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 low complexity (one optional parameter) and the presence of an output schema, the description sufficiently covers the tool's behavior. It states the return type as a list of game dictionaries, which is enough for an agent to understand the tool's purpose.
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 provides only the type and default for the date parameter without any description. The tool description compensates by specifying the date format (YYYY-MM-DD) and the default behavior (defaults to today), adding meaningful semantics beyond 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 gets NBA schedules for a specific date, using the verb 'Get' with a specific resource ('NBA schedule'). It is distinct from siblings like get_league_teams, get_matchups, etc., which focus on different data types.
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 implies usage for retrieving schedule data for a given date, with an optional date parameter. It does not explicitly provide alternative tools or exclude cases, but the context is clear enough for an agent to select it over sibling tools.
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 discloses env var fallbacks and the use of auth cookies for private leagues, but does not explicitly state read-only behavior, error conditions, or limitations. This is partially transparent but not fully 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 well-structured with a clear purpose line, an Args section, and a Returns section. Every line provides valuable information without redundancy, making it appropriately concise and front-loaded.
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 covers the tool's purpose, all arguments, and the return shape, which is sufficient given the tool's moderate complexity and lack of output schema. It could add examples or edge-case details but is otherwise complete.
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 has 0% description coverage, but the description compensates by explaining all six parameters, including defaults, env var fallbacks, and purpose. This adds significant meaning beyond the schema's bare type definitions.
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 with a specific verb ('Get recommendation') and resource ('current player being nominated'). It distinguishes from sibling tools like who_should_i_target_next, which focuses on targeting rather than bidding.
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 implies usage during an auction nomination by referencing 'current player being nominated,' giving clear context. However, it does not explicitly mention when not to use it or compare with alternatives, leaving out exclusions.
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 provided, the description carries the full burden of behavioral disclosure. It covers authentication needs (ESPN_S2 and SWID cookies for private leagues), environment variable fallbacks, defaults, and the return format (list of player dictionaries with auction values and rankings). This provides meaningful transparency, though it omits potential errors or rate limits.
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 well-structured with a one-sentence purpose, an Args section, and a Returns section. It is appropriately sized for 5 parameters, with no redundant information or filler. Every sentence contributes to understanding the tool.
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 moderate complexity (5 optional parameters, env var fallbacks, auth requirements), the description is complete: it explains purpose, all parameters, defaults, authentication, and return values. The presence of an output schema further reduces the need to detail return structure, and the description adequately covers behavioral context for an agent to invoke the tool correctly.
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 has 0% description coverage, but the description fully documents all 5 parameters with clear semantics: ESPN league ID, season year, limit, and authentication cookies. It also explains env var fallbacks and defaults, adding substantial meaning beyond the raw 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 begins with a specific verb+resource: 'Get top available players for the draft with auction values.' This clearly states what the tool does and differentiates it from sibling tools like get_free_agents or get_trending_players by focusing on draft context and auction values.
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 usage for draft preparation and provides contextual details (e.g., optional league_id, env var fallbacks), but it does not explicitly state when to use this tool versus alternatives like get_free_agents or get_trending_players, nor does it mention exclusions. Usage context is implied rather than explicit.
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 provided, the description carries the burden of behavioral disclosure. It explains authentication requirements (espn_s2, swid) for private leagues, environment variable fallbacks, and the return format (list of matchup dictionaries). It does not mention error handling or rate limits, but for a read-only retrieval tool this is fairly 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 well-structured with a one-sentence purpose followed by a clean Args block and Returns line. Every line earns its place; there is no redundant text or 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?
Given moderate complexity (5 params) and an existing output schema, the description covers parameter semantics and return shape. It lacks explicit differentiation from sibling schedule tools, but overall provides sufficient context for an agent to invoke it correctly.
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 description coverage is 0%, so the description fully compensates by explaining every parameter: league_id and year fall back to env vars/defaults, scoring_period selects a specific period, and espn_s2/swid authenticate private leagues. This adds significant meaning 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 opens with 'Get matchups/schedule for an ESPN Fantasy Basketball league,' using a specific verb and resource. This clearly distinguishes it from siblings like get_nba_schedule by specifying 'Fantasy Basketball league' matchups.
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 implies usage for retrieving league matchups or schedules, and documents optional parameters including auth for private leagues. It does not explicitly state when to prefer this over siblings like get_nba_schedule or get_league_teams, but the context is clear enough for correct 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?
No annotations are provided, so the description carries the burden. It reveals that optional parameters fall back to environment variables, specifies defaults for year/direction/limit, and states the return structure (list of dicts with add/drop percentages). It does not discuss potential errors or rate limits, but for a read-only data-fetch tool this is adequate.
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 efficiently organized into a one-sentence summary, an Args list, and Returns section. No redundant text, and every line serves a purpose.
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 6-param tool with no required parameters and an output schema, the description covers all parameters, defaults, env var handling, authentication, and return type. It provides sufficient context for an agent to invoke the tool correctly.
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 explains every parameter with human-readable meaning, including optionality, env var fallbacks, and defaults, whereas the schema only lists types. It also clarifies the 'direction' allowed values and the meaning of 'limit'.
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?
Description clearly states a specific action ('Get players trending up or down in adds/drops') and purpose ('waiver wire intelligence'). This differentiates it from sibling tools like get_free_agents or get_player_stats.
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 'for waiver wire intelligence' conveys the intended use case but does not explicitly mention alternatives or when-not-to-use. It implies usage for tracking player add/drop momentum, which is reasonably clear.
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

Copy to your README.md:

[![espn-fantasy-basketball-mcp MCP server](https://glama.ai/mcp/servers/dylancharris/espn-fantasy-basketball-mcp/badges/card.svg)](https://glama.ai/mcp/servers/dylancharris/espn-fantasy-basketball-mcp)

Score Badge

Copy to your README.md:

[![espn-fantasy-basketball-mcp MCP server](https://glama.ai/mcp/servers/dylancharris/espn-fantasy-basketball-mcp/badges/score.svg)](https://glama.ai/mcp/servers/dylancharris/espn-fantasy-basketball-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/dylancharris/espn-fantasy-basketball-mcp'

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