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

Annotations already indicate readOnlyHint=false, so the description's implied mutating behavior is consistent. The phrase 'lineup move' adds mild context, but the description does not disclose operational details such as dry_run defaults or environment-dependent execution, which are left to the schema.

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. The core action is front-loaded and 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?

Given the output schema, parameter defaults, and sibling context, the definition provides enough for an agent to understand and invoke the tool. It is slightly thin on operational behavior, but the schema compensates for most of that gap.

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 71%, and key parameters like dry_run, sport, season, and league_id are already documented in the schema. The description adds little semantic value beyond the schema, though 'active or bench slot' loosely reinforces the meaning of to_slot.

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 ('Move') with a clear resource ('one player out of the IR/IL slot') and destination ('into an active or bench slot'). It uniquely distinguishes this operation from siblings like move_to_ir and set_lineup.

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 phrasing establishes the clear context: a player currently in the IR/IL slot should be moved into an active/bench spot as a lineup adjustment. It does not explicitly name alternatives or exclusions, but the intended use case is not ambiguous.

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 convey that this is a non-read-only, non-destructive operation, so the safety profile is covered. The description adds useful context about targeting unclaimed free agents and optionally dropping another player, but it does not go deeper into side effects or transaction behavior. The dry-run behavior is documented in the schema, so the description does not repeat 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 front-loaded sentence that states the action, the exception, the sibling tool to use instead, and the optional drop behavior. There is no filler or redundant restating of the tool name.

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 an output schema present and schema documentation for dry_run, sport, season, and league_id, the agent has most of what it needs. The description routes the agent to the correct sibling and clarifies add/drop semantics. The remaining gap is the ambiguous team_id parameter, but required add_player_id and defaults make invocation feasible.

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 57%, so the schema handles sport, season, dry_run, and league_id. The description helps clarify drop_player_id with 'optionally dropping another player,' and add_player_id is inferable from the tool's purpose. However, team_id remains undocumented in both schema and description, leaving an ambiguity for the agent.

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 ('Add') and resource ('unclaimed free agent'), and explicitly distinguishes it from waiver-wire players by pointing to waiver_claim. It also discloses the optional drop behavior, which clearly differentiates it from sibling 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 NOT to use this tool ('not a waiver-wire player') and names the alternative ('use waiver_claim for those'). This gives the agent a clear decision rule without needing to inspect other tool definitions.

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 and readOnlyHint=false; the description adds that only pending waiver claims are affected and that the claim is identified via get_pending. This clarifies what is being acted on beyond the annotation flags, although it does not discuss reversibility or post-cancel 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?

One concise, front-loaded sentence contains the action, target, and parameter source with no filler. Every element contributes to the agent's understanding of what to call and how.

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 defaults documented in the schema, an output schema available, and destructive behavior covered by annotations, the description plus schema provides everything needed to call the tool correctly. The get_pending workflow dependency is explicitly named, so the required context is not 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 67%, and the description compensates for the undocumented required transaction_id by saying it comes from get_pending. Other parameters such as sport, season, dry_run, and league_id are already documented in the schema; team_id remains minimally described but is a defaulted integer with low ambiguity.

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 a specific verb ('Cancel') and resource ('a pending waiver claim'), and identifies the key identifier ('transaction id (from get_pending)'). This distinguishes it from siblings like waiver_claim or add_free_agent, which perform different actions, without merely restating the tool name.

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 ties usage to a pending claim retrieved via get_pending, which provides clear when-to-use context. It does not name alternatives or list exclusions, but the workflow dependency is unambiguous.

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 idempotentHint, so the description correctly adds scope semantics: 'actual stats' distinguishes from projected stats and 'both teams in each matchup' clarifies coverage. No contradiction exists between the description and 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 front-loaded sentence with no filler: the key concepts 'per-player actual stats', 'scoring period', and 'both teams in each matchup' appear in order of importance.

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 an output schema, strong annotations, and defaults documented in the input schema, the description covers the essential scope. A small gap is not naming an alternative for projected stats, but that is not required for 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 75% (sport, season, and league_id are documented), and the description reinforces scoring_period_id via 'scoring period'. It does not add new meaning beyond the schema, so the 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 identifies the resource as per-player actual stats for a scoring period and scopes it to both teams in each matchup, which distinguishes it from get_matchups (matchup-level data) and get_player (single-player data). It lacks an explicit verb like 'Retrieve', but the meaning is 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 phrase 'actual stats' implies use when real boxscore data is needed rather than projections or rosters, but no sibling tools or when-not-to-use conditions are mentioned. The usage context is inferable from the description but not explicitly 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, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is fully covered. The description adds useful behavioral context about the default sort order and the projection sort option, but does not detail what qualifies as a free agent vs waiver-wire player or any response characteristics.

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 filler; the primary behavior and default sorting are front-loaded, and the optional filtering note is placed at the end. Every clause 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?

