Skip to main content
Glama
yooitsgreg

sleeper-mcp

by yooitsgreg
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

sleeper-mcp

An MCP (Model Context Protocol) server for the Sleeper Fantasy Sports API. Gives Claude, Cursor, VS Code Copilot, and any other MCP-compatible AI client read access to Sleeper's public API — no API key required.

What you can do

Ask your AI assistant things like:

  • "What leagues am I in this season?" (give it your Sleeper username)

  • "Show me the standings and rosters for my league"

  • "Who won the championship bracket?"

  • "What trades happened this week?"

  • "Which players are being added the most right now?"

  • "Show me all first-round draft picks from my 2024 draft"

Related MCP server: sleeper-caffeine MCP

Available Tools

Tool

Description

sleeper_get_user

Look up a user's profile by username or user ID

sleeper_get_nfl_state

Current NFL week, season type, and season year

sleeper_get_user_leagues

All leagues a user is in for a given sport/season

sleeper_get_league

Full league details including scoring and roster settings

sleeper_get_league_rosters

All rosters with win/loss records and player lists

sleeper_get_league_users

All managers in a league with their team names

sleeper_get_league_matchups

Weekly matchup scores for any week

sleeper_get_league_winners_bracket

Playoff championship bracket

sleeper_get_league_losers_bracket

Consolation / toilet bowl bracket

sleeper_get_league_transactions

Trades, waiver claims, and FA adds/drops by week

sleeper_get_league_traded_picks

All traded draft picks in a league

sleeper_get_user_drafts

All drafts a user participated in

sleeper_get_league_drafts

All drafts for a league

sleeper_get_draft

Full draft details (type, order, slot mapping)

sleeper_get_draft_picks

Every pick in a draft with player and position info

sleeper_get_draft_traded_picks

Picks that were traded within a draft

sleeper_get_nfl_players

Full NFL player database with filtering by position, team, or name

sleeper_get_trending_players

Most-added or most-dropped players over a time window

Prerequisites

  • Node.js 18+ — download — OR — Bun — download

  • A Sleeper account is helpful but not required (the API is fully public)

Installation

git clone https://github.com/yooitsgreg/sleeper-mcp.git
cd sleeper-mcp

# pick your package manager:
npm install   # or: pnpm install / yarn / bun install

The install triggers a prepare hook that compiles TypeScript to dist/. No separate build step needed.

Configuration

Pick the section for your AI client.

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "sleeper": {
      "command": "node",
      "args": ["/absolute/path/to/sleeper-mcp/dist/index.js"]
    }
  }
}

Claude Code (CLI)

Edit ~/.claude/claude.json:

{
  "mcpServers": {
    "sleeper": {
      "command": "node",
      "args": ["/absolute/path/to/sleeper-mcp/dist/index.js"]
    }
  }
}

VS Code (GitHub Copilot / MCP extension)

Create or edit .vscode/mcp.json in your workspace:

{
  "servers": {
    "sleeper": {
      "type": "stdio",
      "command": "node",
      "args": ["/absolute/path/to/sleeper-mcp/dist/index.js"]
    }
  }
}

Cursor

Edit ~/.cursor/mcp.json:

{
  "mcpServers": {
    "sleeper": {
      "command": "node",
      "args": ["/absolute/path/to/sleeper-mcp/dist/index.js"]
    }
  }
}

After editing the config, restart your AI client.

Development

npm run dev     # watch mode (tsx), recompiles on save
npm run build   # compile TypeScript → dist/
npm run clean   # remove dist/

Project structure

src/
├── index.ts              # Entry point — wires up McpServer + StdioServerTransport
├── constants.ts          # API base URL, timeouts, character limits
├── types.ts              # TypeScript interfaces for all Sleeper API responses
├── services/
│   └── sleeperClient.ts  # Shared axios client and error handler
└── tools/
    ├── users.ts          # sleeper_get_user
    ├── leagues.ts        # All league tools (9 tools)
    ├── drafts.ts         # All draft tools (5 tools)
    ├── players.ts        # sleeper_get_nfl_players, sleeper_get_trending_players
    └── state.ts          # sleeper_get_nfl_state

