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

With no annotations, the description carries the burden and does disclose key behaviors: data source (cached dictionary minus picks), sorting (search_rank), and default filters. However, it does not mention cache staleness, potential pagination, or that limit defaults to 40, leaving some behavioral aspects undisclosed.

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?

Two dense sentences provide high-value information without filler. Every sentence adds functional detail: data source, computation, sorting, and default exclusions.

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 list-with-filters tool with no output schema, the description explains the core behavior, default filtering, and sorting. It lacks explicit statement about the return type (player list) but that is inferable. Overall sufficient for correct invocation.

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?

Schema description coverage is 67%, so some parameters (limit, draft_id) lack schema descriptions. The description does not explain limit or draft_id, but it does clarify the meaning of include_idp and include_unranked via defaults. It partially compensates but does not fully cover the undocumented parameters.

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?

Description clearly states the action: fetching players not yet drafted in this draft, computed from the cached dictionary minus picks. It adds sorting and default filtering details that distinguish it from siblings like get_draft_picks or get_trending_players.

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 specifies default behavior (fantasy positions only, drops unranked players) and context (during a draft, available players). It does not explicitly mention when to prefer this over siblings, but the tool's purpose is self-evident and no alternative routing is ambiguous enough to require exclusion.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It details what fields are returned, which is helpful, but it doesn't mention whether this is a read-only operation (likely safe), what happens if no draft exists, or any rate limits or side effects. It adds reasonable contextual value but leaves some behavioral gaps given no annotations.

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 a single, dense sentence that front-loads the main resource (draft settings) and enumerates the specific fields returned. Every clause adds information, and there is no fluff or repetition. It is well-structured and efficient.

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?

Given that there is no output schema and no annotations, the description does a solid job of listing the return contents and clarifying the draft_id vs league_id fallback behavior. Minor missing context includes the default behavior when neither parameter is provided (likely 400 or error) and whether the operation is read-only, but overall it is fairly complete for a metadata retrieval tool.

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?

Schema description coverage is 50%: draft_id is well-documented, but league_id has no description. The description explains that league_id targets the league's most recent draft implicitly, but doesn't add much beyond the schema for draft_id. The tool description does clarify the relationship between draft_id and league_id, which helps, but league_id semantics remain thin.

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 the tool retrieves draft settings, lists specific fields (draft type, status, team count, rounds, third-round-reversal flag, slot->roster->owner mapping, required starting slots), and mentions an explicit draft_id or league default. It distinguishes itself from siblings like get_draft_picks by focusing on metadata and settings, making its purpose unmistakable.

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 context: it returns draft settings for a league's most recent draft or a specific draft via draft_id. It does not explicitly state when to use this over siblings like get_league or get_draft_picks, nor does it mention prerequisites or exclusions. The context is clear but lacks explicit alternative guidance.

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

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. It reveals that player data is resolved from a cached player dictionary with fallback to pick metadata, hinting at potential data staleness, and it specifies a polling interval. This is useful context, though it omits any explicit statement of side-effect freedom or response details.

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?

Two sentences, each carrying essential information: the result type, the polling guidance, and the data resolution behavior. The most usable information is front-loaded and there is no redundancy with the schema. This is model conciseness.

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?

There is no output schema, so the description must convey enough about the return value. It communicates an ordered list of picks and the fact that player names, positions, and teams are resolved, giving the agent a mental model of each pick's contents. While the exact fields of a pick object are not enumerated, the stated ordering and fallback behavior are sufficient for a simple polling tool.

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 schema documents the optional limit parameter as returning the most recent N picks, while draft_id is only typed as a string with no description. The tool description adds no detail about either parameter and thus doesn't compensate for the missing draft_id semantics. Since draft_id is self-evident from the tool name and limit is already well-described, this is adequate but not exceptional.

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 states the tool returns an ordered list of draft picks already made, which clearly identifies the resource and behavior. It distinguishes itself from sibling tools like get_available_players (unpicked players) and whose_turn (next pick) by focusing on completed picks. The title 'Get picks made so far' reinforces this precision.

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?

It gives explicit advice to poll every 5–10 seconds during a live draft, which defines a concrete use case and cadence. It does not explicitly contrast with alternatives, but the mention of live polling and cached resolution implies when it is appropriate. Without exclusions or named fallback tools, it falls just short of the strongest guidance.

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

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

With no annotations, the description carries the full behavioral burden. It discloses a two-step behavior (username resolution before listing), the default season behavior, and that the output contains league_id for reuse. It does not mention error cases, but the disclosed behavior is sufficient for a read-only lookup.

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?

Two sentences with no redundancy: the first states the operation and default, the second explains how to use the result. The key workflow constraint (league_id reuse) is front-loaded.

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 two-parameter resolver with no output schema, the description provides the essential context: what the tool returns (a list of leagues with league_id) and how the result fits into the wider toolset. It omits error behavior, but that is a minor gap for this straightforward lookup.

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?

Schema description coverage is 100%, so the schema already documents username and season. The description restates the default season and refers to username resolution but adds no new parameter-level detail beyond the schema. 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 states a specific action: resolve a Sleeper username to a user_id and list that user's NFL leagues for a season. It also clarifies the tool's role in the workflow by telling the agent to use the returned league_id with other tools, distinguishing it from the sibling tools that handle players, drafts, and rosters.

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 the tool is the entry point for user-league lookups: it resolves the username, lists leagues, and returns league_id for downstream tools. It does not explicitly name alternative tools or when not to use it, but the context is clear because the siblings serve different purposes.

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

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

