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

With no annotations present, the description carries the full burden and does add context: it discloses that the response includes player metadata (name, position, team), and 'Get' implies a read-only operation. However, it says nothing about pick ordering, behavior for an invalid or nonexistent draft_id, or auth/rate-limit expectations, so the behavioral picture is only partial.

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 short sentences with no filler; the core action is front-loaded and the second sentence earns its place by revealing that player resolution is bundled into the response. Nothing is redundant or wasteful.

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?

The tool is simple (one required string parameter) and the description covers the core behavior, but with no output schema or annotations, an agent gets no hints about pick ordering, the shape of each pick object, or how this relates to get_traded_picks. Adequate for basic invocation, with clear gaps around return format and edge cases.

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 100% — the only parameter, draft_id, is already documented as 'The Sleeper draft ID.' The description's phrase 'in a draft' merely echoes this meaning and adds no format, validation, or source detail, so the schema-heavy baseline of 3 applies.

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?

States the verb 'Get' with a specific resource: 'all picks in a draft,' and clarifies the response includes player metadata. The phrase 'all picks' implicitly sets it apart from the sibling get_traded_picks, but no sibling is named and the differentiation is left to inference.

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 is purely declarative and gives no guidance on when to call this versus siblings such as get_traded_picks or get_drafts. No context is provided on the typical flow (e.g., fetch a draft via get_drafts first) or when the bundled player metadata would make a separate resolve_players call unnecessary.

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 provided, the description carries the full burden and does disclose one behavioral trait: results are sorted most recent to earliest. It does not explicitly confirm read-only behavior or mention limitations like pagination, though the verb 'get' and 'all drafts' imply a safe listing operation.

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 sentence of ten words with no filler. It front-loads the main action and scope, and the sort-order detail is the only addition, making every word earn its place.

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?