Notes

  • No authentication required — Sleeper's API is free and public.

  • Rate limit — Sleeper asks that you stay under 1,000 requests/minute.

  • sleeper_get_nfl_players fetches ~5 MB of data. Use the position_filter, team_filter, or search parameters to keep responses manageable. Sleeper recommends caching this data and only refreshing once per day.

  • All tools are read-only — this server never writes to Sleeper.

License

MIT

Available Tools

18 tools
sleeper_get_draftGet Draft DetailsA
Read-onlyIdempotent

Get detailed information about a specific Sleeper fantasy draft.

Args:

  • draft_id (string): The Sleeper draft ID

Returns: Full draft details: type, status, rounds, slot-to-roster mapping, draft order, settings.

Examples:

  • "Show details for draft 987654321"

  • "What type of draft is this and how many rounds?"

ParametersJSON Schema
NameRequiredDescriptionDefault
draft_idYesSleeper draft ID

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, fully covering safety. The description adds behavioral context by listing returned fields (type, status, rounds, etc.), which goes beyond what annotations offer.

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: one sentence for purpose, then an Args section, Returns section, and examples. Every part adds value, and it is front-loaded with the main action.

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 simplicity (one required parameter), rich annotations, and no output schema, the description fully covers what the tool does and returns. The listed return fields provide sufficient context for an agent.

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

Parameters3/5

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

Schema coverage is 100% with a description for draft_id. The description repeats the schema information ('draft_id (string): The Sleeper draft ID') but adds no new semantics beyond examples. With full schema coverage, baseline 3 is appropriate.

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 detailed information about a specific Sleeper fantasy draft,' which uses a specific verb and resource. It distinguishes from sibling tools like sleeper_get_draft_picks and sleeper_get_league_drafts by focusing on a single draft's details.

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 examples illustrating when to use the tool (e.g., 'Show details for draft 987654321'). While it doesn't explicitly state when not to use or list alternatives, the context from sibling tool names and the single required parameter make usage clear.

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

sleeper_get_draft_picksGet Draft PicksA
Read-onlyIdempotent

Get all picks made in a specific Sleeper fantasy draft, in order.

Args:

  • draft_id (string): The Sleeper draft ID

  • round_filter (number, optional): Filter results to a specific round only

Returns: All picks in pick order: round, pick number, player, position, team, and who picked them.

Examples:

  • "Show all picks from draft 987654321"

  • "What were the first-round picks?"

  • "Who did roster 5 draft?"

ParametersJSON Schema
NameRequiredDescriptionDefault
draft_idYesSleeper draft ID
round_filterNoOptional: only return picks from this round

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, so safety is clear. Description adds return format details: 'round, pick number, player, position, team, and who picked them.' No contradictions.

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?

Concise, front-loaded purpose, structured with Args, Returns, Examples. Every sentence is impactful.

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?

Low complexity tool with 2 params and no output schema. Description covers purpose, parameters, return structure, and examples. Lacks error info but annotations provide openness.

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

Parameters3/5

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

Schema coverage is 100%, description repeats parameter info but adds examples and clarifies types. Adds marginal value beyond 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?

Clearly states 'Get all picks made in a specific Sleeper fantasy draft, in order.' The verb, resource, and scope are specific. Distinguishes from siblings like sleeper_get_draft_traded_picks.

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?

Provides examples showing typical queries (all picks, first-round picks, by roster). Implicitly differentiates from siblings but lacks explicit when-not-to-use or alternative mentions.

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

sleeper_get_draft_traded_picksGet Draft Traded PicksA
Read-onlyIdempotent

Get all picks that were traded within a specific Sleeper draft.

Args:

  • draft_id (string): The Sleeper draft ID

Returns: All traded picks: round, original owner roster, and current owner roster.

Examples:

  • "What picks were traded in draft 987654321?"

  • "Show pick trades from this draft"

ParametersJSON Schema
NameRequiredDescriptionDefault
draft_idYesSleeper draft ID

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare the tool as read-only and idempotent. The description adds behavioral context by specifying the returned fields (round, original owner roster, current owner roster), which goes beyond the annotation information. No contradictions.

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 with a clear structure: purpose, arguments, returns, and examples. Every sentence adds value, and there is no redundant or filler content.

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 simplicity (single parameter, read-only, no output schema), the description sufficiently covers purpose, parameter usage, return values, and example queries. No additional information is necessary for an agent to use it correctly.

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?

