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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the mutation risk is covered. The description adds meaningful behavioral context beyond annotations: it requires ESPN_S2 and ESPN_SWID credentials, dryRun previews the payload without posting, and dropping a rostered player occurs in the same transaction. These are non-obvious behaviors an agent needs to know.

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 logically organized and front-loads purpose and sibling differentiation. However, several sentences repeat information already present in the schema, such as player id format, teamId default, week default, and dryRun semantics. With 100% schema coverage, those repetitions make it longer than necessary and slightly reduce 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?

The description covers the core action, the alternative tool, required credentials, defaults, dry-run behavior, and the transactional drop behavior. An output schema exists, so return-value documentation is not needed. For a tool with five parameters and a destructive hint, this is sufficiently complete 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 100%, so the baseline is 3. The description repeats some defaults already in the schema, but it adds transactional meaning by saying the drop happens in the same transaction and explicitly characterizes the action as adding a free agent with an optional drop. This adds nuance beyond the individual parameter descriptions.

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 opens with a specific verb and resource: 'Add an available free agent', and clarifies the optional drop of a rostered player in the same transaction. It clearly differentiates this from the sibling submit_waiver_claim by naming the condition that selects that sibling, so an agent can distinguish the 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?

It explicitly states when to use an alternative: 'Use submit_waiver_claim for players on waivers.' This gives the agent a direct routing rule. Combined with the title and opening sentence, the description leaves no ambiguity about when this tool applies versus its sibling.

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?

Annotations already declare destructiveHint=true, so the agent knows this is a destructive operation. The description adds useful context: it requires ESPN_S2 and ESPN_SWID credentials, it cancels a 'pending' claim (not an executed one), and dryRun previews without posting. This goes beyond the annotations by clarifying the scope of the destructive action and the auth requirement.

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 three sentences, each earning its place: the action and key parameter, the defaults, and the dryRun behavior plus auth requirement. It is front-loaded with the core purpose and avoids fluff.

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 tool has an output schema and annotations, the description covers the essential behavioral context: what it cancels, how to identify the claim, defaults, dryRun, and auth. It doesn't explicitly state what happens if the claim is not pending or if the transactionId is invalid, but that's a minor gap for a cancellation tool with an output schema.

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 75%, and the description adds meaning for the key parameter (transactionId) by specifying it comes from get_transactions. It also clarifies the defaults for teamId and week, which are already in the schema but reinforced. The dryRun parameter is described in both schema and description. The description doesn't add much for week/teamId beyond the schema, but the transactionId provenance is valuable.

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 action ('Cancel a pending waiver claim'), the specific resource ('using its ESPN transactionId from get_transactions'), and the context (ESPN fantasy). It distinguishes itself from siblings like submit_waiver_claim by focusing on cancellation of a pending claim. The title and description align well.

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 provides clear context: it tells the agent to use the transactionId from get_transactions, and explains defaults for teamId and week. It also mentions dryRun for previewing. However, it doesn't explicitly state when NOT to use this tool or name alternatives (e.g., when to use submit_waiver_claim instead), though the sibling list makes the distinction inferable.

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?

Annotations already mark this as destructive, and the description adds valuable behavioral context: it posts a payload to ESPN, can be previewed via dryRun without posting, and is subject to roster-lock and league-rule enforcement. This goes beyond what the annotations alone convey and does not contradict them.

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 compact and front-loaded with the purpose, then covers constraints, parameter defaults, and authentication in five short sentences. The first sentence slightly overlaps with the title, but overall there is minimal padding and every sentence carries useful 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?

Given the output schema, full parameter documentation, and destructive annotations, the description is largely complete: it covers auth requirements, league constraints, defaults, and the dryRun escape hatch. The only notable gap is the absence of explicit guidance about when to use direct drop versus a waiver claim, which was already factored into the usage-guidelines score.

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 baseline is 3. The description mostly restates what the schema already says about player ID formats, negative D/ST IDs, teamId and week defaults, and dryRun behavior, adding no substantially new parameter-level 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?

The description uses a specific verb and object, 'Release one player from your fantasy team,' which clearly identifies the drop action and its target. It is distinguishable from siblings like add_player and submit_waiver_claim, but the description does not explicitly contrast itself with those 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?

The description provides useful contextual constraints: ESPN roster locks and league rules may block the drop, and ESPN_S2/ESPN_SWID authentication is required. However, it does not explain when to choose drop_player over sibling tools such as submit_waiver_claim, so usage guidance is mostly implied rather than explicit.

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

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