No annotations are provided, so the description carries full burden. It explains the core analysis behavior but does not disclose side effects (e.g., read-only nature), permission requirements, error handling if roster_positions is missing, or return format. For a tool named 'get', read-only is implied but never stated.

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?

Two sentences with no superfluous content. The first sentence explains the purpose, the second gives essential usage context and parameter guidance. Highly efficient and front-loaded.

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?

Given the simple 3-parameter tool with no output schema, the description covers functionality, dependencies, and parameter selection. Missing details like return values or failure modes are not critical but would make it fully complete. Overall, sufficient for an agent to invoke correctly.

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?

Schema description coverage is only 33% (my_roster_id is described in the schema). The description adds meaning for league_id and draft_id by explaining their role in locating roster_positions, but it does not clarify their format or relationship beyond 'or' — nor does it elaborate on the required my_roster_id beyond the schema's brief note. Partial compensation for low schema coverage.

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 uses a specific verb ('compare') and resource ('players a roster has drafted so far against the league's required starting lineup') and states the outcome ('flag thin positions'). It clearly differentiates from sibling tools like get_draft_info or get_draft_picks, which focus on draft data rather than roster needs analysis.

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 explicitly states a prerequisite ('Needs the league's roster_positions') and provides the required parameter guidance ('pass league_id (or a draft_id whose league is known)'). It does not explicitly mention when to avoid this tool, but the context is clear for a roster analysis use case.

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

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

With no annotations, the description carries the behavioral disclosure burden. It discloses that the data is a rough signal and explicitly not rankings/ADP, which sets expectations about data quality. However, it does not mention any other behavioral aspects such as data freshness, rate limits, or return format.

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 very concise—two sentences—and front-loads the core functionality. The caveat about being a rough signal immediately follows the primary purpose. Every word adds information.

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 tool with no output schema or annotations, the description provides the core purpose but lacks guidance on parameter usage, expected return shape, and when to choose this tool over siblings. The tool is easy to understand but incompletely documented.

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?

Schema description coverage is 0%, so the description must compensate. It mentions 'added or dropped' and 'lookback window', which indirectly hints at the 'type' and 'lookback_hours' parameters, but does not explicitly describe any of the three parameters or their constraints. The description adds minimal value beyond the schema.

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 the tool's function: retrieving Sleeper's trending players (most added or dropped) within a lookback window. It explicitly differentiates the tool from rankings or ADP, which helps distinguish it from potential alternatives.

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?

No explicit guidance on when to use this tool versus alternatives is provided. The phrase 'Rough signal only' implies it is not a precise source, but there is no mention of sibling tools or specific use cases.

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

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

With no annotations, the description carries the full burden. It discloses the key behavioral trait: re-downloading a ~5MB dictionary and rewriting disk cache. It does not mention potential latency or network dependency, but the core side effect is clearly stated.

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?

Two sentences with no wasted words. The action is stated first, followed by context and usage condition. Every word contributes.

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 zero-parameter, no-output-schema maintenance tool, the description provides complete context: what it does, data size, frequency, and when to invoke manually. Nothing essential is missing.

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?

Tool has zero parameters, so schema coverage is complete and no parameter descriptions are needed. Baseline of 4 is appropriate; description need not add parameter meaning.

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?

Description states a specific verb ('Re-download') and resource (Sleeper's /players/nfl dictionary), with clear action (rewrite disk cache). It is clearly distinct from sibling query tools like get_available_players or get_trending_players, which all retrieve data rather than refresh a cache.

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?

Explicitly says when to use: 'use this if names look stale' and notes the normal automatic daily behavior. It doesn't mention when not to use it, but no alternative tool performs this refresh function, so the guidance is sufficient.

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

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 the calculation logic and special cases (linear, third-round reversal), and explains the optional flag behavior. However, it does not state whether the tool is read-only, what happens if draft_id is invalid or draft is complete, or describe the return format/side effects.

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?

Two sentences with no fluff. The primary purpose is front-loaded, and the optional parameter behavior is logically placed second. Every clause contributes meaningful information.

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 two-parameter computation tool, the description covers the core purpose and optional behavior but lacks important context: there is no output schema, no note about error conditions (e.g., draft finished), no mention of whether this function is deterministic from the given inputs, and no cross-reference to related draft tools. This leaves some ambiguity for correct invocation.

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?

Schema coverage is 50%: my_roster_id has a schema description and the description adds specific meaning ('on_the_clock flag and picks-until-your-next-turn'), but draft_id is only named, not explained. The description does not clarify that draft_id is used to fetch the draft state, relying on the agent's inference.

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 a specific verb ('Compute') and resource ('the pick currently on the clock'), and explains the mathematical approach (snake-draft, linear drafts, third-round reversal). It distinguishes itself from sibling tools like 'get_draft_picks' by focusing on current turn calculation rather than listing picks.

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 gives context for when the tool is useful (knowing whose pick it is) and how to use the optional my_roster_id, but it does not explicitly compare to alternatives or state when not to use it. Usage is implied rather than clearly scoped against siblings.

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