Schema coverage is 100%, so baseline is 3. The description adds examples of usage that illustrate the parameter's role ('What picks were traded in draft 987654321?'), providing practical context beyond the schema description.

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 'all picks that were traded within a specific Sleeper draft', using a specific verb and resource. It distinguishes itself from the sibling tool 'sleeper_get_draft_picks' (which presumably gets all picks) by explicitly focusing on traded picks.

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 provides clear examples of when to use the tool (e.g., 'What picks were traded in draft 987654321?'), but it does not explicitly state when not to use it or mention alternative tools. The usage context is implied but lacks explicit comparative guidance.

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

sleeper_get_leagueGet League DetailsA
Read-onlyIdempotent

Fetch detailed information about a specific Sleeper fantasy league.

Args:

  • league_id (string): The Sleeper league ID

Returns: Full league details: name, status, settings, scoring settings, roster positions, and more.

Examples:

  • "Get details for league 123456789"

  • "What are the scoring settings for this league?"

ParametersJSON Schema
NameRequiredDescriptionDefault
league_idYesSleeper league ID

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint. Description adds that it returns 'full league details' and lists key fields, enhancing transparency about the response.

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?

Well-structured with Args, Returns, and Examples sections. Information is front-loaded and every sentence adds value.

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 explains the return fields, compensating for the lack of an output schema. It is sufficient for a simple tool with one parameter, though it could mention the league_id format.

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

Parameters3/5

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

Schema coverage is 100% for the single parameter. Description repeats the parameter name and type but does not add new semantic meaning 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?

Clearly states 'Fetch detailed information about a specific Sleeper fantasy league', with a specific verb and resource. The resource is distinct from siblings like sleeper_get_league_rosters or sleeper_get_league_drafts.

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?

Provides examples but no explicit guidance on when to use this tool versus alternatives like sleeper_get_league_rosters. Usage context is implied but not clarified.

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

sleeper_get_league_draftsGet League DraftsA
Read-onlyIdempotent

Get all drafts that have taken place in a Sleeper fantasy league.

Args:

  • league_id (string): The Sleeper league ID

Returns: All drafts for the league with type, status, rounds, and timing.

Examples:

  • "What drafts have happened in league 123456?"

  • "Get the draft history for this league"

ParametersJSON Schema
NameRequiredDescriptionDefault
league_idYesSleeper league ID

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, etc. The description adds that it returns 'type, status, rounds, and timing' but does not disclose additional behavioral traits (e.g., pagination, data recency). With annotations covering safety, a 3 is appropriate.

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 with clear sections (Args, Returns, Examples) and no fluff. Every sentence provides value.

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 simple single-parameter retrieval task, rich annotations, and no output schema, the description adequately covers what the tool returns (type, status, rounds, timing) and examples. It is complete for agent decision-making.

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

Parameters3/5

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

Schema coverage is 100% for league_id. The description repeats 'The Sleeper league ID' with no added meaning (e.g., format, source). Baseline 3 is justified as schema does the heavy lifting.

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 all drafts that have taken place in a Sleeper fantasy league,' using a specific verb and resource. It distinguishes from siblings like sleeper_get_draft (single draft) and sleeper_get_draft_picks (picks of a draft). Examples reinforce the purpose.

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 provides examples but does not explicitly guide when to use this tool versus alternatives (e.g., sleeper_get_draft for a specific draft, sleeper_get_user_drafts for user-level drafts). The context is implied but not differentiated.

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

sleeper_get_league_losers_bracketGet League Losers BracketA
Read-onlyIdempotent

Get the consolation/toilet bowl (losers bracket) for a Sleeper fantasy league.

Args:

  • league_id (string): The Sleeper league ID

Returns: Losers bracket structure showing consolation matchups and results.

Examples:

  • "Show me the toilet bowl bracket for league 123456"

  • "Who came in last place?"