Annotations already indicate this is read-only and open-world. The description adds useful behavioral context beyond annotations, especially that player ids are ESPN ids and that D/ST ids can be negative, which is a non-obvious gotcha. It does not contradict the 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 two tight sentences with no filler. The core purpose is front-loaded, and the critical ID note is included 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 read-only listing tool with an output schema, the description covers the main behavior, filtering/sorting options, and an important ID quirk. The main gap is the lack of explicit guidance on how this tool relates to search_players, but the description is otherwise 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 only 25%, so the description must compensate. It adds meaning for positions and sortBy ('optional position filters and ownership or projection sorting'), and week has a schema description, but limit receives no explanation in either place and the percentChange sort option is only implicitly covered by 'ownership'.

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 clear action and resource: finding available players to add or claim, with optional filters and sorting. It doesn't explicitly name sibling tools like search_players, so it doesn't fully differentiate itself, but the resource and intent are unambiguous.

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 looking for players to add or claim. However, it gives no explicit guidance on when to choose this over search_players or other alternatives, and there are no exclusions or conditions 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?

Annotations already declare readOnlyHint and openWorldHint, covering the safety profile. The description elaborates on the scope (settings, lineup slots, waiver rules, standings) but does not describe data freshness, whether standings are current, or any open-world variability implied by openWorldHint. No contradiction with annotations exists.

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 first sentence is front-loaded and compact, listing the action and resources in a single line. The second sentence ('Team ids identify ESPN fantasy teams.') is tangential for a zero-parameter tool, so it is not fully earning its place, though it is brief and not seriously distracting.

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, read-only tool with a provided output schema, the description adequately explains what the tool does and when it is relevant ('before managing a team'). It does not explicitly distinguish itself from all siblings, but the listed league-level resources make the distinction clear enough for an agent to select it appropriately.

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 rubric baseline is 4. The input schema is empty and schema coverage is 100% vacuously; the description adds no parameter-specific meaning, and none is needed. The 'Team ids' sentence is broader domain context rather than 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 ('Inspect') and names concrete resources: league settings, lineup slots, waiver rules, and team standings. This clearly distinguishes it from sibling tools like get_roster, get_matchups, or get_transactions, which focus on other data domains.

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 'before managing a team' gives clear contextual timing for when this read-only overview should be used. However, it does not explicitly name when-not situations or direct the agent to alternatives such as get_roster or get_matchups, stopping short of full exclusion 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?

Annotations already declare readOnlyHint=true, and the description adds useful behavioral details: 'live projections' implies real-time data, and 'with the configured team's matchup marked mine' discloses an output behavior. It also clarifies team id semantics 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.

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

The description is two sentences with zero fluff. The primary action and scoping are front-loaded in the first sentence, and the second sentence adds a necessary clarification about ESPN team ids, all in under 30 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?

Given the output schema exists and annotations cover safety, the description is complete enough for a one-parameter read tool. It explains what is checked and the special marker; potential omissions like pagination or error handling are minor given the output schema.

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% for the only parameter, ``week``, which already explains the default and type. The description's mention of team ids refers to the configured team, not the parameter, so it adds no additional parameter semantics beyond the baseline.

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 checks scores and live projections for a week and marks the configured team's matchup. This distinguishes it from sibling tools like get_roster and get_league by focusing on weekly matchups with a specific output marker.

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 provides clear context—use for weekly scores/projections with the configured team highlighted. It does not explicitly name alternatives or exclusions, but the purpose is specific enough that an agent would know when to invoke it.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and data volatility. The description adds useful content details (lineup, injuries, projections, ESPN id conventions including negative D/ST ids) but does not disclose additional behavioral traits such as auth requirements or rate limits, which are not expected for a simple read-only tool.

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 compact at three sentences with the purpose front-loaded. The final sentence about player ids is slightly tangential to invocation but still short and useful for interpreting output, so no significant 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?

With both optional parameters fully documented in the schema, an output schema present, and annotations covering safety, the description is complete for an agent to select and invoke the tool correctly. No critical information 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 description coverage is 100%, with both week and teamId already documented including defaults. The description repeats the teamId default but adds no new parameter semantics beyond the schema, so baseline 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 ('Inspect') and resource ('a team's lineup, eligible slots, injuries, opponents and projections'), clearly distinguishing it from sibling read tools like get_free_agents or get_matchups. The 'before making moves' clause reinforces its role in the fantasy workflow.

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 provides a clear usage context ('before making moves'), suggesting when to call it relative to action tools like add_player or set_lineup. However, it does not name alternatives or explicitly state when not to use it, so it falls short of full 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?

Annotations already declare the tool read-onlyais, so the description need not restate safety. It adds valuable behavioral details beyond annotations: results are newest-firsttas, items contain only ESPN player IDs without names, and player IDs include negative D/ST IDs.

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?

Three sentences, no filler. The primary purpose is front-loaded, followed by two terse but essential detail sentences about item contents and player ID semantics.

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 read-only list tool with one optional parameter)Skip, an output schema, and annotations covering the safety profile, the description is nearly complete. The only small ambiguity is whether 'league activity' includes non-transaction events, though the tool name and transaction-ID focus resolve most of it.

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 description does not explain the 'limit' parameter, and schema description coverage is 0%. However, the sole parameter is optional, self-explanatory, and fully constrained in the schema with a default, maximum, and exclusive minimum, so the gap is minor.

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 ('Inspect'), a resource ('recent league activity'), and an explicit purpose ('find transaction ids for cancelling pending claims'). This clearly differentiates it from siblings like get_matchups and cancel_waiver_claim, though 'league activity' is slightly broader than 'transactions'.

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 a clear use case: finding transaction IDs specifically for cancelling pending claims. It does not explicitly name alternatives or exclusions, but the connection to the cancel_waiver_claim sibling is strongly implied, giving enough contextual 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: case-insensitive substring matching, ESPN-specific id semantics, and the inclusion of negative D/ST ids.

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 tightly written sentences with no filler. The core action and scope are front-loaded, and the second sentence adds important id-format detail. Every sentence 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?

