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

With no annotations, the description carries the full burden and does well: it discloses what the output contains (token length, shape, source from environment or config file), that a live check is made against Sleeper, and the common delivery failures it detects. The privacy guarantee that the token itself is never emitted is genuinely valuable. It does not state whether the call has any side effects or its cost/rate characteristics, leaving a modest 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?

Four short sentences, with the trigger condition placed immediately after the purpose statement so an agent sees when to call it early. The first sentence is slightly abstract in isolation, but nothing is padded or redundant.

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?

An output schema exists, so return-value documentation is not required, yet the description still characterizes the output, which is a bonus. For a zero-parameter diagnostic with a rich output schema, the only meaningful omission is pointing at setup_token when the diagnosis is that no valid token exists.

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 takes zero parameters, so there are no argument semantics to explain; per the rubric a 0-parameter tool baselines at 4. Nothing in the description is needed to compensate for schema gaps.

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 concrete statement of what is reported: the source of each setting and whether the token works. That is a specific diagnostic purpose, not a restatement of the name. It stops short of differentiating from the one obvious sibling, setup_token, which an agent would need to distinguish this read-oriented diagnostic from the token-writing 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?

"Call this first when a write or an authenticated read fails" gives a clear, actionable trigger condition. There is no explicit when-not or naming of alternatives such as setup_token for the case where the token needs to be set rather than diagnosed, so it falls short of full routing guidance.

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

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

No annotations, so the description carries the load — and it does well: it discloses the ranking methodology (change in target/carry share), the free-agent roster filter, and the min_snap_share rationale (below it, a spike is garbage time). It does not discuss permissions or auth, but the output schema covers return values.

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?

Front-loaded purpose sentence, then a tightly reasoned justification, then an Args block. The comparative paragraph is dense but every clause conveys actionable information rather than padding.

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 six-parameter tool with an output schema, the description covers scope (free agents), method (share change), all parameters with defaults, and the caveat that drives result quality. Nothing an agent needs to select or call 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 coverage is 0%, so the description must carry all six parameters — and it documents every one, including position options, weeks semantics ('completed weeks'), defaults, season format, and league override. The min_snap_share explanation adds real meaning beyond the schema's bare 0.25 default.

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+resource with scope: free agents in the league ranked by the change in their share of team targets and carries. It explicitly distinguishes itself from the sibling waiver_targets by naming what that tool does and why this one differs.

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

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

Explicitly says when this tool matters versus waiver_targets: waiver_targets prices by projection, projections lag usage by a week, so this tool is the earlier signal. That is a concrete when-to-use and when-the-alternative-fails rule, not implied guidance.

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

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

With no annotations, the description carries the full behavioral burden and discloses important semantics: missing players in a played week are reported as UNKNOWN rather than scored as zero, preventing hidden holes. It does not explicitly state that the tool is read-only or mention authentication, but the query phrasing and output-schema presence make the safe-read nature reasonably clear.

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 core purpose is front-loaded in the first line, and the IMPORTANT note is useful. However, the description includes rationale and colorful explanation ('that is how a hole gets hidden until Sunday') that could be trimmed for an agent-facing tool definition.

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 output schema exists, so return-value details are not needed, and the description adequately explains the tool's behavior and parameters. It lacks explicit authentication or when-not-to-use guidance, but for a read-oriented bye-week projection tool it is largely 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 0%, so the description must compensate. The Args section documents all three parameters meaningfully: league_id_ and roster_id_ default to SLEEPER_LEAGUE_ID and SLEEPER_ROSTER_ID, and through_week is described as the last week to project with default 17.

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 outcome: identifying upcoming weeks where the user cannot field a legal lineup, and why. It implicitly covers bye weeks by explaining that a player on bye returns no projection, though it does not explicitly distinguish this tool from siblings like player_outlook.

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 conceptual context for using the tool, such as 'absence IS the bye' and that no separate bye table is needed, which implies its purpose. However, it gives no explicit when-to-use guidance, no exclusions, and no named alternatives such as player_outlook or roster.

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

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

With no annotations, the description carries the full burden; it does disclose the operation is a WRITE and that it targets a pending claim. However it never explains the `confirm` flag's role, whether cancellation is reversible, or any permission/rate-limit constraints for a mutating call.

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 short lines, front-loaded with the WRITE flag and the core action, followed by prerequisite and usage context. 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?

An output schema exists so return values need no explanation, and the core action is covered. Gaps remain for an un-annotated mutation: the confirm parameter and any destructive/reversibility semantics are unaddressed.

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 0% and there are 4 parameters. The description clarifies only `transaction_id` (retrieve it from `pending`) and leaves `leg`, `confirm`, and `league_id_` entirely undocumented — notably `confirm`, which materially changes invocation behavior.

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 ('Withdraw one of your pending waiver claims') with an explicit WRITE marker. It is clearly distinguishable from the sibling `pending` (which it names as the source of the id) and from `waiver_claim`.

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 a concrete usage window ('when news lands after a claim goes in and before waivers process') and a prerequisite action ('Get transaction_id from `pending`'). No explicit when-not-to-use or statement of what happens to the claim after cancel, but the context is clear.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the auth requirement ('Needs a token'), a specific failure mode (invalid `order_by` returns HTTP 500 rather than a clean error), and that sorting is done client-side. It also flags the prompt-injection surface of message content, which is exactly the kind of non-obvious trait annotations never cover.

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?

Front-loaded with purpose, then two clearly labeled blocks (GOTCHA, SECURITY), then args. Every section earns its place, though the SECURITY block is somewhat verbose relative to the rest and could be tightened without losing meaning.

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?