ParametersJSON Schema
NameRequiredDescriptionDefault
league_idYesSleeper league ID

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description's behavioral disclosure adds minimal new information (the return structure includes matchups and results). No contradiction exists.

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, with clear sections (Args, Returns, Examples) and no extraneous text. Every sentence adds value, and the format is easy to parse.

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 low complexity (one parameter, clear annotations, no nested objects or output schema), the description provides all necessary information: purpose, parameter specification, return type, and example usage.

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?

Although schema description coverage is 100%, the description adds value by clarifying the parameter's role through examples and the Args section, making its semantics more concrete than the minimal schema description 'Sleeper league ID'.

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 ('Get') and explicitly defines the resource as 'consolation/toilet bowl (losers bracket)', clearly distinguishing it from the sibling tool 'sleeper_get_league_winners_bracket' by naming and context.

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 provides examples ('Show me the toilet bowl bracket' and 'Who came in last place?') that imply usage context, but it does not explicitly state when to use this tool versus alternatives like the winners bracket, nor does it provide exclusions or prerequisites.

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

sleeper_get_league_matchupsGet League MatchupsA
Read-onlyIdempotent

Get all matchups for a specific week in a Sleeper fantasy league.

Args:

  • league_id (string): The Sleeper league ID

  • week (number): NFL week number (1-18 for regular season)

Returns: All matchups for the week: roster IDs, points, starters, and player scores.

Examples:

  • "What are the matchups for week 5 in league 123456?"

  • "Show me all scores for week 12"

ParametersJSON Schema
NameRequiredDescriptionDefault
weekYesNFL week number (1-18)
league_idYesSleeper league ID

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already provide a strong safety profile (readOnlyHint, idempotentHint, destructiveHint false). The description adds value by specifying the return fields ('roster IDs, points, starters, and player scores') without contradicting annotations.

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 with two short paragraphs plus examples. Every sentence adds value, and the purpose is 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?

For a simple query tool with two parameters and no output schema, the description adequately explains the return fields and usage. It could mention pagination or error handling, but it is reasonably complete.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already describes both parameters. The description only restates them in an Args section and adds examples, which provides minimal additional meaning 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 'Get all matchups for a specific week in a Sleeper fantasy league' with a specific verb and resource. It distinguishes from sibling tools which cover different Sleeper functions like drafts, rosters, or users.

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?

Examples show typical use cases like 'What are the matchups for week 5 in league 123456?' and 'Show me all scores for week 12'. While it doesn't explicitly say when not to use, the context makes the purpose clear and distinct from siblings.

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

sleeper_get_league_rostersGet League RostersA
Read-onlyIdempotent

Get all rosters in a Sleeper fantasy league, including players, starters, and standings.

Args:

  • league_id (string): The Sleeper league ID

Returns: All rosters with owner IDs, player lists, and win/loss records.

Examples:

  • "Show me all rosters in league 123456"

  • "What players does roster 3 have?"

ParametersJSON Schema
NameRequiredDescriptionDefault
league_idYesSleeper league ID

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destrcutiveHint=false, idempotentHint=true, openWorldHint=true. The description adds that it returns owner IDs, player lists, and win/loss records, but does not disclose additional behavioral traits beyond what the annotations imply.

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 concise, with a clear opening sentence, structured Args/Returns/Examples sections. It is front-loaded and contains no unnecessary text, though examples could be slightly more informative.

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 simplicity (single parameter, read-only) and the annotations covering safety, the description adequately explains what is returned and provides examples. Lacks mention of pagination or rate limits, but these are not critical for this tool.

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

Parameters3/5

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

Schema coverage is 100% for the single parameter league_id, which already has a description 'Sleeper league ID'. The description merely repeats this without adding new semantic meaning, so baseline score of 3 is appropriate.

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 all rosters in a Sleeper fantasy league, including players, starters, and standings. It uses a specific verb and resource, and its purpose is distinct from sibling tools like sleeper_get_league or sleeper_get_league_users.

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 provides examples showing when to use the tool ('Show me all rosters'), but does not explicitly mention when not to use it or contrast with alternatives. No guidance on using sibling tools.

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

sleeper_get_league_traded_picksGet League Traded PicksA
Read-onlyIdempotent

Get all traded draft picks in a Sleeper fantasy league (across all seasons).