Given the output schema exists and annotations cover safety, the description is largely complete. It adequately explains the search scope and id semantics. A slight gap is that it does not explicitly guide the agent to choose this over get_free_agents or get_roster, but the cross-cutting phrasing makes the distinction inferable.

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 clarifies that the query parameter is a case-insensitive name substring, which is valuable. However, the limit parameter is not described at all; its meaning is left to inference from the parameter name and schema defaults, providing only partial compensation.

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 action ('Look up'), a specific resource (ESPN player ids and fantasy team ownership), and a precise search method (case-insensitive name substring). It also distinguishes itself from sibling tools by explicitly stating the search spans rosters, free agents, and waivers, making it the cross-cutting search tool.

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 clear context: use this tool when you need to find players across rosters, free agents, or waivers by name substring. It does not explicitly name alternatives or state when not to use it, but the cross-cutting scope is sufficiently clear versus roster-specific or free-agent-specific siblings.

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?

Annotations already signal mutation via destructiveHint=true, and the description adds useful operational detail: the caller must list every move including the player vacating a slot, no counter-moves are auto-generated, and dryRun previews the payload without posting. It also discloses required ESPN credentials, which is important for invoking the tool.

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 opening sentence states the core purpose, followed by short sentences on behavior, ids/defaults, dryRun, and auth. It is slightly longer than necessary because some parameter details repeat what the schema already documents, but every sentence carries useful information and the structure is logical.

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 a 4-parameter tool with an output schema and destructive annotations, the description covers all essential invocation context: auth, defaults, slot semantics, dryRun safety, and the 'list every move' rule. No critical detail appears missing for an agent to call this tool 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 coverage is high at 75%, so the baseline is 3. The description adds value by giving slot value examples ('QB, FLEX, BE or IR') and restating key defaults and the negative D/ST id convention, which helps agents construct valid moves. Some redundancy with the schema exists, but the slot clarification compensates.

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 opens with a specific verb ('Move') and resource ('rostered players to eligible slots'), and enumerates slot examples. This clearly distinguishes set_lineup from sibling tools like add_player, drop_player, and submit_waiver_claim, which operate on acquisitions or drops rather than lineup placement.

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 frames the tool for repositioning already-rostered players and calls out auth prerequisites, defaults, and dry-run behavior. It does not explicitly name alternative tools or state hard when-not-to-use conditions, but the 'rostered players' scope plus sibling names makes the intended context clear enough.

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?

Annotations already mark this as destructive, and the description adds valuable behavior context: ESPN processes the claim under league rules, dryRun previews without posting, and ESPN_S2/ESPN_SWID are required. This goes beyond the structured annotations without contradicting them.

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 compact and front-loaded: the core action appears in the first sentence, followed by defaults, credential requirements, and preview behavior. Every sentence earns its place 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 mutating waiver tool with six parameters and an output schema, the description covers the essential operational context: what the claim does, optional drop, defaults for bid/teamId/week, dryRun safety, and required credentials. Nothing critical for invoking it 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 description coverage is 83%, so the schema already documents most parameters. The description mostly restates schema defaults (bid 0, teamId defaults to ESPN_TEAM_ID, dryRun previews payload) and the negative D/ST id note, adding little new semantic value beyond the structured fields.

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 and resource: 'Claim a player on waivers with an optional drop and a nonnegative bid.' It clearly identifies the operation and distinguishes it from siblings like cancel_waiver_claim, add_player, and drop_player by framing it as a waiver-claim submission.

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 sets clear context: this tool is for submitting a waiver claim, not for canceling one or for ordinary adds/drops. It does not explicitly contrast itself with cancel_waiver_claim or other siblings, but the action is unambiguous enough that an agent can select it appropriately.

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