Complete for a 3-param read tool: auth, failure modes, parameter defaults, and content-safety guidance are all present, and an output schema exists so return values need no prose. Nothing an agent needs to call this 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 0%, so the description must compensate, and it does — all three params are explained: `league_id_` defaults to SLEEPER_LEAGUE_ID, `limit` is count of recent messages defaulting to 25, and `search` is a case-insensitive substring filter. This adds real meaning the bare schema does not.

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 — 'Read the league chat' — which is unambiguous against the sibling list, none of which touches chat. It stops short of naming scope boundaries (e.g. whether it covers DMs vs league-wide), so it lands at a clear-but-not-exhaustive 4.

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 concrete operating context: a token is required, defaults are documented (SLEEPER_LEAGUE_ID, limit 25), and the `order_by` gotcha tells the agent how to use the args safely. It doesn't say when to prefer this over another data source, but no sibling competes for this resource.

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

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

With no annotations, the description carries the full burden and it does disclose two real traits: the result is filtered to traded picks only, and an auth token is required. It omits the safety profile (that this is a read-only query), any pagination/limit behavior, and what the league_id_ argument actually does.

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 short lines, front-loaded with the core purpose and followed by the scope caveat and auth note. No wasted sentences, though the hard line breaks read slightly like fragments rather than prose.

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?

An output schema exists, so return values need no explanation, and for a single-parameter read tool the description covers purpose, result scope, and auth. The only real gap is that the league_id_ input is left entirely undocumented.

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% and the single parameter league_id_ is never mentioned in the description. The agent must infer from the name alone that it scopes the query to a league, so the description fails to compensate for the coverage gap.

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 resource (future draft picks) and the exact scope of the query (those that have changed hands). It is clearly distinct from siblings like keepers or trade_block, though it never names an alternative to disambiguate against.

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?

"Only TRADED picks appear — a manager who still holds all of his own shows nothing" tells the agent when results will be empty, which is genuinely useful usage context. However, there is no explicit when-to-use-vs-alternatives guidance or statement of prerequisites beyond the token note.

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

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

With no annotations, the description carries the full behavioral burden and usefully discloses that no token is required and all data is public, which is exactly the auth context an agent needs before calling. It does not cover failure behavior (e.g. unknown username) or any rate limits, so it is adequate rather than rich.

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?

Purpose is front-loaded, followed by the critical 'start here / no token' guidance, then the args. The Args block is slightly verbose but justified given the schema carries no parameter descriptions.

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?

An output schema exists, so return values need not be explained. Given that, the description covers what an agent needs: what the tool produces, that it is the prerequisite for other tools, that no auth is required, and the meaning/format of both parameters.

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, and it does: username is clarified as 'the display name you log in with' (not an id or email) and season is given a format example ('2026') plus the real default behavior ('current season'), which the schema's empty default string does not convey.

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 ('Look up') and exactly what is returned: the Sleeper user id, the leagues, and the roster id within each. This distinguishes it from siblings like league_info, roster, and standings, which all operate on ids this tool produces.

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?