Args:

  • league_id (string): The Sleeper league ID

Returns: All traded picks with season, round, original owner, and current owner.

Examples:

  • "What draft picks have been traded in league 123456?"

  • "Which future picks does roster 3 own?"

ParametersJSON Schema
NameRequiredDescriptionDefault
league_idYesSleeper league ID

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds the return fields (season, round, original owner, current owner) but does not disclose additional behavioral traits like error handling 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 well-structured with a purpose sentence, Args, Returns, and Examples sections. It is clear but slightly redundant because Args/Returns repeat schema info. Overall concise for a simple tool.

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 tool with one parameter, the description adequately covers return fields and provides examples. It lacks error conditions or distinction from a similar sibling tool, but given low complexity, it is sufficiently complete.

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

Parameters3/5

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

Schema description coverage is 100% for the lone parameter 'league_id', and the description repeats the same meaning. The examples provide usage context but no additional semantic detail beyond what the 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 verb 'Get' and the resource 'all traded draft picks in a Sleeper fantasy league (across all seasons)', which is specific and distinguishes it from siblings like sleeper_get_draft_picks.

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 provides examples that imply usage contexts (e.g., 'What draft picks have been traded in league 123456?') but does not explicitly state when to use this tool versus alternatives like sleeper_get_draft_traded_picks, leaving some ambiguity.

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

sleeper_get_league_transactionsGet League TransactionsA
Read-onlyIdempotent

Get all transactions (trades, waiver claims, free agent adds/drops) for a specific round/week in a league.

Args:

  • league_id (string): The Sleeper league ID

  • round (number): The transaction round (corresponds to NFL week number)

Returns: List of transactions with type (trade/waiver/free_agent), adds, drops, traded picks, and status.

Examples:

  • "What trades happened in week 8 in league 123456?"

  • "Show all waiver claims for round 3"

ParametersJSON Schema
NameRequiredDescriptionDefault
roundYesTransaction round (week number)
league_idYesSleeper league ID

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, etc. The description adds useful behavioral context beyond annotations, such as the return format (list with type, adds, drops, etc.) and mapping of round to NFL week. No contradictions.

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 brief purpose statement, bulleted args, returns, and examples. Every sentence adds value with no filler.

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 simple read tool with 2 parameters, full schema coverage, and informative annotations, the description provides a complete picture of what the tool does and returns, including examples. No gaps.

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

Parameters3/5

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

Schema coverage is 100% with basic descriptions. The main description adds minimal extra information (e.g., round corresponds to NFL week, examples). Baseline 3 is appropriate as the schema already documents the parameters adequately.

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 all transactions for a specific round/week in a league, listing types like trades, waiver claims, and free agent adds/drops. It is distinct from sibling tools like sleeper_get_league_traded_picks which focus on traded picks only.

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 explicit context on when to use (e.g., 'Get all transactions for a specific round/week') and includes examples like 'What trades happened in week 8?'. However, it does not explicitly state when not to use this tool or mention alternatives, so it is slightly lacking in exclusion guidance.

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

sleeper_get_league_usersGet League UsersA
Read-onlyIdempotent

Get all users (managers) in a Sleeper fantasy league with their team names and metadata.

Args:

  • league_id (string): The Sleeper league ID

Returns: List of users with user IDs, display names, team names, and avatar IDs.

Examples:

  • "Who are the managers in league 123456?"

  • "List all teams in this league"

ParametersJSON Schema
NameRequiredDescriptionDefault
league_idYesSleeper league ID

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it returns a list of users with specific fields (user IDs, display names, team names, avatar IDs), which is helpful beyond the annotations. It does not contradict annotations.

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 very concise with a clear structure: one sentence for purpose, then 'Args', 'Returns', and 'Examples' sections. No unnecessary information, front-loaded with the main action.

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 simple tool (1 parameter, no output schema), the description fully explains what the tool returns and includes examples. Combined with annotations, it provides a complete understanding for correct invocation.

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

Parameters3/5

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