This is a simple one-parameter read-style tool with no output schema, and the description covers the resource, scope, and sort order, which is largely sufficient. It does not explain the return shape or authorization needs, but the tool's simplicity and full schema parameter coverage keep the gap small.

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%, and the only parameter, league_id, is already described as 'The Sleeper league ID.' The description adds no new semantic detail about the parameter beyond tying it to the league context.

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 verb and resource—'Get all drafts for a league'—with the added precision of a sort order. It does not explicitly reference sibling tools, but 'drafts' clearly distinguishes this from get_draft_picks and other league-related tools.

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 guidance is given about when to use this tool versus alternatives like get_draft_picks. The description implies the usage scenario—retrieving drafts for a league—but provides no conditions, prerequisites, or exclusions.

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 bears the full burden. It indicates a read-only retrieval operation but does not disclose what fields are returned, whether the league data is fully populated, or any error behavior (e.g., invalid/nonexistent league ID). While 'Get' signals non-destructive behavior, the lack of detail on response specifics is a gap.

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 extremely concise—a single, clear sentence that front-loads the primary action and resource. It avoids redundancy with the title and schema, containing no filler words. It is slightly under-specified regarding return details, but the brevity is appropriate for a simple tool.

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 single-parameter lookup tool, the description is functionally adequate: the schema covers the parameter, and the description outlines the core operation. However, with no annotations, no output schema, and no mention of common error cases or rate-limit considerations, it leaves minor gaps for an agent that needs to handle failures gracefully.

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%, as the schema already fully describes the one parameter ('The Sleeper league ID.'). The description adds no further semantic nuance, such as format expectations or examples, so it meets the baseline without adding 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 with a specific verb ('Get') and resource ('a specific league's details'), and identifies the key identifier ('league ID'). It unambiguously distinguishes itself from sibling tools like get_leagues (which lists leagues) by focusing on a single league's details.

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 primary use case—fetching details for one league—but offers no explicit guidance on when to choose this over get_leagues or other league-related siblings. It does not state scenarios for which this tool is appropriate or inappropriate, leaving some inference to the agent.

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 must carry the full behavioral burden. It only restates the core function and does not disclose return shape, list vs. empty behavior, error handling, ordering, or any side effects or limitations. An agent gets little more than the tool name conveys.

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?

A single, front-loaded sentence with no filler. Every word contributes to the core purpose, making it easy to parse quickly.

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 there is no output schema and no annotations, the description should fill in what the returned data looks like. It does not, nor does it clarify default season behavior beyond the schema, failure modes, or whether the result is an array. For a tool with only two well-described parameters, invocation is straightforward, but response expectations are ambiguous.

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%, with both 'user_id' and 'season' described. The description adds no new parameter meaning beyond restating 'a user belongs to' and 'given season', which is already present. Baseline 3 applies because the schema handles the parameter documentation.

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 ('Get') and resource ('all leagues'), with a clear scoping clause: 'a user belongs to for a given season.' It clearly differentiates from sibling 'get_league' by being plural, and from 'get_users_in_league' by inverting the relationship.

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 when to use it: when you need all leagues for a specific user and season. However, it provides no explicit guidance on when not to use it, no alternatives, and no prerequisites such as the user_id needing to exist or season format.

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 burden. It discloses that teams sharing a matchup_id face each other and that player IDs are annotated with names, which is useful behavioral context. However, it doesn't mention whether this is a read-only operation, any rate limits, or what happens if no matchups exist for the week. The description adds some value but not comprehensive behavioral disclosure.

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

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

The description is two sentences, front-loaded with the core function, and adds a clarifying detail about matchup_id and player ID annotations. Every sentence earns its place; no wasted words.

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-style tool with two fully documented parameters, the description is largely complete. It explains the grouping logic and the player ID annotation, which are the non-obvious aspects. It could mention the return format or edge cases (e.g., empty weeks), but given the simplicity and full schema coverage, the gaps are minor.

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 both parameters (league_id and week) with descriptions. The description adds the context that week is used to filter matchups, but doesn't add new parameter-level meaning beyond what the schema provides. 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 the tool's function: retrieving all matchups in a league for a given week. It specifies the resource (matchups), the scope (league), and the key parameter (week). It also adds a useful detail about matchup_id grouping and player ID annotations, which helps distinguish it from other league-related tools.

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 when to use this tool: when you need matchups for a specific league and week. It doesn't explicitly name alternatives or exclusions, but the sibling list shows other tools like get_league, get_rosters, get_transactions, which are clearly different. The context is clear enough for an agent to select it appropriately.

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 provided, the description must carry the behavioral burden. 'Get' implies a read-only fetch with no side effects, and the description explicitly lists what will be returned. It does not describe the exact response shape, but for a zero-parameter state query this is a minor gap.

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?

A single, front-loaded sentence that states the operation and the three return fields without any filler. Every word earns its place.

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 tool, the description is complete: it names exactly what the agent will receive, including the season type values (pre/regular/post). Nothing needed to invoke or understand the result 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?

The tool has zero parameters, so the baseline is 4. There are no parameter semantics for the description to clarify, and the schema already fully covers the empty parameter set.

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 names a specific verb ('Get'), a clear resource ('current NFL state'), and enumerates the exact data points returned: season, week, and season type. It also distinguishes itself from all sibling tools, which operate on users, leagues, rosters, and drafts rather than league-wide NFL state.

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 word 'current' clearly situates the tool as the one to call when an agent needs the current NFL season/week/type. There are no similar sibling tools to confuse it with, so explicit when-not/alternative guidance is unnecessary; no exclusions are needed.

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?

There are no annotations, so the description carries the behavioral disclosure burden. It adds one useful behavioral detail: player IDs are annotated with player names unless the player cache is warm. However, it does not mention other relevant behaviors such as authorization needs, read-only guarantees, or the structure of the returned roster objects.

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 exactly two sentences with the primary action and scope front-loaded, followed by a concise caveat about player name annotations. Every sentence adds value and there is no filler.

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 tool with a single well-described parameter, this is nearly complete: it states what is returned (all rosters) and a key return-value nuance (player name annotations). The lack of an output schema makes more detail about roster object structure desirable, but nothing essential for invoking the tool correctly 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?

Schema coverage is 100%, and the league_id parameter is already described as 'The Sleeper league ID.' The description's 'in a league' does not add new parameter meaning, so it stays at the baseline for full 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 begins with the specific verb 'Get' and the resource 'all rosters in a league', which clearly differentiates it from sibling tools such as get_league, get_users_in_league, and get_matchups. It states exactly what the tool returns and at what scope.

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 phrase 'in a league' clearly indicates when the tool is appropriate: whenever an agent needs roster-level data for a given league. It provides clear context, but it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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 clearly signals a read operation and adds the meaningful nuance that future picks are included, but it does not define what counts as a 'traded' pick or describe edge cases such as empty results or sorting.

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, front-loaded sentence where every word adds information. It avoids redundancy with the title and clearly states the core action, resource, scope, and future-pick nuance without waste.

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 one-parameter read tool with 100% schema coverage, the description is mostly sufficient to invoke the tool. However, with no output schema and no annotation coverage, it leaves the response shape and the exact semantics of 'traded' to inference, and it does not explicitly point to get_draft_picks as the alternative for non-traded picks.

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%, with league_id already described as 'The Sleeper league ID.' The description adds no parameter-specific meaning, so the baseline of 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 uses a specific verb ('Get'), a precise resource ('traded draft picks'), and a scope ('in a league'), while also noting the inclusion of future picks. The word 'traded' differentiates this from the sibling get_draft_picks, making the tool's purpose clear without needing to open the schema.

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 when-to-use or alternative routing is provided. The description implies that this tool is for traded draft picks, especially future ones, and that get_draft_picks is the broader sibling, but the agent must infer this rather than being told directly.

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 provided, the description carries the full burden of behavioral disclosure. It does convey that this is a read operation returning transactions, but it says nothing about pagination, response shape, error behavior, empty-week outcomes, or any authentication limits. For a tool with zero annotation coverage, this is a notable gap.

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 one tight sentence that front-loads the action and resource, then clarifies scope and transaction types. There is no redundant wording or filler, so every word earns its place.

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?

The input schema fully documents both parameters and the tool is conceptually simple, so the description is adequate for knowing what to request. However, there is no output schema and the description does not describe what the returned transaction data looks like or how missing transactions are represented, leaving some contextual gap for an agent invoking the 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 100%, so both league_id and round are already documented. The description lightly reinforces that 'round' corresponds to the week, but it adds no additional meaning or constraints beyond what the input schema provides. 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 names a specific verb ('Get'), a clear resource ('all transactions'), and the exact scope ('for a league in a given week (round)'). It also enumerates what kinds of transactions are included (trades, waivers, free agent adds/drops), which removes ambiguity and distinguishes it from the sibling league/roster/draft tools.

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 clearly implies when to use this tool: when transaction activity for a specific league and week is needed. However, it gives no explicit guidance on when not to use it or how it compares to alternatives such as get_matchups or get_draft_picks, leaving selection to inference from the resource name.

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 behavioral burden. It does convey that trending is derived from add/drop activity, which adds some signal beyond the name, but it does not explain sorting, response format, or how 'trending' is computed.

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 clear sentence with no filler or repetition. It front-loads the core purpose and does not waste words.

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?

The tool has optional parameters with clear schema defaults, so invocation is reasonably straightforward. However, with no output schema and no annotation context, the description does not clarify what the returned player objects contain, how results are ordered, or how 'trending' is quantified, leaving some ambiguity.

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 parameters are already well documented in the schema. The description's add/drop activity phrasing loosely aligns with the 'type' parameter, but it does not add meaningful semantics beyond what the schema already provides.

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 ('Get') and resource ('players trending') and identifies the underlying signal ('add/drop activity'). It is distinguishable from sibling tools like get_transactions or get_rosters, though it could more explicitly mention the adjustable type/limit/lookback options.

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?

There is no guidance on when to use this tool versus alternatives such as get_transactions or resolve_players. The description implies the intended use through the name and add/drop phrasing, but it does not explicitly state the right context or any exclusions.

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 transparency burden. It clearly signals a read-only lookup and adds a useful behavioral caveat about usernames changing over time. But it does not disclose response shape, not-found behavior, or what happens if neither or both identifiers are supplied.

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 compact sentences with no filler. The core lookup mechanism is front-loaded, and the user_id persistence tip earns its place as actionable guidance.

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 read-only lookup, the description plus schema is nearly sufficient. It explains what the tool does and gives stable-identifier guidance. The main gaps are not explicitly requiring exactly one of username/user_id and not describing the return contract, but these are minor given the tool's simplicity and full schema coverage.

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 input schema already documents both parameters with 100% coverage. The description adds value beyond the schema by explaining that usernames are mutable and advising the agent to store user_id for stable future lookups, which directly informs parameter choice.

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 verb ('Look up') and resource ('Sleeper user') and clearly identifies the two lookup keys: username or user_id. This distinguishes it from siblings like get_users_in_league, which is about users within a league, and resolve_players, which is about player resolution.

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 when to use the tool: when you have a username or user_id and want the corresponding Sleeper user. It also gives practical guidance to prefer storing user_id because usernames change. However, it never explicitly names alternatives or says when not to use this tool versus siblings, leaving some routing to inference.

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 burden of disclosing behavior. It conveys a read operation and the output fields, but does not mention authorization needs, pagination, empty-league behavior, or that it returns users rather than roster entries. This leaves moderate, non-misleading gaps.

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, front-loaded sentence with no filler. The parenthetical efficiently adds relevant detail about the returned user fields without bloating the text.

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 one-parameter read endpoint with a fully documented schema and no output schema, the description adequately conveys what is returned. It stops short of describing pagination, error handling, or exact response structure, but those are minor for this simple 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 already provides 100% coverage by describing league_id as 'The Sleeper league ID.' The tool description adds no additional meaning beyond the schema, so the baseline of 3 applies.

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 names a specific verb ('Get'), a clear resource ('all users'), and a scope ('in a league'), plus the key fields returned (display names/team names). It is semantically distinguishable from sibling tools like get_user (a single user) and get_rosters (rosters rather than users).

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?

There is no explicit guidance about when to use this tool versus alternatives, such as get_user or get_rosters. The imperative 'Get all users...' implies its use case, but no when/when-not conditions or sibling exclusions are stated.

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 burden. It accurately conveys a read-style transformation and lists the output fields, but it omits the caching behavior implied by force_refresh in the schema and does not mention how unknown or invalid player IDs are handled. It does not contradict anything, but deeper behavioral disclosure would improve it.

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, well-structured sentence with no filler. The core operation and return attributes are front-loaded, and the example context is included efficiently without distracting from the main purpose.

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 tool with no output schema, the description is nearly complete: it identifies the input, the typical source of that input, and the four output attributes. The only notable gap is that cache-refresh behavior is left to the parameter schema rather than explained in the description, which is a minor omission.

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 100%; both player_ids and force_refresh are already described in the input schema. The tool description adds no new parameter-level detail beyond the use-case example, so the baseline score of 3 applies.

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, 'Resolve', with a clear object ('a list of Sleeper player IDs') and a concrete outcome ('into player names, teams, positions, and injury status'). This clearly differentiates it from sibling getter tools like get_rosters or get_matchups, which return raw data rather than enriched player details.

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 parenthetical 'e.g. from rosters or matchups' gives a clear context for when to use the tool: after fetching raw roster or matchup data. It provides good usage orientation, though it does not explicitly list alternatives or state when not to use it.

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