'Start here. Everything this returns is what the other tools need' is an explicit, actionable usage directive that positions the tool as the bootstrap step and implies the other tools depend on its output. It lacks an explicit when-not/alternative clause, but for a root entry-point tool that guidance is largely 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that the two keeper lists often disagree and that reporting either as "the keepers" would be wrong, which is useful behavioral context. However, it doesn't describe return format, pagination, permissions, or side effects (though it's likely read-only).

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 front-loaded with the key distinction and then lists arguments. It is appropriately sized without redundancy. The opening sentence is slightly vague ("Who was kept...") but the following sentences clarify 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 that an output schema exists, the description needn't explain return values. It covers the core conceptual distinction and both parameters. It lacks explicit usage guidance versus siblings, but for a read-only keeper-info tool with an output schema, this is fairly 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 0%, so the description must compensate. It does explain both parameters: `history` ("Also show previous seasons. Default True") and `league_id_` ("Override the configured league"). This adds meaning beyond the schema's bare titles, though it could specify format or valid values for `league_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?

The description clearly states the tool's subject: keeper records and designation rules. It distinguishes two data sources (`is_keeper` from draft vs `roster.keepers` for the next draft), which is a specific and helpful distinction. However, it doesn't explicitly name sibling tools like `set_keepers` or `draft_picks`, so sibling differentiation is implied but not stated.

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 (to inspect keeper status and rules) by contrasting the two data sources, but it doesn't explicitly say when to use it versus alternatives like `draft_picks` or `roster`. It also doesn't mention 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?

With no annotations, the description carries the full burden. It conveys the key behavioral trait that the returned settings alter the meaning of other tools' outputs, which is genuinely useful context, but it never states that it is a read-only lookup, nor mentions auth or caching behavior.

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?

Front-loads the core insight that league settings govern how other outputs are read, then explains the impact in one further sentence. The Args block is slightly formal but earns its place by documenting the default.

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?

An output schema exists, so return values are not the description's job, and the single optional parameter is addressed. For a one-parameter read tool this is largely complete, with only the read-only nature left implicit.

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 0% and the schema only shows an empty-string default. The description adds real value by clarifying the default source ('Defaults to SLEEPER_LEAGUE_ID'), but gives no format or validation detail for the single optional parameter.

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 precisely (league settings: scoring, roster slots, waiver type, trade rules) and frames why it matters, so an agent knows it returns league configuration. It lacks an explicit retrieval verb and does not distinguish itself from any sibling, keeping it just below the top band.

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 strongly implies when the tool matters — before interpreting other tools' output, since settings 'silently change what a tool's output means' — but states no explicit when-to-use conditions or alternatives. Usage is inferable rather than 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 full burden and does so well: it discloses that `matchup_legs` is an authenticated query, that it returns 'Unauthorized' without a token, and that the tool degrades to public REST giving pairings without projections instead of failing. That is exactly the kind of non-obvious behavior an agent needs.

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 core purpose is front-loaded in one sentence, and the auth fallback caveat follows immediately. The Args block is compact and each line adds information not present in the schema.

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?

An output schema exists, so return values need not be explained, and the description covers the key operational caveat (auth-dependent projection availability) plus both parameter defaults. Only the week parameter's valid range and the practical difference between authenticated and fallback output shape are left implicit.

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, and it does: it explains that league_id_ defaults to SLEEPER_LEAGUE_ID and that week 0 means the current week. The raw schema only shows empty/0 defaults with no 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?

States a specific verb+resource: 'This week's matchups and every team's projected total.' An agent can tell it deals with weekly matchups and projections, distinguishing it from siblings like matchup_odds or standings, though it does not explicitly name a sibling to route away from.

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 conditions behavior on authentication ('without a token ... falls back to public REST'), which is useful usage context, but it never says when to prefer this tool over matchup_odds or roster. Usage is implied rather than explicitly scoped.

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, so description must carry the full behavioral burden. It explains the statistical model (normal distribution around estimated strength, noise adjustment) which is useful, but does not explicitly state read-only nature, authentication requirements, or league configuration assumptions.

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?

Front-loaded purpose, followed by a concise model explanation, then an Args list. Every sentence adds value; no 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?

Output schema exists, so return values need not be explained. The description covers purpose, model, and parameters. Missing explicit safety profile (e.g., read-only) and prerequisites, but adequate for a probabilistic odds 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 0%, so the description must explain parameters. It does so for both: week (which week, defaults to current) and league_id_ (overrides configured league). Clear semantics, though no format details beyond schema types.

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 resource and computed metric: win probability for every head-to-head matchup in a week. Clear what the tool does, but does not explicitly distinguish it from sibling tools like matchup or playoff_odds.

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 on when to use this tool versus alternatives such as matchup or playoff_odds. Usage is only implied by the purpose statement.

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 burden and does well by explaining that pending items come from the REST transactions feed because Sleeper has no GraphQL query for trades. It also notes the dependency on transaction_id for actions. It doesn't describe pagination, rate limits, or authentication needs, but it provides key operational 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?

The description is four sentences, front-loaded with the core purpose, then immediately provides crucial context about the data source and ID dependency. Every sentence earns its place with no 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?

The tool has an output schema, so return values needn't be detailed. However, with zero annotation coverage and 0% parameter description coverage, the description leaves parameters entirely undocumented. It covers why the tool exists and its operational context, but the parameter gap reduces completeness.

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 for the two parameters (week and league_id_). The description does not mention either parameter or their meaning/defaults. This is a significant gap; the agent must infer that week and league_id_ are needed to scope the query.

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 it returns pending trades and waiver claims plus the IDs needed to act on them. It distinguishes itself from siblings like transactions and waiver_targets by its focus on actionable pending items with IDs. It's slightly less specific about the exact return format but the verb+resource is clear.

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

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

The description explicitly states that accept_trade, reject_trade, and cancel_waiver_claim need a transaction_id and this is the only place to get one. This tells the agent when to use this tool: before acting on a trade or waiver claim. It doesn't state when not to use it, but the context is clear.

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

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

No annotations are provided, so the description carries the full burden, and it discloses the most important behavioral trait: the confirm flag gates a dry-run by default, which is a real safety mechanism an agent must understand. It does not cover auth requirements, whether an existing pick is overwritten, or error behavior, but the critical send-gate is surfaced.

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?

Front-loads the 'WRITE.' marker and the core action, then an Args block with examples. Efficient and well-ordered, though the 'may be the only way to fix an entry' sentence is slightly redundant with the no-web-interface point.

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?

An output schema exists, so return values need not be described, and the confirm/dry-run mechanism is covered. The gap is the three undocumented optional parameters (week, pickem_league, pickem_roster) with no annotations to fall back on, leaving the agent unsure whether they must be supplied for 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?

Schema description coverage is 0%, so the description must compensate, and it does well for three of six params (game_id with a Sleeper example, team with an abbreviation example, confirm with dry-run semantics). However, week, pickem_league, and pickem_roster are entirely undocumented in both schema and description, leaving half the parameters ambiguous.

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 ('Make or change one pick'em pick') and prefixes the mutation nature with 'WRITE.' It also distinguishes itself from the read sibling by directing the agent to pickem_status for game_id, so the agent can tell it apart without opening a 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?

Gives concrete operating context: get game_id from pickem_status, and confirm must be True to actually send (default False = dry run). It also notes Pick'em has no web interface, explaining why the tool exists. It stops short of explicitly naming a when-not/alternative for the write itself.

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

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

With no annotations, the description carries the full burden and does well for a read tool: it discloses the mobile-only nature of pick'em and the key semantic that a missing pick is 'silently a zero,' which is behavioral insight not derivable from the schema. It could still note whether the entry requires auth or specific league/roster setup.

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?

Front-loaded with purpose, then a genuinely useful behavioral note, then an Args block. Well-structured and mostly tight, with only mild redundancy between the framing sentence and the args list.

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 status tool with an output schema (so return values need not be explained) and three optional, description-justified params, the definition supplies everything an agent needs to invoke 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 coverage is 0%, so the description must compensate, and it documents all three args: week (0 = current week), pickem_league and pickem_roster defaulting to env vars. This resolves the ambiguous 0/"" defaults in the schema, though it doesn't state the roster type or valid week ranges.

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 resource and outcome: 'Your pick'em entry: which picks are in, and which are missing.' This clearly distinguishes it from the sibling pickem_pick tool, which would be for submitting picks, so an agent can route without opening either 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?

Provides clear usage context: pick'em is mobile-app only, so this is often the only way to check an entry from desktop. This tells the agent when the tool is needed, though it never explicitly names alternatives or states 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?

With no annotations, the description carries the full burden and does so reasonably: it warns 'NEEDS A TOKEN, unlike most reads here,' and discloses that history spans seasons via the previous_league_id chain. It doesn't state whether the call mutates anything (it clearly doesn't) or any rate limits, but the auth and scope disclosures are valuable.

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?

Front-loaded with the core purpose and the token requirement, followed by Args. The prose paragraphs on free-agent reasoning and cross-season history are somewhat expansive but each adds useful decision context, with little pure 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?

Given no annotations, an output schema present, and 0% schema coverage, the description covers purpose, auth, cross-season scope, and all three parameters. It is close to complete for an agent to invoke correctly, with only minor gaps like no mention of ordering or result shape.

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 and does: it explains player_name accepts full or partial names, limit sets transaction count (default 25), and league_id_ overrides the configured league. This adds meaning well beyond the bare schema types.

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: 'Every time this league has added, dropped or traded one player.' The 'one player' scoping distinguishes it from the broader 'transactions' sibling, though no sibling is named explicitly, so an agent must infer the boundary.

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

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

It gives concrete usage context: 'Useful for deciding whether a free agent is genuinely available or merely between owners,' framed by the waiver-wire example. That is clear when-to-use guidance, but it names no explicit alternative tool or exclusion condition.

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

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

No annotations are provided, so the description carries the full burden; it does disclose that this is reportage (read-only news text) and explains where the reasoning lives ('did not participate' vs 'limited in practice'). It does not cover freshness window, source, or ordering, though the output schema exists and can carry return structure.

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 core is tight, but the middle sentence is stretched across six lines with indentation and a stylized block about where 'REASONING lives', which is atmospheric rather than operational. Front-loading is fine; the verbosity is not.

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?

Two params, one required, output schema present, so the main gaps are behavioral rather than structural. The description gives the agent enough to call it correctly and understand why the return text matters, but leaves freshness, ordering, and read-only status unstated.

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, and it does: player_name is 'Full or partial name' and limit is 'How many items. Default 4.' Both parameters get meaning beyond the bare schema titles.

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 (reporting) and a specific resource (recent beat reporting for one NFL player), so an agent can tell it apart from player_outlook, player_signal, or player_history. It does not explicitly name how it differs from those siblings, which keeps it short of a 5.

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 want the explanatory text behind an injury tag or practice status — but does not state when-not, nor name an alternative sibling such as player_outlook. Usage is inferable but not spelled out.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that a result may not exist ('if one has been published'), but adds no detail on permissions, rate limits, or what the response contains beyond relying on the output 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?

Front-loads the core purpose, and the news-differentiation sentence earns its place. The Args block is slightly boilerplate but carries genuine parameter meaning rather than padding.

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?

An output schema exists, so return-value detail is unnecessary, and the description correctly captures the conditional (may-not-exist) nature of a read tool. Minor gaps remain, such as the expected season format, but nothing essential 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?

Schema description coverage is 0%, so the description must compensate, and it does explain both parameters: player_name accepts 'Full or partial name' (implying partial matching) and season 'Defaults to the current season.' This adds real semantics the bare schema titles lack.

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+resource: retrieving a written season outlook for a single player. It explicitly distinguishes itself from a named sibling concept by noting it is 'a full preview of the season rather than a dated item,' so an agent can separate it from player_news without inspecting schemas.

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 clear context ('if one has been published') and differentiates the tool from news items, which is the most likely confusion. It stops short of naming an explicit alternative or when-not-to-use rule, so it is clear context rather than full routing guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it discloses almost nothing: not what 'your signal' is, where it comes from, how fresh it is, or what auth/setup it requires (the sibling list includes auth_status and setup_token, suggesting auth matters). Only the hint of a comparison against Sleeper's view adds any 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?

It is a single short sentence with no filler, which is good. However, it is front-loaded with an opaque phrase ('your signal') rather than the action, so brevity comes at the cost of intelligibility.

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 presence of an output schema excuses the description from explaining return values, but given a zero-annotation, zero-schema-description tool in a domain full of overlapping siblings (signal_divergence, player_outlook, trending), the description is too thin to let an agent select and invoke it confidently.

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% for the single required parameter, so the description must compensate – and it does not mention 'player_name' at all, merely 'one player'. The parameter name is self-explanatory enough to avoid a 1, but the description adds no semantics such as accepted name formats or ambiguity handling.

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 is essentially a marketing tagline: 'What your signal says about one player, next to Sleeper's own view.' There is no verb (get/show/compare) and no statement of what is actually returned. It hints at a domain (comparing a personal signal against Sleeper's evaluation) but an agent cannot tell what the tool does or how it differs from the sibling 'signal_divergence'.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. The sibling 'signal_divergence' is plausibly related, yet the description offers no condition for choosing one over the other. Usage is left entirely 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?

With no annotations the description carries the full burden, and it delivers a genuinely important behavioral caveat: seeds are provisional until the regular season ends, Sleeper re-seeds as standings move, and 'the output says which of the two it is looking at.' It doesn't cover auth or rate limits, but the provisional-seed disclosure is the key behavioral trait an agent needs.

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?

Front-loaded with the core identity, then the sibling routing, then the provisional-seed caveat, then args. Prose is a touch chatty but every sentence earns its place; nothing is wasted.

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?

An output schema exists, so return values need not be explained, and the description fills the remaining gaps: what the tool is, when it supersedes playoff_odds, the provisional-seed risk, and all three args. Nothing an agent needs to call 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 coverage is 0%, so the description must compensate — and it does, documenting all three params: consolation as the losers' bracket vs championship, previous as the prior season, and league_id_ as an override of the configured league. It adds clear meaning beyond the bare 'boolean'/'string' types in 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?

States a specific verb+resource — 'who plays whom, and who has won' — and immediately frames it against the sibling playoff_odds as 'the real thing rather than a simulation.' An agent can distinguish it from playoff_odds without opening either 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?

Gives explicit when-to-use guidance: from the first playoff week it 'replaces playoff_odds entirely,' with the reasoning that once the field is set there is nothing left to estimate. The alternative and the switching condition are both named.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the simulation method, the tie-breaking rule (points for, Sleeper default), and that output reports its own confidence rather than a uniformly solid number. It stops short of stating read-only status or cost/runtime.

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?

Purpose is front-loaded in the first line, with methodology and caveats following in an organized way. The confidence paragraph is mildly long-winded but each sentence adds real context.

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?

An output schema exists, so return values need not be explained, and the description covers method, parameters, tie-break behavior, and confidence signaling. The main omission is any routing guidance relative to sibling odds/standings tools.

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 0%, so the description must compensate, and it does: trials is explained with its default effect on error margin, and league_id_ is described as overriding the configured league. Both parameters gain meaning beyond the bare 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?

States a specific verb and resource: computing playoff probability for every team via season simulation. An agent can distinguish it from bracket-style siblings by the simulation framing, though it never names a sibling it is not.

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 implies when it applies (a full-season playoff outlook rather than a single matchup), but gives no explicit when-to-use guidance and names no alternatives among matchup_odds, playoff_bracket, or standings.

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 burden and does well: it discloses that this reaches a real person, that acceptance can execute instantly in certain leagues, and that confirm=False is a dry run. It omits auth requirements and any rate or idempotency notes, but the key side-effect risk is surfaced.

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?

Front-loads the operation type and the risk warning before the argument list; every line earns its place with no redundant restatement of the schema.

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 7-parameter mutation tool with an output schema and no annotations, the description covers the action, the critical league-dependent risk, and most parameters. The only gaps are the two undocumented internal ID parameters and any post-send return expectations, which the output schema addresses.

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 documents give_players (from your roster), receive_players (from theirs), with_manager, faab, and confirm's dry-run semantics. Only league_id_ and roster_id_ are left unexplained, which are likely context-injected defaults.

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?

Opens with a specific verb+resource (offer a trade to another manager) and flags it as a WRITE operation. It is distinguishable from siblings like respond_trade or cancel_claim, though it does not name those alternatives explicitly.

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 tells the agent to consult league_info for trade_review_days and explains the consequence when it is 0 (executes immediately, no vote, no veto window). It also states the confirm-default-dry-run condition, giving clear when-to-send guidance.

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

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

With no annotations, the description carries the full burden and does disclose the critical trait: accepting may be irreversible, executing immediately when trade_review_days is 0. It omits what the returned result contains, whether the write needs confirmation via the `confirm` param, and any permission/auth requirements, so it is strong but not exhaustive.

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 leading 'WRITE.' marker front-loads the operation class, and the irreversibility warning is placed before the argument notes. The 'Args:' block is minimal and earns its space, though the trailing formatting is slightly loose.

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?

An output schema exists, so return values need no explanation, and the destructive/write nature is covered. The remaining gap is the undocumented non-required parameters (confirm, leg, league_id_), which an agent cannot infer from anywhere.

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 0% across 5 parameters, so the description must compensate. It documents the `response` value set and where transaction_id comes from, but leaves `leg`, `confirm`, and `league_id_` entirely unexplained in both description and 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?

States a specific verb pair (accept/reject) and resource (a trade offered to you), which cleanly separates it from propose_trade and trade_block among the siblings. An agent knows exactly what operation this performs without opening 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?

It explicitly routes the agent to the `pending` sibling to obtain transaction_id, which is actionable context. It does not explain when to prefer reject vs accept or when the veto window applies beyond the trade_review_days=0 case, so it stops short of full when/when-not guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that points are computed from raw components against league.scoring_settings rather than Sleeper's generic pts_ppr, which is real behavioral context. But it says nothing about auth requirements, read-only nature, or defaults resolution beyond the Args section.

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 core purpose is front-loaded in the first line, followed by a scoped explanation and a compact Args block. The middle scoring-explanation sentence is slightly verbose but earns its place by justifying why league-specific scoring matters.

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?

An output schema exists, so return values need not be described. Combined with the front-loaded purpose, default-resolution notes, and scoring behavior, the definition gives an agent enough to call the tool correctly; only the absence of any safety/auth context holds it back.

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, and it does: it documents all three parameters, including the defaulting behavior for league_id_ (SLEEPER_LEAGUE_ID), roster_id_ (SLEEPER_ROSTER_ID), and week (0 = current week). This adds meaning well beyond the empty schema, though it omits valid ranges or formats.

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 resource ('your roster') and adds a specific qualifier ('weekly projections, scored under THIS league's rules'), which is far more informative than the bare tool name 'roster'. It implicitly distinguishes itself from generic projection sources by emphasizing league-specific scoring, though it never names a sibling tool it competes with.

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 explains the scenario where this tool matters (half-PPR, first-down-scoring, TE-premium leagues where it diverges from Sleeper's pts_ppr), which implies when to reach for it. However, there is no explicit when-to-use versus alternatives such as matchup, standings, or player_outlook, leaving 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 full behavioral burden. It transparently describes the underlying computation (averaging remaining opponent strength) and implies a read-only analytical operation, but says nothing about how results are structured, direction/interpretation, or any cost/rate considerations.

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?

Purpose is front-loaded in the first sentence, followed by supporting explanation and an Args block. The middle sentences add motivation and are mildly verbose, but the structure is clean and nothing is seriously wasted.

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?

An output schema exists, so return values need not be explained. The description adequately conveys what the tool computes and clarifies the sole parameter, leaving an agent able to invoke it correctly; only the interpretation of the numeric output is left implicit.

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% for the single parameter, but the description compensates by explaining it: 'league_id_: override the configured league,' which clarifies the default-configured context. That meaning is genuinely added beyond the bare schema, though there is only one param and detail is thin.

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

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

The description states a specific computation: it averages the strength of every remaining opponent to produce a schedule-difficulty figure. This is a clear verb+resource that an agent can distinguish from analytics siblings like playoff_odds or matchup_odds. It does not explicitly name a sibling, so it stops short of a 5.

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 motivational context ('this is the part of a playoff race nobody tracks') but no actual when-to-use guidance, no condition selecting this over sibling tools such as playoff_odds, and no exclusions. The agent must infer the usage scenario.

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 well: it discloses the write operation, explains that the list is complete rather than a delta, that an empty list clears IR, and clarifies Sleeper's roster/IR subset modeling. It does not cover confirmation behavior, permissions, or rate limits.

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 front-loaded with the core action and then adds relevant caveats. The three short paragraphs are mostly informative, though the NOTE section is somewhat detailed for the core task.

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 write tool with no annotations and four parameters at 0% schema coverage, the description covers behavioral context well but is incomplete on parameter semantics and usage decisions. The output schema exists, so return values are adequately handled elsewhere.

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 partially explains the main list semantics but refers to it as `reserve` rather than the actual `player_names` parameter, and it omits `confirm`, `league_id_`, and `roster_id_` entirely, leaving three of four parameters unexplained.

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: 'Set which players occupy your IR slots.' It is clearly distinct from siblings like set_lineup or set_keepers, and the leading 'WRITE' signals the operation class.

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 does not say when to use this tool versus alternatives such as set_lineup. It only notes that injury eligibility is a league setting and points to league_info, which is a prerequisite rather than usage guidance.

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

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

No annotations, so the description carries the full burden and does so: mutation semantics, the complete-list contract, the max_keepers cap, the refusal condition during an active draft, and an explicit disclaimer that it only reports known timing rather than asserting a mechanism. That last note is unusually honest 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?

Front-loaded with the capitalized WRITE marker, then the critical complete-list rule. Slightly verbose with the timing caveat sentence, but every sentence adds decision-relevant 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?

Output schema exists so return values needn't be explained. For a 4-param mutation with no annotations, the description covers mutation scope, cap, refusal condition, override params, and cross-references to `keepers`. Nothing an agent needs to call it safely 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 0%, so the description must supply meaning. It documents player_names (full or partial, from your roster), confirm (must be True to send, defaults to dry run), and the two override params — clear semantics beyond the bare schema. Minor gap: no format guidance on name matching.

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?

Starts with 'WRITE. Designate which of your players you are keeping' — a specific verb and resource. Explicitly distinguishes from the sibling `keepers` tool (read side) by pointing at it for both forward and draft keeper views.

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 the decisive usage rule: the list is COMPLETE not a delta, empty list clears, and it refuses only while a draft is running. Names `keepers` as the read alternative. Doesn't spell out when to prefer dry-run vs confirm beyond the default, but the operational conditions are clear.

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

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

No annotations are provided, so the description carries the full burden. It discloses WRITE behavior, confirm=True to send versus default dry run, and in-week changes including players whose games have kicked off, with only locked players immovable.

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?

Front-loads WRITE and the purpose, then moves into argument-specific guidance. Every sentence adds useful detail without redundant repetition, and the args section is appropriately structured for a five-parameter 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 mutation tool with no annotations, 0% schema descriptions, and an output schema, the description covers prerequisites (league_info), slot-order mechanics, dry-run/confirm safety, and edge cases like in-week changes and locked players. 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 description coverage is 0%, so the description must compensate fully. It documents all five parameters: players_in_slot_order (names in slot order, use team code for defense), league_id_ and roster_id_ defaults, week (NFL week, 0=current), and confirm (True to send, False=dry run).

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 'WRITE. Set your starting lineup for a week' — a specific verb and resource. The action is unambiguous against siblings like set_keepers and set_ir, even without naming an alternative.

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 clear context: use this to set a weekly starting lineup, and call league_info to see the required slot order. It does not name when-not-to-use or alternatives, so exclusions are absent.

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

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

With no annotations, the description carries the full disclosure burden and delivers: a single-use 127.0.0.1 address with 5-minute expiry, the three browser routes, the exact data path (browser -> loopback -> process -> 0600 config file), pre-save verification against Sleeper, immediate effect without restart, and that the token never appears in a tool result. This is unusually complete behavioral context for a security-sensitive 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?

Purpose is front-loaded in the first sentence, and the security flow, routes, and argument are laid out in a tight, ordered narrative. Given the complexity and risk of this operation, every sentence earns its place with 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?

An output schema exists so return values need not be described; the description instead covers the entire setup flow, its security properties, expiry, and the one argument's side effects. Nothing an agent needs to call this 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 0%, so the description must compensate, and it does: enable_writes is explained as switching on lineups, waivers and trades, plus the critical caveat that every write tool still dry-runs unless called with confirm=True. This adds meaning well beyond the bare boolean in 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?

States a specific verb and resource: 'Start a one-time local page for adding your Sleeper token.' It is clearly distinct from the many sibling tools (e.g. auth_status) in that it is a setup/onboarding action, but it does not explicitly name or contrast itself with a sibling like auth_status, so it stops short of a 5.

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 usage direction with an alternative: 'Use this instead of ever pasting the token into the conversation.' This is clear selection guidance, but it does not state when-not to use it (e.g. when a token is already configured) or point to auth_status for checking state.

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 the ranking mechanism (within-position percentile normalization) and what a large gap means in both directions, which is genuinely useful. It does not cover permissions, cost, or whether results are cached/live, and with an output schema present the return shape is handled elsewhere.

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?

Front-loaded with the core purpose in one sentence, then mechanism, then interpretation, then args. The percentile-rank paragraph is slightly long but earns its place by preventing misreading of the gap sign. 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 5-param, zero-required tool with an output schema, the description supplies the conceptual model needed to call it correctly: what gets compared, how it's normalized, and how to read the sign. It leaves only league_id_ undocumented and doesn't clarify whether week=0 is always 'current NFL week' vs. league week, a minor 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 0%, so the description must compensate. It documents three of the five parameters with real semantic meaning — min_evidence (evidence threshold), gap (minimum percentile gap), limit (rows per direction) — each with a sensible default. It omits week semantics beyond the 0 default and ignores league_id_ entirely, hence 4 rather than 5.

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 exactly what it does: surfaces where the agent's own signal and Sleeper's projection disagree most, using within-position percentile ranks. Distinguishes itself from siblings like player_signal and usage by describing a comparative gap rather than a single source metric.

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 explains the interpretation of positive vs. negative gaps (why you'd use it) but never states when to choose this over player_signal/usage/breakouts, nor any prerequisites. Usage is inferable from the output semantics, so 3 is fair.

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 not state that this is a read-only operation, whether authentication is required, or how league scope affects results. Only the returned content is hinted at, with no operational traits.

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 zero waste. It is appropriately sized for a simple retrieval tool, though it may be too terse to fully orient the agent.

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 unannotated tool and a 0%-documented parameter, the description omits critical context: it does not explain what the optional league_id_ does or when to supply it. The output schema covers return values, but operational and parameter details are 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 input schema has one parameter (league_id_) with 0% description coverage, and the description never mentions it. The parameter name and title loosely imply a league identifier, but the description adds no syntax, format, or behavior for the parameter.

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 resource ('League standings') and adds content detail ('points for and against'), so an agent knows what data comes back. It lacks an explicit verb and does not distinguish itself from siblings like league_info, but the purpose is clear.

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 league_info or matchup. The description is a noun phrase with no context, exclusions, or prerequisites.

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 discloses that the trade block is visible to the whole league, which is useful, but it never explains the mutation path (add/remove), the purpose of the unexplained 'confirm' flag, permission requirements, or reversibility.

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 short sentences, front-loaded with the core read/set statement, and the read-mode instruction is placed last where it is useful. No notable 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?

The output schema exists so return values need not be explained, but a five-parameter tool with zero schema descriptions, no annotations, and an opaque 'confirm' parameter is left substantially under-specified by the description.

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 five parameters (add, remove, confirm, league_id_, roster_id_) have 0% schema description coverage, and the description names none of them. Aside from implicitly distinguishing the zero-argument read mode, it adds no meaning about what any parameter does or what format is expected.

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+resource: read or set which players are advertised as available, and clarifies the trade block's league-wide visibility. It is clear what the tool does, though it does not name a sibling (e.g. propose_trade, trade_targets) to differentiate against.

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?

'Call with no arguments to read it' gives one clear usage condition for the read mode, but there is no guidance on when to use this tool versus related siblings like propose_trade or trade_targets, and no 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 full burden and does well: it discloses the methodology, output categories, and important caveats about injury and early-season data. It does not cover auth needs or rate limits, but adds substantial behavioral context beyond 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 long but front-loaded and cleanly structured with headers, bullet-like explanations, and a caveat section. Every part supports correct interpretation, though it is more verbose than typical tool descriptions.

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 conceptual explanation is strong and an output schema exists so return format is covered. However, with 4 parameters at 0% schema coverage, the description should explain league_id_ and roster_id_ to be complete for a complex, multi-league 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 0%, so the description must compensate. It explains min_evidence and limit, including defaults, but completely omits league_id_ and roster_id_, leaving half the parameters undocumented anywhere.

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 finds mispriced players on rival rosters using revealed preference, and explains the BUY LOW/SELL HIGH archetypes. It does not explicitly name sibling alternatives like trade_block or waiver_targets, but the purpose is specific enough for an agent to distinguish it from generic player 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 explains when the signal is meaningful, gives early-season caution, and states that an injured benched player is not evidence of mispricing. This provides clear usage context, though it stops short of naming explicit alternative tools for related tasks.

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 not state whether this is a read-only operation, whether authentication or league permissions are required, or whether the week parameter controls pagination or filtering. It adds only content scope, not behavioral traits.

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 concise sentence with no filler. It is front-loaded and efficient, though its telegraphic noun-phrase style is less structurally helpful than a direct verb-led statement. It is appropriately sized for a short tool name but borders on under-specification.

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?

An output schema exists, so return values need not be described. However, with no annotations, 0% schema description coverage, and a crowded sibling set, the description is too thin to guide correct invocation. It omits usage context, parameter semantics for league_id_, and any read/write or permissions signal.

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 for both parameters. It adds meaning for week by saying transactions are returned for a week, but league_id_ is only implicitly referenced by the word 'League' and its default behavior is unexplained. The description does not resolve either parameter's format, default meaning, or required/optional nature.

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 the resource and scope clearly: league adds, drops, trades, and waiver bids for a given week. It implies a retrieval operation and distinguishes the tool from narrower siblings like waiver_claim or propose_trade, though it never states the verb explicitly. This is clear but not as sharp as an explicit verb+resource definition.

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 pending, waiver_targets, waiver_claim, trade_block, or propose_trade. The description only describes content categories, leaving all routing decisions to inference. No when/when-not or prerequisite information is provided.

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 does disclose a meaningful behavioral trait: this is a crowd/aggregate signal rather than an analytical projection, which tells the agent how much to trust it. But it says nothing about auth requirements, refresh cadence, or how 'all Sleeper leagues' is scoped, and the output schema covers 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 core definition is front-loaded in the first sentence and the args block is compact. The em-dash aside on crowd vs analytical signal earns its place, though the 'Args:' list is slightly redundant with the schema field titles.

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 read tool with an output schema, the description covers the enum values, the default, and the nature of the data. It is close to complete; only the league/season scope of the aggregation is left unstated.

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 0%, so the description is doing the work. Critically, it supplies the 'add'/'drop' enum values that the schema does not declare (parameters with enums: 0), and it confirms the default of 25 for limit. This is real added meaning 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?

States a specific verb+resource: players being added or dropped most, with explicit scope 'across all Sleeper leagues'. It also differentiates itself from analytical siblings (player_signal, signal_divergence) by framing itself as a crowd signal. Minor gap: it never names a sibling tool directly.

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

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

It gives a usage rationale — useful for knowing what you will have to bid against — which implies when the tool matters. However it names no alternatives and states no explicit when-not conditions, leaving the agent to infer the boundary with waiver_targets or player_signal.

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

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

With no annotations, the description carries the full burden, and it does add real behavioral context: it defines each returned metric semantically and notes that only completed weeks are shown. However it omits data freshness/lag, scope of the underlying data source, and whether results are scoped to the authenticated user's league.

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?

Purpose is front-loaded and the arg list is compact. The middle paragraph explaining the three shares is jargon-dense but earns its place by defining non-obvious metric names; it could be trimmed slightly.

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?

An output schema exists, so return values need not be described, and the metric definitions usefully interpret what that schema returns. All three parameters are documented despite 0% schema coverage. Missing only operational details like data recency and error/empty behavior.

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, and it does: player_name accepts full or partial names, weeks counts completed weeks with a default of 5, and season takes a past-year string like '2025' defaulting to the current season. Minor gaps remain (no bounds on weeks, no handling of invalid seasons), so not a full 5.

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 specifically what the tool returns: week-by-week snap share, target share, and opportunity share for one player, and clarifies the intent ('is he getting more work?'). It does not name or contrast any sibling tool (player_history, player_outlook, trending), so differentiation relies on the reader's 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?

Usage is implied rather than stated: it positions itself against scoring-focused questions ('rather than did he score?'), which hints at when to prefer it over box-score tools. There is no explicit when-to-use, when-not-to-use, or named alternative among the many 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?

With no annotations, the description carries the full burden. It usefully discloses that this is a WRITE, that confirm=False is a dry run, and that a bid is only meaningful in FAAB leagues. It omits auth/permission requirements and reversibility, and the k_adds/v_adds paragraph references fields absent from the schema, which is mildly confusing.

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?

Front-loads the WRITE marker and purpose, and the Args list is clean. However the mid-paragraph digression about parallel k_/v_ arrays describes fields the tool's schema does not expose, adding confusion without earning 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?

An output schema exists, so return values need not be explained, and the description covers the mutation nature and dry-run behavior. But for a no-annotation, 0%-schema-coverage write tool, the missing league_id_/roster_id_ docs and auth requirements leave 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 description coverage is 0%, so the description must compensate. It documents four of six parameters (add_player, drop_player, bid, confirm) with useful detail such as bid default 0 and confirm semantics, but leaves league_id_ and roster_id_ entirely undocumented.

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?

Opens with an explicit verb+resource ('WRITE. Submit a waiver claim.'), which clearly states what the tool does. It does not differentiate itself from the related siblings cancel_claim or waiver_targets, so it stops short of a 5.

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?

Provides conditional context ('Check league_info for your league's waiver type — a bid is meaningless outside FAAB') and explains the dry-run toggle, which is genuine when-to-use guidance. However it never says when to prefer this over cancel_claim or waiver_targets, leaving alternative selection 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?

With no annotations, the description carries the full burden and delivers meaningful behavioral context: it explains the exact computation, that players who can't crack the lineup price at zero, and that an empty list is a legitimate result rather than an error. It does not cover auth/permission requirements (auth_status, setup_token siblings exist), so it falls short of 5.

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 line is front-loaded with the core ranking purpose, and the Args block is tight and scannable. The intervening philosophy paragraph is slightly long but every sentence justifies the metric or its edge case.

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?

An output schema exists, so return-value explanation is unnecessary, and the params and methodology are well covered. The only real gap is the absence of any permission/auth note on a league-scoped read tool, but for this complexity level it is close to 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 0%, so the description must compensate fully — and it does, documenting all five parameters with defaults and meaning (week 0 = current week, limit=15, position enumerated QB/RB/WR/TE/K/DEF, league_id_/roster_id_ falling back to env defaults). This adds substantial meaning beyond the bare 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 action (rank free agents) and a precise, differentiating metric: `best_lineup(roster + him) - best_lineup(roster)`. It explicitly contrasts itself with projection-based and generic-replacement (VORP) tools, so an agent can distinguish it from siblings like trending or trade_targets without opening a 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?

It clearly frames when this tool is the right choice by naming what it is NOT (projection, value over replacement) and by normalizing the 'empty result' case as a valid answer. It stops short of naming specific sibling tools or explicit exclusions, but the methodological context is enough to route 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?

No annotations are provided, so the description carries the full disclosure burden. It usefully discloses the auth prerequisite ('Needs a token'), but says nothing about whether the call is read-only, whose watchlist is returned, or what happens if no token is configured — gaps an agent would want covered for an unannotated 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 short sentences, front-loaded with the resource and followed by the prerequisite — no filler. It is efficient but borders on under-specified rather than genuinely concise.

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 tool with an output schema (which already documents the return shape), the description covers the essentials: what it returns and that a token is required. The missing piece is any relation to watch_player, which would help routing.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. The 'Needs a token' note correctly implies auth is ambient rather than a call argument.

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 resource precisely — the user's Sleeper watchlist — so an agent knows this is a retrieval of already-watched players. It does not name the sibling watch_player (which presumably adds to the list), so the boundary between reading and modifying the watchlist 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?

No when-to-use guidance and no explicit alternative named. The only contextual hint is the prerequisite 'Needs a token,' which is a precondition rather than a usage rule, and it never contrasts with watch_player or the other 30+ 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?

With no annotations, the description carries the full burden; it does flag 'WRITE' to signal mutation and warns that this call returns a Player OBJECT requiring a subfield selection. It omits prerequisites such as auth/permissions, idempotency (what happens if the player is already watched), and reversibility of removal.

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?

Front-loaded with 'WRITE.' and the purpose in the first sentence, followed by a targeted gotcha. The GOTCHA paragraph is somewhat verbose and references a tool not present in the sibling list, but there is little outright 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?

An output schema exists, so return values are partially covered, and the description usefully notes the subfield-selection requirement. For a write tool with no annotations and 0% parameter coverage, however, it should say more about the player_name argument and any auth/prerequisite conditions.

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 for both parameters, but it does not. 'Add or remove' loosely maps to the unwatch boolean, yet the required player_name gives no format or resolution detail (full name vs. ID), leaving parameter meaning largely to inference.

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

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

States a specific verb (add or remove) and resource (Sleeper watchlist), so the agent immediately knows this mutates watchlist membership. It does not name the sibling that reads the list (watched_players), but the core action 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?

Usage is implied by the add/remove action and the 'WRITE' flag, but there is no explicit when-to-use or when-not-to-use guidance and no reference to the read-side sibling watched_players. The GOTCHA addresses output shape, not selection between tools.

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