Schema description coverage is 100% (league_id described in schema). The description only restates 'The Sleeper league ID' without adding new semantics. Baseline score of 3 is appropriate since schema already covers the parameter meaning.

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 action ('Get all users'), the resource ('in a Sleeper fantasy league'), and the scope ('with their team names and metadata'). This distinguishes it from sibling tools like sleeper_get_league (league info) or sleeper_get_league_rosters (rosters).

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?

Examples provide context for when the tool is used (e.g., 'Who are the managers in league 123456?'). While it doesn't explicitly say when not to use or mention alternatives, the purpose is clear enough that an agent can infer appropriate use cases.

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

sleeper_get_league_winners_bracketGet League Winners BracketA
Read-onlyIdempotent

Get the playoff winners bracket (championship bracket) for a Sleeper fantasy league.

Args:

  • league_id (string): The Sleeper league ID

Returns: Bracket structure showing playoff matchups, rounds, and results.

Examples:

  • "Show me the playoff bracket for league 123456"

  • "Who won the championship in this league?"

ParametersJSON Schema
NameRequiredDescriptionDefault
league_idYesSleeper league ID

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as false. The description adds value by detailing the return type ('Bracket structure showing playoff matchups, rounds, and results'), which goes beyond annotations.

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 with clear sections (Args, Returns, Examples). Every sentence serves a purpose without fluff.

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 simple tool with one parameter and no output schema, the description is complete. It explains what the tool does, what it returns, and provides examples.

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

Parameters3/5

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

The input schema covers 100% of parameters with a description for league_id. The description repeats this information but does not add new semantic meaning 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 action 'Get the playoff winners bracket' and specifies 'for a Sleeper fantasy league'. It differentiates from the sibling tool 'sleeper_get_league_losers_bracket' by using the term 'winners bracket'.

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?

While not explicitly stating when not to use, the description implies usage for retrieving the championship bracket. Examples provide context for when to invoke this tool (e.g., 'Show me the playoff bracket'). No explicit alternatives are given, but sibling names clarify.

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

sleeper_get_nfl_playersGet All NFL PlayersA
Read-onlyIdempotent

Fetch the complete NFL player database from Sleeper (~5MB). Returns all player metadata. NOTE: This is a large dataset. Use filters to narrow results. Sleeper recommends caching this data and only fetching once per day.

Args:

  • position_filter (string, optional): Filter by position (e.g. "QB", "RB", "WR", "TE", "K", "DEF")

  • team_filter (string, optional): Filter by NFL team abbreviation (e.g. "KC", "SF", "DAL")

  • active_only (boolean): Only return active players (default: true)

  • search (string, optional): Filter by player name (case-insensitive substring match)

  • limit (number): Max players to return (default: 50, max: 200)

  • offset (number): Pagination offset (default: 0)

Returns: Paginated list of players with id, name, position, team, status.

Examples:

  • "List all active QBs"

  • "Find players on the Kansas City Chiefs"

  • "Search for players named 'Patrick'"

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax players to return
offsetNoPagination offset
searchNoCase-insensitive substring match on player name
active_onlyNoOnly return active players
team_filterNoFilter by NFL team abbreviation (e.g. KC, SF, DAL)
position_filterNoFilter by position: QB, RB, WR, TE, K, DEF, etc.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by disclosing the ~5MB size, caching recommendation, and return fields (id, name, position, team, status). No contradictions.

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 main sentence, a note, then structured Args, Returns, and Examples sections. It is front-loaded and each section earns its place, though slightly lengthy.

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 no output schema, the description fully explains return fields and pagination. It covers size, caching, and filter usage. All important aspects for a data-fetching tool with 6 parameters are addressed.

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

Parameters3/5

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

Input schema has 100% coverage with descriptions for all 6 parameters. The description repeats them in an Args list and adds usage examples, providing minor additional clarity but no new semantic meaning 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 fetches the complete NFL player database from Sleeper and returns all player metadata. It distinguishes itself from sibling tools as the only player-fetching tool. The size and caching note add specificity.

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 large dataset size and recommends using filters and caching once per day. It implies usage context but does not directly compare with alternatives, though no alternative player tools exist.

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

sleeper_get_nfl_stateGet NFL StateA
Read-onlyIdempotent

Retrieve the current NFL season state including the active week, season type, and season dates. Useful for knowing what week it is, whether we're in preseason/regular/postseason, and which season year is active.