With rich annotations, a complete input schema covering defaults and valid values, and an output schema present, the description covers all that an agent needs to invoke the tool correctly. Nothing critical 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 high (83%), and the description reinforces the meaning of sort_by and position_slot_id. It uniquely adds the cross-reference to get_league/README for slot IDs, which helps an agent supply valid values for position_slot_id.

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 a specific verb and resource ('free agents and waiver-wire players') and clarifies sorting by ownership percent or projection. It is clearly distinct from sibling mutation tools like add_free_agent or waiver_claim, which operate on this same player pool.

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 intended use—browsing available unrostered players—is clear from the description, and the optional filter is explained. It does not explicitly state when not to use it or compare against get_player/get_transactions, but the context is strong enough that an agent can select it correctly.

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 cover the read-only/idempotent safety profile. The description adds value by revealing the breadth of returned settings, including the current scoring/matchup period, beyond what the annotations encode. No behaviors 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?

A single front-loaded sentence lists the settings in a compact, scannable colon list with no filler. Every item 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, annotations, and complete parameter schema, the description covers what the tool returns and its safety profile. A slightly more explicit 'returns/retrieves' verb would make it fully self-contained, but nothing critical for correct invocation 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?

All three parameters are fully documented in the schema with descriptions, defaults, and an enum for sport. The description adds no parameter-specific meaning, which is acceptable because schema coverage is 100%.

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?

Title and first words identify the resource as league settings, and the description enumerates concrete setting categories (scoring, roster slots, waivers, schedule, trades, draft/keepers, periods). This separates it from sibling roster/team/matchup tools, though the description itself relies on the 'Get League Settings' title for the action verb.

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 category list makes it plain that this tool is for league-level configuration data, offering implied guidance for when to use it. However, it does not name alternatives or state when not to use it, so an agent must infer selection from the sibling names rather than explicit 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 destructiveHint=false, so the safety profile is known. The description adds value by specifying the content of the response (home/away IDs, totals, projections), which is not conveyed by annotations. No contradictions, and the added detail helps set expectations without overstepping.

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 sentence that front-loads the core purpose and then lists the key output fields. Every word contributes value; there is no filler or redundancy.

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

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

Given the tool has an output schema and comprehensive parameter schema, the description is sufficient. It covers the essential return content and does not omit critical calling details. It could mention pagination or sorting, but these are not expected for a straightforward matchup list, so a 4 is appropriate.

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 fully documents all four parameters, including the meaning of scoring_period_id ('Week (football) or day (basketball/baseball)'). The description does not add any parameter-specific guidance beyond what the schema already provides, 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 clearly states the verb ('get'), the resource ('matchups'), and the scope ('for a scoring period'), and enumerates the specific data returned (home/away team ids, live/final totals, live projections). This distinguishes it from siblings like get_teams or get_boxscore by focusing on the matchup-level summary.

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 (scoring period) but does not explicitly state when to prefer this tool over alternatives such as get_boxscore or get_teams. No exclusions or alternative routing are provided; an agent would have to infer when matchups are needed vs. a single game's details.

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 idempotentHint, and the description adds useful clarification that trades are read-only and that the server never proposes, accepts, or rejects trades. This prevents an agent from assuming it can act on the returned trade proposals through this 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?

Two sentences with no filler. The first sentence front-loads the resource and output behavior, and the second adds a critical read-only clarification that earns its place. Nothing extraneous is included.

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 zero required parameters, fully documented schema, rich safety annotations, and an output schema present, the description is complete. Nothing an agent needs to correctly invoke this tool 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%, with each parameter (sport, season, league_id) having a clear description and default value. The description adds no parameter-specific information, so the schema carries the full burden, matching the baseline for high 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?

