sleeper_league_drafts

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is known. The description adds valuable context by disclosing the exact return shape, the fact that no auth is needed, and the one-per-season nuance for dynasty leagues. This goes beyond what annotations alone provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise yet information-dense: a clear purpose, a compact return specification, a minimal example, and an auth note. Every sentence earns its place, and key details are front-loaded. There is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list tool with a single parameter and no output schema, the description is highly complete. It provides the return structure, an example call, auth requirements, and domain-specific context about dynasty leagues. The agent can invoke the tool correctly and interpret results without needing additional information.

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

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

The only parameter, league_id, is fully described in the schema with 'League id. Required — part of the URL path.' The description adds a concrete example value and explains it is the league whose drafts are returned, but does not add significant semantic detail beyond the schema. With 100% schema coverage, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that this tool retrieves the drafts belonging to a league, with the return format giving exact fields such as draft_id, league_id, season, and type. It distinguishes from sibling tools like sleeper_draft and sleeper_draft_picks by focusing on the collection of drafts for a league, and the dynasty note adds specificity.

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

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

The description implies usage: call this when you need the list of drafts for a given league, and the dynasty league note clarifies when to expect one per season. It does not explicitly mention alternative tools, but the context and example provide clear when-to-use guidance. No exclusions or when-not-to-use cases are stated.

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