Returns: Current week, season type (pre/regular/post), season year, season start date, display week.

Examples:

  • "What week is it in the NFL?"

  • "Is the NFL season currently active?"

  • "What is the current NFL season year?"

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by listing the specific fields returned (week, season type, year, etc.), aligning with the read-only and idempotent nature.

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 summary, usage tips, and return fields. Slightly verbose with the examples paragraph, but overall 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?

Fully complete for a parameterless tool: explains the purpose, usage context, and return values in enough detail. No output schema exists, but the description compensates adequately.

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?

No parameters exist, so the description does not need to explain them. Baseline 4 is appropriate per rubric for zero parameters.

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 verb 'Retrieve' and the specific resource 'current NFL season state', and distinguishes from sibling tools that deal with leagues, drafts, or user data.

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?

Provides clear use cases and example questions, but does not explicitly mention when not to use it or alternatives. However, given that it has no parameters and is self-contained, the exclusion is less critical.

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

sleeper_get_userGet Sleeper UserA
Read-onlyIdempotent

Retrieve a Sleeper user's profile by their username or user ID.

Args:

  • identifier (string): The username (e.g. "john_doe") or numeric user ID (e.g. "12345678")

Returns: User profile including user_id, username, display_name, and avatar.

Examples:

  • "Get user info for username 'sleeperuser'"

  • "Look up user ID 123456789"

ParametersJSON Schema
NameRequiredDescriptionDefault
identifierYesSleeper username or numeric user ID

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already indicate read-only and idempotent behavior. The description adds that the tool returns specific fields (user_id, username, display_name, avatar) and explains the dual nature of the identifier, providing behavioral clarity beyond annotations.

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 separate sections for args, returns, and examples, and every sentence adds value without redundancy.

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 simple tool with one parameter and no output schema, the description fully explains input and expected output, making it complete for an agent to use.

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?

With 100% schema coverage, baseline is 3. The description enhances meaning by clarifying that 'identifier' accepts either username or numeric user ID and provides concrete examples.

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 verb 'retrieve' and resource 'Sleeper user's profile', and distinguishes itself from sibling tools by focusing on user profile 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 specifies that the identifier can be a username or numeric user ID, provides examples, and implies usage context without explicitly excluding alternatives.

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

sleeper_get_user_draftsGet User's DraftsA
Read-onlyIdempotent

Get all drafts a user has participated in for a given sport and season.

Args:

  • user_id (string): Sleeper user ID

  • sport (string): Sport (default: "nfl")

  • season (string): Season year (e.g. "2024")

Returns: List of drafts with draft ID, type, status, and league ID.

Examples:

  • "What drafts did user 123456 do in 2024?"

  • "Show all NFL drafts for this user"

ParametersJSON Schema
NameRequiredDescriptionDefault
sportNoSport (default: nfl)nfl
seasonYesSeason year, e.g. '2024'
user_idYesSleeper user ID

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds value by specifying the return format (list of drafts with fields) and constraints (sport default, season format). No contradictions.

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-structured with clear sections (summary, args, returns, examples), and front-loaded with the core purpose. Every sentence adds value 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 is complete enough for a simple list retrieval tool, given no output schema. It lists returned fields and provides examples. Minor omission: no mention of pagination or sorting, but likely not needed for drafts.

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?

Input schema covers 100% of parameters with descriptions. The description adds examples and clarifies the season format (e.g., '2024'), which aids understanding beyond the schema alone.

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 ('get') and resource ('drafts'), and clearly scopes to user participation for a given sport and season. This distinguishes it from sibling tools like sleeper_get_draft (single draft) and sleeper_get_league_drafts (league drafts).

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 alternatives or provide exclusion criteria. While the examples imply usage for user-specific draft queries, no direct guidance is given to help an agent differentiate it from similar tools.

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

sleeper_get_user_leaguesGet User's LeaguesA
Read-onlyIdempotent

Get all fantasy leagues a user is in for a given sport and season.

Args:

  • user_id (string): The Sleeper user ID (use sleeper_get_user to look up by username)

  • sport (string): Sport to filter by (default: "nfl")

  • season (string): Season year (e.g. "2024", "2025")