Description names a specific verb and resource: 'Pending waiver claims and trade proposals.' It also distinguishes itself from the broader sibling get_transactions by explicitly scoping to pending items, so an agent knows exactly what this tool returns.

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 makes clear this is the read-only view of trades and waiver claims, contrasting with mutation siblings like waiver_claim or cancel_claim. It does not explicitly name alternative tools, but the context is strong enough that an agent can infer when to use get_pending versus mutation or broader transaction tools.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context: the name search is case-insensitive and searches across both rosters and free agents. It also implies the tool returns a single player ('one player'), which is useful. It doesn't mention edge cases like no match or multiple matches, but the output schema likely covers the return shape.

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 that front-loads the primary lookup method (id) and then adds the secondary method (name substring). Every word earns its place, and it's appropriately sized for a simple lookup 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?

The tool has an output schema, so return values are documented elsewhere. The description covers the two lookup modes and the search scope. It doesn't specify behavior when both id and name_search are provided, or what happens with no matches, but these are minor gaps given the output schema and annotations. The tool is simple enough that the description is nearly complete.

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 60%, so the schema documents sport, season, and league_id with defaults. The description adds meaning for 'id' and 'name_search' by explaining they are the two lookup methods, but it doesn't add detail beyond what the schema provides for the other parameters. The description doesn't explain the relationship between id and name_search (e.g., are they mutually exclusive? what if both are provided?). 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: 'Look up one player by ESPN player id, or by a case-insensitive name substring search across rosters and free agents.' It specifies the resource (player), the lookup methods (id or name substring), and the scope (rosters and free agents). This distinguishes it from sibling tools like get_rosters or get_free_agents, which list collections rather than look up a single player.

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 a single player by id or name. It doesn't explicitly state when not to use it or name alternatives, but the context of siblings (get_rosters, get_free_agents) makes the distinction clear. It could be improved by explicitly saying 'use get_rosters to list all players' but the current wording 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds behavioral scoping (team_id limits to one team) and enumerates the returned fields (position, injury status, lock state, etc.), which goes beyond the annotations and gives the agent a clearer picture of what to expect. This exceeds the minimal baseline for annotation-covered tools.

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 filler. The first sentence front-loads the core purpose and scoping, the second succinctly lists the player fields. Every word earns its place, and the length is appropriate for the tool's simplicity.

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 a simple read operation with all parameters optional and fully described in the schema, an output schema is present (so return format is covered), and annotations cover safety. The description adds the team_id scoping and field list, which is enough for an agent to call it correctly. No critical gaps exist.

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 all 4 parameters, so the baseline is 3. The description adds meaning to team_id by clarifying that it limits results to one team, which is a meaningful semantic beyond the schema's 'Limit to one team id.' The other parameters (sport, season, league_id) are already well-described in the schema, so the description's additional value is moderate but sufficient to warrant a 4.

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 returns rosters, with an explicit scoping condition ('or one team's roster if team_id is given'). It distinguishes from siblings like get_teams (teams vs. rosters) and get_free_agents (free agents vs. rosters) by naming the specific resource (rosters) and the player fields included. This is a specific verb+resource with clear 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 description gives a usage condition for team_id ('if team_id is given') but does not explicitly state when to use this tool over alternatives like get_teams or get_free_agents, nor does it mention exclusions. The usage context is implied but not explicit, so it falls short of providing clear alternative routing.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds the specific fields returned, which is useful context, but it doesn't mention any behavioral nuances like pagination, ordering, or potential response size. Since annotations carry the load, a 3 is appropriate.

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

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

A single, efficient sentence with zero filler. The key action and resource are front-loaded ('All teams in the league'), followed by the returned fields. No unnecessary words or repetition.

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 an output schema present, the description doesn't need to detail the return structure. The high-level summary of fields, combined with full schema coverage and annotations for safety, gives an agent everything needed to invoke this tool correctly. Nothing is missing for a straightforward read operation.

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 each parameter (sport, season, league_id) having a clear description and defaults. The tool description adds no additional parameter-level information beyond what the schema already provides. Baseline 3 is correct when the schema is exhaustive.

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 ('get') and resource ('teams'), and lists the exact fields returned (id, name, owners, record, waiver rank). It clearly distinguishes this from sibling tools like get_rosters (which would return roster data) and get_league (which would return league settings). No ambiguity.

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: it returns all teams in the league. It doesn't explicitly mention when not to use it, but the scope is obvious and it doesn't conflict with any sibling. For a simple read-only getter, this level of guidance is sufficient, though it could have named alternatives for contrast.

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 it read-only, idempotent, and non-destructive; the description adds the pagination envelope (total/count/offset/hasMore), ordering, and player-name resolution, none of which is visible in annotations or schema. No contradiction with 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?

Three sentences carry all the meaningful behavioral information with no filler. The core act is front-loaded and the pagination warning is placed immediately where the agent will need it.

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 paginated list tool with 100% schema coverage, full annotations, and an output schema, the description covers everything an agent needs to select and call it correctly. It even preempts the common failure mode of expecting all records in one response.

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 explains limit, offset, sport, season, and league_id. The description reinforces that limit/offset are necessary for paging, but adds no new parameter-level detail 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?

States a specific verb and resource ('Executed transactions') with categories (adds, drops, trades, lineup moves, draft picks), a defined ordering (most recent first), and a transformation trait (items resolved to player names). The qualifier 'executed' distinguishes it from the sibling get_pending without needing to open that 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?

Gives explicit operational guidance: it is paginated and limit/offset should be used because a season's draft alone can be 100+ records. It stops short of explicitly naming an alternative such as get_pending for pending/unprocessed transactions, so the when-not-to-use guidance is implied rather than direct.

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 readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds that the tool refuses if the player isn't eligible or is locked, and the dry_run parameter in the schema adds safety context. It doesn't contradict annotations. It could mention whether it's reversible, but the refusal conditions and dry_run default provide meaningful behavioral context.

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, front-loaded with the core action and scope, followed by refusal conditions. No wasted words. 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?

The tool has an output schema, so return values are covered. The description covers the core behavior, refusal conditions, and the dry_run safety mechanism is in the schema. It doesn't explicitly mention the relationship to activate_from_ir, but the sibling list and description are sufficient for an agent to call it 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 67%, and the description doesn't add much parameter-level detail beyond what the schema provides. The dry_run parameter is well-documented in the schema. The description's mention of 'refuses if not eligible' relates to player_id semantics but doesn't add new parameter meaning. 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 action ('Move one player into the IR/IL slot'), the resource (player), and the context (as a lineup move). It also distinguishes itself from siblings by mentioning IR/IL eligibility and lock refusal, which differentiates it from activate_from_ir and set_lineup.

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 a player is IR-eligible and the user wants to make a lineup move. It doesn't explicitly name alternatives like activate_from_ir, but the context and sibling list make the use case clear. It also states refusal conditions (not eligible or locked), which helps an agent decide 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.

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

Beyond the near term read-only/idempotent/destructive annotations, it adds critical behavioral detail: this is a heuristic, not guaranteed optimal; bye-week/no-game players rank 0 for a given scoring period; locked players keep their slot; and it is a suggestion that does not modify. This is rich context that a caller must know to trust the output.

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 run-on-style paragraph that front-loads the mechanism, then gives heuristics and cautions. It is not overly bloated—each sentence carries a distinct fact (algorithm, non-optimality, ranking period, locked players, apply-offloading). A tiny bit more line break would improve scannability, but it's far from verbosity.

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 output schema present and safety annotations already in place, the description fills all functional gaps: what it suggests, how it picks slots, what numbers it uses (season vs scoring period), how locked players behave, and how to apply the result. No missing information that would prevent a 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?

The schema already documents sport, league, etc. The description adds meaningful behavior for scoring_period_id (ranks by that period, modifies bye-week behavior) and overall ties the heuristic to 'best projection'. It doesn't explain team_id's enumeration but the default of 1 and the 'one team' wording make it adequate; the description adds 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 states a specific verb ("suggests") and a specific resource ("a starting lineup for one team"), and it goes further by contrasting its purpose with set_lineup ("pass the resulting moves to set_lineup yourself"). This clearly differentiates it from siblings like get_rosters and set_lineup.

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 says the tool is a non-committal suggestion and that the caller should invoke set_lineup to apply the moves. It also tells the agent when to add scoring_period_id (when ranking by a specific period) and clarifies the two different projection modes.

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?

The description goes beyond annotations by revealing the local validation phase, noting that validations happen before anything is sent, and stating that rejected moves are reported with a reason and never sent. Annotations already indicate this is a non-read operation, so this context meaningfully adds to the behavioral model.

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. Every sentence carries distinct information: what the tool does, how validation works, and what happens with rejected moves. There is no filler or repetition.

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 is adequate considering the rich schema (defaults, dry_run behavior, slot ID references) and the annotation set. It could be clearer on whether valid moves are sent if any rejected ones exist, but the schema, output schema, and annotation hints fill most remaining gaps.

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 about 67%, and the description adds real meaning to the 'moves' parameter by enumerating validation rules: player must be on the roster, slot eligibility, player not locked, and lineup must respect slot counts. It also clarifies that this is a batch operation, which is not in the schema itself.

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, 'Apply a batch of lineup moves to one team,' and clearly differentiates this from sibling tools like add_free_agent, move_to_ir, or activate_from_ir. It communicates both the batch nature and the one-team 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 description implies usage when the user wants to set or adjust a lineup, but it does not explicitly contrast with alternatives or say what it's not for. There is no explicit 'when to use vs. not use' guidance, only indirectly derived from the operation name and wording.

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, openWorldHint, idempotentHint, and destructiveHint=false, covering safety and idempotency. The description adds valuable context about the exact output format, including the line structure and markers, which goes beyond annotations and helps the agent understand what the tool returns. No contradiction with 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 packs all essential information: the output format, the file reference, and the components. It is concise with no filler, though it could be slightly restructured to front-load the action (e.g., 'Generates a league snapshot in...') for even quicker comprehension.

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 fully specifies the output format, listing all line types and markers. All three parameters are optional with defaults, so there are no ambiguous inputs. The tool's read-only nature is covered by annotations, and the output is thoroughly described, leaving nothing an agent needs to call it 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 100%, so each parameter (sport, season, league_id) is already documented with defaults and enums. The description adds no parameter-specific meaning beyond what the schema provides, 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 clearly specifies the resource (the league) and the output format (line-oriented text with specific rows and markers). It distinguishes this tool from siblings like get_teams or get_league, which return structured data, by emphasizing the exact text format used for diffing. The title 'League Snapshot' reinforces the purpose.

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 for diffing via the reference to 'frontoffice-manager's tools/diff-snapshot.mjs', but it does not explicitly state when to use this tool instead of alternatives like get_league or get_rosters. It lacks explicit exclusions or conditions, leaving the decision to the agent's 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?

Annotations already indicate readOnlyHint=false, so the write nature is known. The description adds only that it's a waiver claim with optional drop, but doesn't disclose side effects like pending status, processing time, or failure conditions. With openWorldHint=true, more behavioral context is expected but missing. No contradiction with 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 redundancy. The core purpose is front-loaded, and the bid clarification is placed after. 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 claim tool with 8 parameters, the description covers the essential action but misses sibling differentiation (e.g., when to prefer add_free_agent) and doesn't mention that claims are processed asynchronously. Output schema exists, so return values are covered, but the context around claim lifecycle is incomplete.

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%, and the description compensates partially: it explains bid's league-type dependency and hints at the conditional drop. However, add_player_id, drop_player_id, and team_id are left undocumented in both schema and description, leaving gaps for a new agent.

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 verb and resource: 'Submit a waiver claim, optionally with a conditional drop.' This is specific and distinguishable from general roster actions. However, it doesn't explicitly contrast with sibling tools like add_free_agent, so it doesn't fully differentiate in purpose.

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 no guidance on when to use this tool versus alternatives such as add_free_agent or cancel_claim. It does offer a parameter-specific tip about bid usage in FAAB vs priority-waiver leagues, which is helpful for invoking correctly, but not for choosing the tool. No when-not-to-use or alternative references.

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