Returns: List of leagues including league name, ID, status, roster count, and scoring type.

Examples:

  • "What leagues is user 123456 in for the 2024 season?"

  • "Show all NFL leagues for user ID 987654321"

ParametersJSON Schema
NameRequiredDescriptionDefault
sportNoSport (default: nfl)nfl
seasonYesSeason year, e.g. '2024'
user_idYesSleeper user ID

TDQS

A4.5/5.0
Behavior4/5

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

Annotations indicate readOnlyHint, idempotentHint, and destructiveHint false. The description adds value by specifying the return format (list of leagues with fields) beyond what annotations provide. No contradictions.

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 summary, Args, Returns, and Examples sections. Every sentence is informative, and the format is easy to parse.

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 simple query tool with three parameters, the description covers all necessary aspects: purpose, parameter details, return structure, and usage examples. No output schema needed as return is explained.

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?

Schema description coverage is 100%, meeting baseline. The description adds meaningful context: for user_id, suggests using sleeper_get_user; for sport, states default 'nfl'; for season, provides example years. This enhances agent understanding.

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 all fantasy leagues a user is in for a given sport and season,' specifying the verb, resource, and scope. It lists parameters and return fields, distinguishing it from siblings like sleeper_get_league.

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 for when to use the tool, including a hint to use sleeper_get_user for user ID lookup. It does not explicitly state when not to use, but examples and parameter details make the usage clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 18 tool updatesv1.0.0
    • First observedsleeper_get_draft
    • First observedsleeper_get_draft_picks
    • First observedsleeper_get_draft_traded_picks
    • First observedsleeper_get_league
    • First observedsleeper_get_league_drafts
    • First observedsleeper_get_league_losers_bracket
    • First observedsleeper_get_league_matchups
    • First observedsleeper_get_league_rosters
    • First observedsleeper_get_league_traded_picks
    • First observedsleeper_get_league_transactions
    • First observedsleeper_get_league_users
    • First observedsleeper_get_league_winners_bracket
    • First observedsleeper_get_nfl_players
    • First observedsleeper_get_nfl_state
    • First observedsleeper_get_trending_players
    • First observedsleeper_get_user
    • First observedsleeper_get_user_drafts
    • First observedsleeper_get_user_leagues
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose, covering different aspects of Sleeper fantasy football such as user, league, draft, player, and league operations. There is no ambiguity or overlap between tool functionalities.

Naming Consistency5/5

All tool names follow a consistent 'sleeper_get_<resource>' pattern using snake_case. The naming is uniform and predictable, with clear hierarchy for sub-resources like 'sleeper_get_draft_picks'.

Tool Count5/5

With 18 tools, the server is well-scoped for its purpose. It covers a broad but focused set of functionalities for Sleeper fantasy football, without being overwhelming or too sparse.

Completeness5/5

The tool set provides comprehensive coverage of core Sleeper fantasy football operations: user management, league details, rosters, matchups, transactions, brackets, drafts, and NFL player data. No obvious gaps exist for typical use cases.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • sleeper-mcp

    draffetseder
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI models to manage and query fantasy sports leagues through the Sleeper API, supporting tasks like player lookups, league activity, and draft management.
    71
    MIT

  • sleeper-caffeine MCP

    chadnickbok
    A
    license
    Not graded
    quality
    B
    maintenance
    Provides read-only access to Sleeper fantasy football leagues, enabling team snapshots, available players, matchups, trade context, and league history through standardized MCP tools.
    MIT

  • Sleeper Fantasy Football MCP

    rajn1
    A
    license
    A
    quality
    C
    maintenance
    A read-only MCP server that supplies live context from Sleeper fantasy-football leagues, including rosters, trade analysis, draft picks, and league settings via Sleeper's public API.
    11
    MIT

  • sleeper-mcp

    tweiss777
    F
    license
    A
    quality
    C
    maintenance
    Enables read-only access to Sleeper fantasy sports data, including users, leagues, rosters, matchups, transactions, drafts, players, trending activity, playoff brackets, traded picks, and sport state via MCP tools.
    18
    -

Latest Blog Posts

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/yooitsgreg/sleeper-mcp'

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