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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds useful substance about the computation itself (freshly 'computed now', reason categories such as minutes/usage/hot-cold shooting/teammate out/small sample, plus confidence and action hint), but says nothing about freshness guarantees, caching, or result 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?

Purpose is front-loaded, which is good, but the body is a single long sentence with nested parentheticals that mixes output fields, computation method, and parameter values. It is information-dense but not cleanly structured for scanning.

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

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

With no output schema, the description usefully enumerates what comes back: reasons versus preseason expectation, confidence, owner, and an action hint. Combined with the read-only annotations, an agent has enough to call it correctly, with the only real gap being the undocumented 'top' parameter.

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 carry the load. It does define the accepted 'scope' values (all | mine | others | fa), which is genuinely additive, but the 'top' parameter and its default of 15 are never explained (presumably list length), leaving half the parameters 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?

The description names a specific output artifact (buy-low / sell-high lists) and spells out the exact computation basis: season-to-date value vs rest-of-season projection in G points per game. It is clear what the tool returns, but it never differentiates itself from adjacent siblings like find_trades or rankings, 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?

There is no statement of when to reach for this tool versus find_trades, rankings, or evaluate_trade, and no prerequisites or exclusions. The 'scope: all | mine | others | fa' fragment is parameter documentation, not usage guidance, so the agent gets no routing help.

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

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

Beyond the annotations, it discloses what the mutation actually does ("updates the demo roster to match") and the deferred-verification mechanism ("the next Yahoo snapshot verifies it"). It does not discuss failure modes or the non-idempotent behavior flagged in the annotations, but the added context is genuine.

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 tight clauses with the precondition front-loaded ahead of the action and the verification note. No filler, though the parenthetical aside breaks the flow 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?

The workflow context and post-action verification are covered, and annotations carry the safety profile. For a mutating tool with two opaque, undescribed parameters and no output schema, the parameter semantics remain the missing piece.

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 both parameters (ref, note) are required with no titles beyond their names. The description never explains what ref identifies or what note should contain, so it fails to compensate for the documentation 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 verb+resource — "mark the proposal done" — and adds the real-world precondition (owner has made the move in Yahoo). This distinguishes it from the proposal-creation and step tools in the sibling list, though it never names a sibling 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?

"Only after the OWNER says they made the move in Yahoo" is an explicit, strong when-to-use condition and implies when not to use it (before the owner confirms). It does not, however, point to any alternative tool (e.g. record_owner_decision) or spell out the inverse case.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: this tool cannot change anything, and edits require owner approval plus a journal entry, which warns the agent off treating it as a config mutator.

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

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

Two sentences, no filler, with the return-shape enumeration front-loaded and the change-workflow caveat following. Every clause carries information.

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

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

For a zero-param read tool with no output schema, the description enumerates the returned fields and states the mutation path, which is enough to call it correctly. Minor gaps remain about volume or grouping, but nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so the baseline of 4 applies. The description usefully clarifies that the returned records include unit and kind taxonomies (measured/research/rule/heuristic), which shapes how the agent interprets output.

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 (engine constants) and enumerates exactly what each entry carries: value, default, unit, kind, and source. An agent can tell this is the read-only constants registry and not one of the many data/analysis siblings.

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 second sentence redirects mutation away from this tool: changing values happens in config/constants.toml under owner approval with a journaled rationale. It gives clear context for read vs. change, though it doesn't explicitly name a sibling tool to use instead.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe, self-contained read. The description adds genuine behavioral context by stating that the payload includes data freshness and Yahoo access status, which tells the agent the response may reveal staleness or auth problems. It stops short of describing size, ordering, or what happens when data is stale, so it is solid but not 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?

The imperative 'START HERE every session' is front-loaded and the rest is a tight comma-separated inventory with no filler. It is on the long side, but every listed item is a distinct payload section, so each phrase earns its place.

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

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

With no output schema, the description effectively serves as the return-value specification, and it does so by itemizing the payload sections an agent should expect. Combined with annotations covering the safety profile and a zero-argument schema, nothing critical is missing, though flagging which sections may be empty or invalidated by stale data would improve it further.

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 per the rubric the baseline is 4. There is nothing for the description to disambiguate beyond noting there are no filters or options, which the empty schema already conveys.

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 (a bundled session context pack) and enumerates its contents: league overview, strategy, playbook, journal, notes, proposals, signals, decision policy, freshness, Yahoo access status. This clearly differentiates it from the many single-topic siblings like league_overview or signals, since it is evidently the aggregate of those. The only weakness is that 'context_pack' itself is not a natural verb+resource phrase; the clarity comes entirely from the enumerated contents.

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 every session' gives an explicit, unambiguous trigger condition, which is strong guidance for an orientation tool. It does not name a when-not or point to alternatives, but for a canonical first-call aggregate that is less necessary — an agent can infer that the individual sibling tools are for follow-up detail.

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

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

Annotations already declare non-readonly and non-idempotent, so the write nature is covered. The description adds real behavioral value beyond that: the owner-approval constraint ('FBM never makes the move'), the requirement that rationale cite tool outputs, and that evidence_json carries the key numbers. It still omits what happens after drafting (notification, expiry 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-loaded with the action and key constraint, then moves into compact per-kind examples. Dense but efficient, with each clause carrying payload or policy information. Slightly terse in ways that leak into the parameter gaps above.

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, 0%-coverage mutation tool with no output schema, the description should fully explain the input contract. It covers the payload-bearing parameters well but leaves three parameters (title, summary, expires_in_hours) and two kind variants unexplained, so an agent must guess at them.

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% across 7 parameters, so the description carries the full semantic burden and does document kind, payload_json shape per kind, rationale, and evidence_json. However, it says nothing about title, summary, or expires_in_hours, and payload examples cover only add_drop, trade, and strategy, leaving waiver_claim and other 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?

States a specific verb+resource ('Draft a proposal') and adds a critical scope constraint ('FBM never makes the move') that separates it from execution siblings like send_email or evaluate_trade. An agent can tell it is a proposal-creation tool, not an action tool, without inspecting 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?

The 'kind' values imply when each proposal type applies, and 'FBM never makes the move' clarifies intent, but there is no explicit when-to-use-vs-alternative routing against siblings like proposal_steps, list_proposals, get_proposal, or record_owner_decision. Usage is implied 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?

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the safety profile is already covered. The description goes beyond that by disclosing the failure path (explains why Yahoo was unreachable and keeps ESPN ADP) and the success effect (board prefers Yahoo over ESPN) — real behavioral context not present in structured fields. It does not contradict any annotation.

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

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

Two compact sentences with the primary action front-loaded and the fallback behavior second. Every clause carries information; nothing is 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 parameterless tool with no output schema, the description covers what it does, the success effect, and the degraded path. The only gap is any mention of auth/credential prerequisites for reaching Yahoo, which is implied by 'Without Yahoo access' but never stated.

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; the baseline for a 0-param tool applies. The description correctly implies the call is parameterless.

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: fetch Yahoo ADP (draft_analysis) into the local cache, and names the downstream effect on the board's ADP preference. This is clear and non-tautological, but it never distinguishes itself from close siblings like draft_sync_yahoo or refresh_data, leaving the agent to infer which one to call.

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 when-to-use guidance, no prerequisites, and no named alternative. Given siblings such as draft_sync_yahoo and refresh_data that plausibly overlap, the description should say when this is the right call versus those, but it offers nothing.

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

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

Annotations already cover the safety profile (readOnly, closed-world), but the description adds a genuinely useful dynamic trait not captured anywhere else: drafted players are hidden while a draft is in progress. That state-dependent filtering is real behavioral context 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?

Two dense sentences with zero filler, and the core value proposition is front-loaded. The phrasing is somewhat telegraphic/cryptic ('punt-aware G-score value'), but 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?

With no output schema, the description usefully enumerates the returned fields, which is a real plus. However, for a 3-parameter tool with 0% schema coverage, the missing parameter documentation leaves a clear 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% for all three parameters, and the description does not compensate: it never explains what 'top' limits, what format 'punts' or 'position' take, or their defaults. Only a loose thematic link ('punt-aware', 'positions') exists.

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?

Names the resource (draft board) and enumerates the specific outputs it returns (G-score value, tier, positions, ESPN ADP, value vs ADP), so an agent knows exactly what data to expect. It does not, however, distinguish itself from siblings like draft_recommend or draft_mock.

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 call this versus draft_recommend, rankings, or free_agents, and no explanation of how the 'top', 'punts', or 'position' arguments should be chosen. The agent is left to infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that scoring comes from season-level simulation rather than a single simulated draft, but it does not explain the 'runs' semantics, the stochastic nature of the output, or how punts are interpreted. With annotations carrying the safety profile, a 3 is appropriate.

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

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

Two sentences, front-loaded with what the tool does. Efficient, though it could have spent those words on parameter semantics instead of the ADP/recommender parenthetical.

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?

Five parameters at zero schema coverage and no output schema means the description is the only documentation, and it documents none of the inputs. An agent cannot confidently call this tool without guessing at punts format and the meaning of runs.

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 description explains none of the 5 parameters. Key ambiguities are left unresolved: what format punts takes (empty default suggests a string list, but this is never stated), what runs controls (number of mock drafts simulated?), or what units teams/rounds/my_slot use. For a zero-coverage schema this is a serious 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?

The description states a specific verb and resource: it runs mock drafts scored by season-level simulation, returning expected categories won and rank. It explains who drafts what (others by ADP, me by the recommender). It doesn't explicitly distinguish itself from siblings like draft_recommend or draft_board, though the mock/compare framing implies the distinction.

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 says to use it 'to compare draft slots or punt builds,' which implies usage context but names no alternatives and gives no explicit when-not guidance. Siblings such as draft_recommend and punt_scenarios are never referenced.

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

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

Annotations already disclose the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds useful context beyond them: it returns updated advice and must be called sequentially for every pick, implying stateful accumulation. It still doesn't describe what the 'advice' contains or failure 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?

Two tightly packed sentences with the primary action front-loaded and no filler. Every clause carries meaning: what it does, when to call it, and what it returns.

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 single-param mutation tool whose annotations already cover the write/non-idempotent safety profile, the description covers the action and return. However, the undocumented parameter format and the absence of any note on draft-state prerequisites leave real gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single 'player' parameter. The description implies the argument is the player being picked, but never states the expected format (name vs. ID) or how the pick maps to the parameter, leaving the agent to infer invocation syntax.

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 (record) and resource (the pick for the team on the clock), which clearly separates it from siblings like draft_undo, draft_start, and draft_recommend. It does not name those siblings explicitly, so it falls 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 parenthetical '(call for every pick, in order)' gives implied usage in a live draft sequence, but there is no explicit when-to-use vs. alternative guidance, no prerequisites (e.g. draft must be started), and no exclusions. Adequate but leaves routing to the agent.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context by enumerating what the advice contains (build-aware score, ADP availability, position needs, category profile), which substitutes for a missing output schema, but it says nothing about cost, latency, or how scores are computed.

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

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

A single front-loaded sentence beginning with the key qualifier 'Live draft advice', followed by an efficient comma-delimited inventory of what it returns. No filler, though the list runs slightly long without punctuation hierarchy.

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

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

For a tool with no output schema, the enumeration of returned components is genuinely helpful, but the only input parameter is left unexplained and there is no indication of prerequisites such as an active draft or synced league data.

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 single parameter 'top' has 0% schema description coverage and a bare default of 8, and the description never mentions it or says how many picks are returned. With one undocumented param the description should have compensated, and it 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-less but concrete purpose: live draft advice, enumerated as best picks by build-aware score, ADP availability, position needs, next-pick projections, and category profile. This distinguishes it from siblings like draft_board (static board data) and draft_pick (recording a pick), though it never names those alternatives.

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

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

The phrase 'Live draft advice' implies usage during an active draft, but there is no explicit when-to-use statement and no comparison to draft_board, draft_mock, or draft_start. The agent must infer that this is the recommendation call rather than a data-fetch call.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the agent knows this is a non-idempotent write. The description adds that it 'Returns first advice,' a useful output behavior, but does not explain what restarting does to existing draft state or any auth requirements.

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

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

A single front-loaded sentence with no wasted words; the configuration and return hint are packed efficiently. Slightly terse given the parameter ambiguity.

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 non-idempotent mutation tool with 0% schema coverage and no output schema, the description covers the essentials but omits what restart does to prior state and the punts format, leaving gaps an agent would have to guess at.

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 carry the param burden; it does map the four fields (league size, my slot, rounds, punts) to the schema. However, it gives no format detail for the free-text 'punts' string, leaving its syntax unclear.

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/restart a live draft) and enumerates the configuration it takes. It is distinguishable from siblings like draft_pick or draft_board, though it never names those alternatives.

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

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

The parenthetical '(or restart)' implies the tool can reinitialize an existing draft, giving some usage context, but there is no explicit when-to-use vs. when-to-use-an-alternative guidance and no 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?

The description asserts 'Idempotent,' while the annotations declare idempotentHint=false – a direct contradiction about a behaviorally significant property (whether repeat calls are safe). 'Read-only toward Yahoo' is defensible against readOnlyHint=false only because the tool writes local draft state, but the idempotency claim is a straight conflict with structured data.

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 tight sentences that front-load the core action, then the return contract, then the failure mode. No filler, though the trailing clause about pending Yahoo access could be folded more economically.

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

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

With no output schema, the description carries the return-value burden and does it well: new picks, on-the-clock status, and recommendations. It also discloses the pending-API failure mode. The undocumented 'top' parameter and the unaddressed idempotency conflict keep it from being fully 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?

There is one parameter, 'top', with 0% schema description coverage and no default explanation beyond '8'. The description never mentions it, though 'recommendations when it's my turn' hints obliquely at what the parameter governs. With a documented parameter and no compensating text, this falls below the 3 baseline.

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

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

The description uses a specific verb+resource: 'Read the league's Yahoo draft results and record every new pick ... into the live draft state.' That dual read-source/write-target scope is clear. It separates itself implicitly from siblings like draft_pick and draft_start, though it never names them explicitly, which keeps it just 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?

It gives one piece of situational context – 'errors clearly while Yahoo API access is pending' – which tells the agent when the tool will fail. But it never states when to call this versus draft_pick, draft_start, or draft_recommend, so the routing decision is left 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?

Annotations correctly mark this as a non-read-only, non-idempotent, non-destructive mutation, and the description doesn't contradict that. It adds one genuinely useful behavioral constraint beyond the annotations: only the LAST pick can be undone, not an arbitrary one. However, it says nothing about irreversibility, confirmation, or what happens when there is no pick to undo.

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

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

A single tight sentence with the action and target front-loaded and no filler. It is arguably too terse for a mutation tool, but that shortfall is better accounted for under completeness than conciseness.

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

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

For a zero-parameter mutation with no output schema, the description covers the bare minimum: what it changes and which record it targets. It omits meaningful edge-condition context an agent would want, such as required draft state, behavior when no pick exists, and whether the undo is reversible.

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 per the baseline this scores 4. There are no arguments for the description to explain, and it correctly implies the target is implicit (the most recent pick).

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 ('Undo') and a precise resource ('the last recorded draft pick'), which is enough to distinguish it from the pick-adding siblings like draft_pick or draft_board. It doesn't name an explicit sibling or clarify boundary cases (e.g., whether it works during mock vs live drafts), so it falls 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 no explicit when-to-use or when-not-to-use guidance, no prerequisites (e.g., an active draft must exist), and no mention of alternatives if the intent is something other than reversing the most recent pick. Usage can only be inferred from the verb.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds useful output context (category deltas and before/after matchup odds), but says nothing about whether lineup/roster state must be current, whether it mutates anything implicitly, or what inputs are required.

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

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

A single dense sentence with the core action front-loaded and the parenthetical scoping the drop case economically. Nothing is wasted, though the nested clauses make it slightly harder to parse than a two-sentence split would.

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

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

With no output schema and 0% schema description coverage, the description does the right thing by summarizing the return values. However, for a 3-parameter tool it leaves the required/optional distinction and input format entirely unstated, which is a meaningful gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden. It does convey the semantics of all three parameters – 'add' a free agent, 'drop' one of mine, and the matchup context for 'opponent' – but supplies no format detail (player names vs. IDs, whether opponent is required or optional) to compensate for the empty 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 names a specific verb (quantify) and resource (adding a free agent while dropping one of mine) and states the computed outputs: rest-of-season G deltas by category plus matchup odds before/after. It does not, however, distinguish itself from siblings like evaluate_trade, waiver_decision, or find_trades, which an agent must disambiguate on its own.

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 wording – it is clearly a pre-move add/drop analysis tool – but there is no explicit when-to-use guidance, no exclusions, and no routing to the obvious alternatives (waiver_decision, evaluate_trade, free_agents). The agent must infer the situation from the name and description alone.

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

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

Annotations already declare readOnlyHint=true and readOnly safe semantics, and the description does enumerate the analysis outputs (deltas, forced drops, verdict), adding context beyond annotations. However, it doesn't state assumptions (roster state, league settings) or how names are resolved, and the parenthetical 'season-level' only lightly qualifies scope.

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 output list, but the run-on structure combining a long output inventory with a terse input note is dense and the input guidance is buried at the end.

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?

No output schema and zero param documentation means the description must carry the input contracts; it covers give/get format but omits partner semantics and doesn't clarify how the per-week/verdict outputs are produced or what inputs they rely on.

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% – none of the three required params (partner, give, get) are described in the schema. The description only says give/get are 'comma-separated names' and leaves 'partner' undefined entirely (is it a manager name? team id?), a substantial gap given zero schema help.

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?

Clearly states it evaluates a trade for both sides at season level, listing the concrete outputs (category per-week expectations, win-rate deltas, G deltas, forced drops/FA fills, verdict). Distinguishable from find_trades (discovery) and evaluate_add_drop (single-player), though it doesn't explicitly name those siblings.

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?

Implied use is when assessing a proposed trade, and the 'give/get' instruction hints at input format, but there is no explicit when-to-use vs find_trades or proposal_steps, and no stated preconditions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that it returns evaluated candidates with payload ids ready for a proposal, which is useful, but it does not describe search cost, result ordering, or other 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 two tight sentences with no filler. The search scope and purpose are front-loaded, and the return behavior is stated immediately afterward.

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 output schema and four undocumented parameters, the description is only partially complete. It explains the purpose and the general return (evaluated candidates with payload ids), but it omits details about the search constraints and the meaning of max_get, max_give, and limit.

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 four parameters, so the description carries the full burden of explaining parameter meaning. It only hints at the partner parameter ("or one partner") and says nothing about limit, max_get, or max_give, leaving three parameters 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?

The description states a specific verb and resource: searching the league or one partner for trades. It also explains the goal (improving expected categories and being defensible for the other team) and what is returned. However, it does not explicitly differentiate itself from siblings like evaluate_trade or create_proposal, so it falls 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 gives clear context for when to use the tool: to search the league or one partner for mutually beneficial trade candidates. It does not provide explicit when-not-to-use guidance or name alternatives such as evaluate_trade, but the intended usage 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?

Annotations already supply readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds nothing behavioral beyond that — no permissions, ranking methodology, or result limits beyond the 'top' parameter. The sort formulas are parameter semantics, not 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?

Two tight sentences with the core purpose front-loaded and no filler. Efficient, though extremely terse given the undocumented parameters.

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

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

With 0% schema coverage, no output schema, and four parameters, the description should do more. It omits 'punts' (presumably a punt strategy) and 'position' filtering entirely, so an agent cannot infer how to constrain the result set.

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 carry the full load for four parameters. It explains the 'sort' values well but says nothing about 'top', 'punts', or 'position', leaving three parameters undocumented in both schema and prose.

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 scope: 'Best unrostered players', which clearly identifies the free-agent ranking operation. It does not explicitly differentiate itself from siblings like waiver_decision or streaming_plan, so it falls 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?

Explains when each sort mode applies ('value' = rest of season, 'week' = streaming), which is genuine usage guidance for the sort parameter. However, it gives no guidance on when to reach for this tool versus waiver_decision or streaming_plan, leaving alt-tool selection implicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context—that the result includes the proposal's full event history—which is the only signal about return content since there is no output schema. It does not mention auth, pagination, or error 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?

A single front-loaded sentence with zero filler. It is efficiently worded, though given the total absence of parameter and usage information, the extreme brevity reflects under-specification more than optimal sizing.

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 tool with no output schema and an undocumented required parameter, the description leaves key gaps: what 'ref' must contain, how it relates to identifiers elsewhere, and when to prefer it over list_proposals. Only the event-history return detail is a meaningful addition.

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?

There is one required parameter, 'ref', with 0% schema description coverage, and the description says nothing about it. It never clarifies whether 'ref' is a proposal ID, a reference string, or a composite key, leaving the agent to guess the format—the one place the description was most needed.

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 ('get_proposal') and adds scope: a single proposal plus its full event history. The word 'One' implicitly distinguishes it from the sibling list_proposals, but it never names that sibling or explicitly contrasts the two.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. Despite an obvious sibling (list_proposals) for enumerating proposals, the description gives no cue for choosing between the single-fetch and list variants.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds useful behavioral detail: the metric is realized production in team-week SD units, and grades can be 'too early' when lookback is insufficient. It does not discuss permissions, caching, or output format.

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

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

One dense sentence with no filler. Slightly compressed — the grading scale and metric could be split for readability — but front-loaded with the core action.

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?

Covers what is graded and how, but with no output schema and no parameter documentation, an agent lacks the return structure and the meaning of lookback_days. Adequate minimum, with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the single lookback_days parameter (default 28) is undocumented anywhere. The description mentions 'since execution' and a 'too early' outcome but never explains that lookback_days controls the window, or its units.

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 (grade) and resource (executed add/drop, waiver, and trade proposals), and explains the grading method (acquired minus given up in team-week SD units per category). Distinguishes itself from siblings like evaluate_add_drop and evaluate_trade by grading past execution retrospectively rather than advising future moves.

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 retrospective framing ('executed', 'since execution') implies when this applies — after a move has happened — versus evaluate_* siblings which advise before. But no explicit when/when-not or alternative 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?

Annotations already state readOnlyHint=true and openWorldHint=false, so the safety profile is clear. The description adds useful behavioral context beyond the annotations by listing what is checked and by specifying that each check returns OK/WARN/FAIL with a fix.

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 purpose and then gives a compact list of checks and the result format. Every clause contributes information without 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?

With no input parameters, no output schema, and annotations covering the safety profile, the description supplies enough context: what is checked and what the output statuses mean. It could say more about remediation or interpretation, but it is largely complete for a health check.

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 no parameter semantics burden on the description. The baseline for a no-parameter tool is 4.

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

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

The description names a specific diagnostic resource ('System health heartbeat') and enumerates the checks it performs, from ESPN freshness to notification failures. It is clear what the tool does, though it does not explicitly distinguish itself from siblings like refresh_data or journal_append.

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 name and the phrase 'System health heartbeat', so an agent can infer it is for system diagnostics/monitoring. However, there is no explicit when-to-use guidance, no exclusions, and no comparison to alternative tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a bounded, safe read. The description adds the useful 48h recency window, but says nothing about caching, refresh behavior, or return format, so it adds only modest context beyond the annotations.

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

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

Two tight sentences: content and recency front-loaded, then the scope enumeration. Zero waste.

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

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

For a read-only single-parameter tool with no output schema, the description covers what is returned and the key scoping dimension. It is nearly complete, lacking only a note on the default scope or data freshness.

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 defines no enum, yet the description enumerates the three valid scope values and their meaning, directly compensating for the schema gap. It does not restate the default, which is minor.

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

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

States a specific resource (ESPN injury report) and a precise temporal scope (status changes in the last 48h), which distinguishes it from generic siblings like news or player_card. It does not explicitly name a sibling it differs from, 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?

The scope options (my_roster | league | all) imply how to broaden or narrow the query, but there is no explicit when-to-use guidance or routing against alternatives such as news or player_card. Usage is inferred 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?

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the mutation profile is covered structurally. The description adds only the "today's" scoping; it says nothing about whether entries can be edited/deleted, ordering guarantees, or any auth requirement, so it barely adds value beyond annotations.

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

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

Two compact sentences, front-loaded with the core action and the journal path, then the kind vocabulary. Every clause 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?

For a three-required-parameter mutation tool with no output schema and 0% schema description coverage, the description covers the destination and the kind vocabulary but omits any guidance on title/body content and on what the append returns or how conflicts are handled. Just adequate, not 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 coverage is 0% and there are no enums defined in the schema, so the description's inline list of kind values (decision|observation|recommendation|proposal|review|retro|owner|system) is genuinely valuable and would otherwise be inaccessible. It does not, however, explain the role or expected content of the required title and body parameters, leaving partial compensation only.

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 (Append) and resource (today's decision journal, memory/journal), which is clear and actionable. It does not differentiate from siblings like record_review or record_owner_decision, so the agent has to infer the boundary, but the core purpose is unambiguous.

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

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

The phrase "today's decision journal" implies the temporal scope and the kind enumeration implies what sort of entries belong here, so usage is implied. However there is no explicit when-to-use vs when-not guidance, nor any comparison to the sibling recording tools (record_review, record_owner_decision).

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety and determinism profile is covered. The description adds the ranking methodology (activity group, then complementary category fit), which is genuine extra context, but says nothing about return shape, size, or cost.

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

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

One sentence, purpose front-loaded, detail relegated to a parenthetical. No filler. It could be tighter only by explicitly tying the trailing clause to the parameter.

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

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

The description conveys what data comes back but omits how 'top' shapes the response and gives no sense of output structure for a tool with no output schema. Adequate for a simple read-only aggregate, but there is a clear gap around the one input.

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 single 'top' parameter has a default of 5 and 0% schema description coverage, yet the description never mentions it or explains whether it caps each list, the manager count, or the whole result. With one undocumented param, the description should have compensated and 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?

The description concretely enumerates the outputs — managers ranked by activity, waiver-wire leaders, best trade partners with the ranking logic (activity group, then complementary category fit). That is far more specific than a tautology. It doesn't, however, distinguish itself from close siblings like manager_profile or league_profile, so it falls 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 no statement of when to reach for league_intel versus manager_profile, league_overview, or find_trades. The agent must infer the use case purely from the listed outputs.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds two genuinely useful behavioral facts not in the annotations: the fantasy week is in ET, and a 'freshness' indicator is returned. It does not describe pagination, caching, or response shape, which keeps it at a middling score.

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

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

A single telegraphic fragment with zero waste and the primary resource ('League') front-loaded. The list style is compact but gives weak sentence structure and no hierarchy among the returned items.

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

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

There is no output schema, so the description partially compensates by enumerating returned contents (teams, categories, roster slots, week, strategy, proposals, freshness). However, with no parameters and a crowded sibling set, it omits any routing context, leaving the agent unclear on when this is the right call over league_profile or context_pack.

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; the baseline of 4 applies.

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

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

The description is a bare noun list ('League, teams, categories, roster slots, current fantasy week...') that implies an overview dump but never states a verb or the resource's purpose explicitly. An agent can infer it returns league context, but it cannot distinguish this from siblings like league_profile or context_pack without further inspection.

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 exclusions, and no reference to the numerous overlapping siblings (league_profile, context_pack, standings, my_roster). The agent is left to guess which overview tool to call.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. Beyond that the description adds no behavioral context: it does not say whether the result is simulated/cached, what time basis 'typical-week' uses, or whether the computation is expensive.

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

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

A single parenthetical sentence that front-loads the return value and then the use case. No filler, though the parenthetical slightly buries the strategic framing that would help routing.

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

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

With no output schema and no annotation detail beyond safety, the description carries the burden of conveying what comes back. It states the output concept well but leaves the sole parameter and any behavioral traits (cost, caching, freshness) unexplained.

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?

There is one parameter, n, with default 4000 and 0% schema description coverage. The description never mentions n or explains that it likely controls simulation sample size, so it fails to compensate for the schema 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?

The description names a concrete output — every team's typical-week win rate per category versus the league — which is a specific computed resource rather than a tautology. It is distinguishable from generic siblings like league_overview or standings, though it never explicitly says how it differs from them.

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 gestures at usage by framing the output as the 'basis for punt/target strategy and trade partner fit,' which implicitly points toward punt_scenarios and evaluate_trade/find_trades. However, it never states when to call this tool instead of those siblings, nor any prerequisite or ordering.

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

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

Annotations mark this as non-read-only and non-idempotent, and the description adds real behavioral context beyond them: it journals the recommendation (a side effect) and that confirm=true updates the demo roster. It discloses what gets written but not auth requirements or repeat-call 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?

Compact and front-loaded with the core purpose, but the single dense sentence is overloaded with nested parentheticals and unexplained jargon, making it hard to parse on first read.

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 multi-step lineup mutation tool with no output schema, the description covers the ordering logic, the journaling side effect, and the confirm gate. It is largely complete, with the only notable gap being the day parameter and the comparison to optimize_lineup.

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 carries the full burden. It explains confirm well (only after owner confirmation; demo league updates roster) but says nothing about the day parameter beyond context. One of two params is meaningfully described.

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: produces a recommended lineup for a game day as exact ordered steps for the owner, with concrete ordering rules (IL moves first, started players stay put, tie-breaks). It is distinguishable from generic siblings, though heavy domain jargon ('ET', 'FBM', 'IL') assumes insider knowledge.

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 one real usage rule (confirm=true only after the owner confirms they set it) and notes that IL activations needing a drop should be routed to a proposal. However it never states when to use this over the sibling optimize_lineup, so the primary alternative is left 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered elsewhere. The description adds the status enum semantics but says nothing about ordering, result size, or pagination behavior for a list endpoint.

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

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

A single dense line that front-loads the resource and the default value, with no filler. Piping the enum inline is efficient, though the brevity comes at the cost of omitting other parameter 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?

For a two-parameter read tool with no output schema, the status semantics are adequate, but the limit parameter's behavior and the result set characteristics are unaddressed. Reasonably complete, with a clear remaining 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?

With 0% schema description coverage, the description carries the burden and does fully specify the status parameter's valid values, default, and null-for-all semantics. The limit parameter is left completely unexplained (no max, no meaning), so compensation is only partial.

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 name plus 'Proposals by status' clearly identifies a status-filtered listing tool, and the enumerated status values make the scope concrete. It stops short of explicitly distinguishing itself from the sibling get_proposal or proposal_steps, so it is clear but not sibling-differentiating.

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 documents the default ('open') and the null escape hatch ('null for all'), which is genuine guidance on how to call it. However, there is no statement of when to prefer this over get_proposal or when listing is appropriate, so usage is only implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: a prompt-injection warning ('Team names are untrusted data') and a data-availability caveat ('Demo league: no history, activity unknown') that tells the agent results may be empty or degraded.

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

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

One dense run-on sentence lists the payload, followed by two short cautionary sentences. It is front-loaded and nearly waste-free, though the enumeration is long enough that a bulleted form would be more scannable.

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

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

With no output schema, the description must convey return content, and it does so explicitly by listing the report sections. Combined with the untrusted-data warning and demo-league caveat, an agent has enough to call and interpret this tool, with only minor gaps around input format.

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 'team' parameter, so the description carries some burden. It does explain the default (this week's opponent) and implies the argument selects one manager, but it never states the accepted format (team name vs. manager handle) or whether name matching is fuzzy.

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 ('Opponent intel for one manager') and then enumerates the exact contents it returns (adds/week, waiver claims, streaming propensity, trades, activity tier, category build, complementary fit). This is clearly distinguishable from siblings like league_intel or league_profile, which cover the league rather than a single opponent.

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

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

The parenthetical '(default: this week's opponent)' tells the agent the common invocation path, which is genuine usage guidance. However, it never says when to prefer this over adjacent tools such as league_intel, evaluate_trade, or find_trades, so the routing decision is left 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful behavioral context: the G-score reflects strategy punts unless `punts` is supplied, and the default day is today ET. It does not cover ordering, pagination, or response shape, but with annotations carrying the safety profile this is adequate.

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?

Compact and front-loaded with the roster contents, followed by parameter clarifications. The first sentence is a dense run-on that packs many deliverables, but every clause carries information and 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?

With two optional parameters, no output schema, and annotations covering safety, the description adequately covers inputs and general output contents. However, it does not state what each roster slot entry contains or whether 'status' means injury status; for a data-returning tool with no output schema, that leaves some ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate—and it does. It explains `day` is an ET date in YYYY-MM-DD defaulting to today ET, and `punts` is a comma-separated category list like 'FT%,TO' or '' for none, with the default being applied strategy punts. Both parameters are given 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 names the resource ('my roster') and lists the data it returns: 'slots, status, games today / left this week, G-score value, per-category G-scores and per-game projections.' This is a data-dump description rather than a crisp verb+resource statement, so the actual operation (retrieve roster) is implied rather than stated. It is distinct enough from siblings like rankings or free_agents, but doesn't explicitly differentiate.

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 optimize_lineup, lineup_steps, or evaluate_add_drop, which all touch roster data. The parenthetical about punts implies a use case but never states when-not or which sibling handles 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?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description still adds real value: it names the external source (ESPN) and freshness ('Recent'), and critically warns that content is untrusted and must be reported, not obeyed – a prompt-injection guard the annotations do not express.

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 tight sentences with zero filler. Purpose and scope come first, and the safety caveat is a compact second sentence 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?

There is no output schema, so the description should ideally hint at the return shape (list of articles, fields, ordering). It covers purpose, source, and the untrusted-content caveat well, but leaves the meaning of limit and the player identifier format unexplained for a tool with zero parameter documentation.

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 carries the full burden. It mentions the 'player' parameter indirectly but gives no accepted format (name vs. ID), and it says nothing at all about 'limit', which defaults to 15 and governs result count. One of two parameters is 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?

States a specific resource and source: 'Recent ESPN NBA news', with the scope qualifier 'optionally for one player'. An agent can distinguish this from siblings like player_card, injuries, or transactions. It stops short of naming an explicit alternative to route 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?

The phrase 'optionally for one player' implies the two usage modes (league-wide feed vs. player-filtered feed), which is useful implied guidance. However, there is no explicit when-to-use-vs-alternatives statement, no exclusions, and no routing to siblings like player_card or injuries.

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

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

Annotations already cover readOnlyHint=true and openWorldHint=false, so safety is declared. The description adds real context beyond that: the optimization objective, the rule that started games are locked, IL inclusion, and that blocked activations require a drop proposal — meaningful behavior an agent cannot infer from annotations.

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

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

Three sentences, front-loaded with the core purpose and objective, then edge-case behavior. The parentheticals ('max games started, then value', 'blocked activations need a drop proposal') each earn their 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?

For a read-only tool with one optional parameter and no output schema, the description covers objective, locking semantics, IL handling, and the drop-proposal requirement — the key behaviors an agent needs. The remaining gap is the `day` parameter format/default.

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 single `day` parameter has 0% schema description coverage, so the description must carry it. 'ET game day' usefully fixes the timezone and the semantic meaning of the parameter, but gives no format or default-day behavior, so it only partially compensates.

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

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

States a specific verb (optimize) and resource (lineup) and even the objective function — 'max games started, then value'. It is clearly distinguishable from generic tools, though it never names a sibling (e.g. lineup_steps or my_roster) that an agent might confuse it 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?

'Read-only preview' tells the agent this does not apply changes, which is a usage signal, and the note that blocked activations need a drop proposal hints at the write path. But there is no explicit when-to-use/when-not or named alternative, so usage is only implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds real behavioral context beyond them: each incoming offer is evaluated from the user's side with a verdict and category deltas, writes are out of scope, and the demo league returns a message rather than data. That is meaningful disclosure for a read 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?

Three short sentences, front-loaded with the resource before the behavioral detail. The trailing 'Demo league: a message.' is slightly cryptic but adds a concrete behavioral note 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?

With no parameters and no output schema, the description carries the return-value burden and does so adequately by naming verdict and expected-category deltas. Combined with the scope note, an agent has enough to call and interpret the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, which per the rubric sets the baseline at 4. Schema coverage is 100% and there is nothing for the description to clarify.

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 (pending trades and waiver claims) and implies a list/retrieve verb, plus it clarifies the evaluation angle (verdict, expected-category deltas). It does not explicitly differentiate from siblings like list_proposals, get_proposal, or evaluate_trade, 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 implies usage context (viewing your own pending offers) and usefully constrains scope by noting accept/reject are manual in the Yahoo app and writes are out of scope. However, it never names an alternative or states when to prefer another tool over this one, so routing is left 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?

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds genuine context about what the payload contains (projection basis, blend weight, early signals), which is real value, but it says nothing about cost, data freshness, or behavior when the query is ambiguous.

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 long inventory sentence with many parenthetical asides. Every listed item is real content, so little is wasted, but the dense bracketed enumerations make it harder to scan than a front-loaded summary plus a short 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?

With no output schema and one undocumented parameter, the description does the work of describing return contents, which is appropriate. However, a tool returning this much aggregated data across many categories should at least note the identifier resolution behavior and freshness expectations; those gaps keep it at minimally adequate.

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?

There is one parameter, 'query', with 0% schema description coverage. The parenthetical '(name or ESPN id)' is the only disambiguation and it is useful, but it does not say how fuzzy matching works or what happens on multiple matches. With zero schema coverage the description carries the load and only partially discharges it.

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 resource (one player) and enumerates the exact data it returns: projection and its basis, ESPN preseason vs latest projection, signals, G/Z by category, rank, owner, injury, games left, last-10 averages, news. That is a precise scope. It does not explicitly distinguish itself from siblings like rankings or my_roster, 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 no when-to-use or when-not-to-use guidance and no mention of alternatives. An agent is left to infer that this single-player deep-dive replaces fanning out across rankings, my_roster, injuries, and news, rather than being told so.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered by structured data. The description adds useful output context (including the current trade playoff weight) beyond the annotations. It doesn't discuss limits, ordering, or how 'top' caps results.

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 payoff, telegraphic and dense with no filler. The scope line and trade-weight note are compact add-ons. Slightly staccato but efficient.

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

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

With no output schema, the description does the right thing by summarizing the returned data (playoff weeks, team games, player value, trade weight). It omits what 'top' controls and any sense of result size or ordering, leaving a gap for a parametrized read 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 coverage is 0%, so the description must carry parameter meaning. It helpfully enumerates the valid scope values (my_roster, free_agents, league), which the schema does not. But the 'top' parameter (default 25) is never explained, leaving half the parameters 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?

The description names a specific resource and enumerates its contents precisely: playoff weeks, NBA team games per playoff week (best/worst), players' playoff games and value, plus the trade playoff weight. An agent can tell it retrieves a fantasy-playoff projection view rather than raw schedules. It stops short of explicitly differentiating itself from siblings like schedule or my_roster.

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?

Listing 'scope: my_roster | free_agents | league' implies the tool is used across those vantage points, giving implicit usage context. However, there is no explicit when-to-use, when-not-to-use, or named alternative (e.g., vs schedule or my_roster) to route the agent.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value by naming the computed metrics, but says nothing about data availability, timeframe, or whether predictions must already exist.

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

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

A single dense sentence that front-loads the action and then lists outputs. Every clause carries information, though the metric list is somewhat compressed.

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

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

With no parameters, no output schema, and annotations covering the read-only nature, the description's enumeration of report contents is close to sufficient. It only lacks a note on when the required prediction data 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 the baseline is 4 and the schema has nothing to document. The description correctly implies no input is required.

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 pairs specific verbs (grade, report) with a concrete resource (finished matchup predictions and simulator calibration) and enumerates the exact metrics produced (Brier score, reliability buckets, per-category Brier). This clearly separates it from projection_calibration, though that sibling is never named 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?

The word 'finished' implies it should be run after matchups complete, but there is no explicit when-to-use statement, no prerequisites, and no routing to the closely related projection_calibration or grade_decisions 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?

The description explicitly states the tool 'Stores the measured weight (used by every projection)', i.e. it persists state, while the annotations declare readOnlyHint=true. That is a direct conflict between described write behavior and the read-only annotation, so the behavioral signal is actively misleading.

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

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

Two sentences, front-loaded with the primary action and outputs before the storage/override detail. The second sentence is dense but each clause (storage trigger, override precedence) carries distinct information, so little 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?

With no output schema, the description usefully names what is returned (per-stat RMSE, normalized error, best blend weight) and explains the storage trigger and config override. It is reasonably complete for a no-argument analysis tool, apart from the annotation conflict.

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 and the empty input schema leaves nothing to document, so the baseline of 4 applies. No parameter meaning is required or missing.

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 (grades logged forecasts) and enumerates concrete outputs: per-stat RMSE, normalized error for engine-only/ESPN-only/blend, and the best blend weight. The scope is unambiguous, though it never differentiates itself from near-neighbor siblings like prediction_calibration or signal_grades.

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 usage context (grade forecasts against the next 14 days of box scores; a weight is stored once enough forecast dates are graded), which hints at a prerequisite. However, it gives no explicit when-to-use or when-not-to-use guidance and never points to the alternative calibration/grade siblings.

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

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and the description usefully clarifies that despite the status transition to awaiting_owner, 'FBM makes no move' and no external action occurs. It also discloses the status model (awaiting_owner vs done). It does not address idempotency or what happens on re-validation failure, so it stops short of a 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?

Three sentences, densely front-loaded with the precondition first and the behavioral clarification second. Every sentence carries information, though the status parentheticals make it slightly technical to parse.

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

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

With no output schema, the description correctly describes the return value (the exact steps the owner performs) and states the preconditions and status transitions. The only missing piece an agent needs is the meaning/format of 'ref', which is not covered anywhere else.

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?

There is one parameter, 'ref', at 0% schema description coverage, and the description never explains what it is (a proposal identifier), what format it takes, or where to obtain it. The text implies a proposal is selected but adds no meaning beyond what the bare schema property name conveys, which is a real gap for the only input.

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: re-validate an owner-approved, unexpired proposal against the current league and return the exact Yahoo steps the owner performs. It also distinguishes behavior by proposal type (strategy proposals are recorded directly, status done), which helps separate it from get_proposal/list_proposals. It stops short of naming a sibling explicitly, so it is clear but not sibling-differentiating to the top tier.

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 context is clear and conditional: this applies only to owner-APPROVED, unexpired proposals, and strategy proposals are handled differently (recorded directly rather than producing steps). That functions as both a precondition and an implicit exclusion, though no alternative tool is named for the other cases.

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

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

The annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully adds the simulation's internal behavior (builds propose FA swaps in valuation order, only helpful swaps are kept) and enumerates returned fields, which matters since there is no 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-loaded with the core purpose and packed with signal, but the middle sentence is a dense run-on that chains process, return values, and side outputs together. It is efficiently sized overall 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?

For a complex read-only simulation with no output schema and no annotation detail about results, the description adequately covers process, outputs, and timing. The only real gap is that two of the three input parameters are left unexplained.

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 carry the parameter burden. It decodes the 'scenarios' format explicitly ('FT%;3PM,FT%'), which is genuinely helpful, but 'top' and 'fa_moves' are never explained, leaving two of three parameters 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?

States a specific verb and resource ('Compare punt builds') and scopes it tightly ('for MY roster'), with enough detail about the simulation pipeline that the agent knows exactly what analysis is produced. It does not explicitly name a sibling to contrast against, so it lands just 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?

'Run before any strategy proposal' gives an explicit sequencing rule, and the scenarios note implies context for testing specific builds. However, it never states when NOT to use it or which sibling (e.g. evaluate_add_drop, simulate_matchup) to prefer for adjacent questions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds what the ranking is based on (G-score, non-punted categories), but says nothing about scope limits, pagination, or how the ranking behaves with the available_only/punts inputs.

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 tight clauses with no filler, and the core purpose is front-loaded. The trailing 'position:' fragment is terse but does add the enum values, so it earns its place.

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

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

For a four-parameter tool with no output schema and zero schema description coverage, the description is too thin: it neither explains the un-documented parameters nor clarifies what the returned rankings look like or how punts interact with them.

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 carries the full burden for four parameters. It only explains the position parameter (listing the PG/SG/G/SF/PF/F/C values); top, punts, and available_only are left completely 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?

States a specific resource (player rankings) and the ranking basis (G-score over non-punted categories), which is more informative than a bare title. It is distinguishable from siblings like player_card or draft_board, though it does not explicitly name what 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?

There is no guidance on when to use this versus alternatives such as punt_scenarios, projection_calibration, or player_card, and no stated prerequisites or context. The only hint of usage is the mention of non-punted categories, which implies a punting-aware fantasy context but is 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?

Annotations already flag this as a non-read-only, non-idempotent write, and the description adds genuinely new behavioral context: a hard guardrail that the agent must not self-approve or fabricate the owner_quote. It doesn't disclose what recording actually does downstream or that non-idempotent calls may create duplicates, which keeps it from a 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?

Two tight sentences, front-loaded with the imperative and the critical constraint immediately after. No filler; every clause carries actionable 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?

The critical misuse case is well covered, which is the highest-value content for this tool, but with 0% param coverage, no output schema, and no explanation of the 'ref' target or downstream effect, an agent still cannot fully understand what it is recording against.

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 carries the full burden, yet it only clarifies one of three parameters (owner_quote as verbatim owner words). The meaning of 'ref' (what is being referenced) and 'approved' (approve/reject sign) is left entirely undefined.

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 (record the OWNER's decision), which is clear and distinct in intent from generic siblings like record_review or create_proposal. However, 'decision' remains slightly abstract — it never says it is an approval/rejection of a proposal — and it doesn't explicitly contrast with the nearby recording 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?

Gives an explicit when-to-use condition ('only call with the owner's own words from this conversation') plus strong exclusions ('never infer, assume, or self-approve'). It does not name an alternative tool for the cases it forbids, so it stops just 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?

Annotations already declare readOnly=false, idempotent=false, destructive=false. The description adds valuable context beyond that: it discloses the resulting state transition ('Moves the proposal to pending_approval') and an authorization constraint on the reviewer's model family. It does not warn that non-idempotency means repeated calls may create duplicate reviews, which is a minor gap.

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

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

Three short sentences, front-loaded with the action and verdict values, then the constraint, then the effect. Every sentence carries information; nothing is padded.

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?

Captures purpose, a prerequisite, and the downstream state change, which is solid for a mutation tool with no output schema. But with 5 parameters at 0% coverage, the definition is incomplete on inputs (ref semantics, what notes should contain, confidence's role) that an agent needs to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 5 parameters, so the description carries the full burden. It clarifies two of them—verdict (enum values) and reviewer_model (must be a different model family)—but leaves ref, notes, and confidence completely unexplained, so half the surface remains opaque.

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 (Record) and resource (the independent reviewer's verdict), and enumerates the allowed values AGREE|DISAGREE|SPLIT. This distinguishes it from sibling mutation tools like record_owner_decision and confirm_done, though it never names the alternative it differs 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?

Gives one concrete precondition—the reviewer must be a different model family from the GM—which is genuinely useful usage context. However, it offers no explicit when-to-use framing versus siblings like record_owner_decision, and no guidance on whether this is the sole path to pending_approval.

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

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

Annotations already declare readOnlyHint=false and idempotentHint=false, so the agent knows this mutates state and is not repeat-safe. The description adds real context beyond that: it discloses the side effects (logging today's forecasts, detecting signals) and the specific return payload (rostered injury changes, newly caught signals).

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

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

Two sentences, front-loaded with the action and then the return value. The parenthetical domain list is dense but each item earns its place by defining sync scope; 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?

With no output schema, the description correctly carries the return burden by naming the two things it returns. Given the mutation semantics flagged by annotations, it is complete enough for an agent to invoke it, though a note on cost/latency or repeat-run behavior would round it out.

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; the 4 baseline applies.

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

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

States a specific verb ('Run the daily ESPN sync') and enumerates the exact data domains it covers (schedule, box scores, averages, injuries, news, projections). This clearly marks it as the ingest/refresh operation rather than a read tool, though it never names a sibling 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?

'Daily' implies a once-per-day cadence, which hints at when to run it, but there is no explicit when/when-not guidance and no reference to the many sibling read tools (injuries, news, snapshot, signals) it complements.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a vague sense of scope ('this fantasy week', 'ET') but does not clarify time window behavior, whether 'days' changes the ET window, or what the response contains.

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 short, but the structure is a fragment of keywords rather than a front-loaded sentence. Every phrase gestures at content but none is clearly framed as purpose or behavior.

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 schedule tool with no output schema and an undocumented 'days' parameter, the description is not complete enough for an agent to know the time horizon or output shape. It gestures at content areas but leaves key operational details unspecified.

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% for the single 'days' parameter. The description does not explain what 'days' controls, its default of 7, or how it relates to 'this fantasy week' and 'upcoming' – leaving an important ambiguity unresolved.

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 reads like a data label rather than a statement of action: 'Upcoming ET game days: NBA games, my players with games; NBA team game counts this fantasy week.' It implies a schedule lookup but does not specify a verb or clearly distinguish what the tool returns versus siblings like scoreboard or my_roster.

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

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

There is no explicit guidance on when to use this tool versus alternatives. An agent could confuse it with scoreboard, standings, or my_roster, and the description offers no exclusion or selection criteria.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds real value on top: it enumerates the returned fields (per-category values, leader, categories won, status, as_of) and discloses a demo-league edge case that returns a message instead of data.

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

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

A single front-loaded sentence with no filler, leading with the time scope and primary resource. The parenthetical and trailing demo-league note are compact and earn their place.

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

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

With no output schema, the description must convey return content, and it does list the key fields. For a zero-parameter read tool this is nearly complete, though it omits whether results are paginated or how many matchups appear.

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 for a no-param tool is 4. The description correctly implies no input is required.

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 scope: this week's live category totals for every matchup, with the caller's team ordered first. It's clear what the tool returns, though it doesn't explicitly differentiate itself from adjacent tools like standings or league_overview.

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 only implied by the content described (you'd call it to see the current week's matchup scores). There is no explicit when-to-use, no exclusions, and no named alternative such as standings for league-wide records.

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

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

Annotations already declare this as a non-read, non-idempotent, non-destructive write. The description adds a genuine behavioral nuance ('approval/alert bypass quiet hours') and names the channel (Gmail), but says nothing about immediacy, confirmation, 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?

Two short sentences with the core action front-loaded and the kind/quiet-hours details following. No filler, though the phrasing is slightly telegraphic.

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 3-param email tool with no output schema, the description covers recipient, channel, kind taxonomy, and a delivery nuance. It is adequate but leaves open whether the send is immediate/unrecoverable and what the required subject/body constraints are.

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 carries the burden. It supplies the enum values for kind (report|approval|alert|retro), compensating for one parameter, but subject and markdown_body receive no added semantics in either the schema or the description.

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 (Email) and a clear resource/recipient (the owner, via Gmail), so the agent immediately knows what the tool does. It is the only email-capable sibling, so differentiation is implicit rather than 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 kind list (report|approval|alert|retro) gives some guidance on intent, but there is no explicit when-to-use vs when-not-to-use guidance. The tool is unique among siblings, so 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety/scope profile is covered. The description adds that it only grades windows that have 'finished' and mentions Yahoo ownership data as 'our lead,' which is useful context. But it doesn't describe return shape or cost, and with the annotations doing the heavy lifting a 3 is appropriate.

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

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

One dense but well-structured sentence with no filler; the definition of 'hit' is front-loaded in parentheses and both reported outputs are named. Slightly long but every clause carries information.

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

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

For a zero-param read-only reporting tool, the description covers what it grades and what it returns at a high level. With no output schema, it could be more explicit about the return structure (e.g., per-kind breakdown format), leaving a gap an agent would have to probe.

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?

Zero parameters, so per rubric the baseline is 4. The description correctly implies the tool takes no inputs by describing a self-contained reporting operation.

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 (grade) and resource (signals with a finished 14-day window), and describes the two outputs it reports (hit rate by kind/confidence, Yahoo ownership movement). It's distinguishable from siblings like grade_decisions or prediction_calibration, though it doesn't explicitly name the comparison.

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

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

The parenthetical '(hit = production moved as the signal said)' clarifies what 'grade' means here, and the 14-day-window condition is a usage boundary. But there's no explicit when-to-use/when-not vs grade_decisions or prediction_calibration, which an agent might confuse it with.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses that the feed is regenerated by every data sync, that refresh=True triggers a fresh detection run, and that low-confidence signals backtest no better than the naive view — a genuinely useful quality caveat. It stops short of saying what a refresh costs or whether it mutates stored state.

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 clause, then signal kinds, then output fields, then parameters — a deliberate most-to-least-important ordering. Dense but every fragment adds information; no filler sentences.

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

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

With no output schema, the description usefully enumerates the returned fields (direction, confidence, reasons, evidence, first_seen_et, is_new, owner, action hint), covering the return contract. The two undocumented parameters and the absence of explicit sibling routing are the only real gaps for a 6-parameter 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 coverage is 0%, so the description carries the load and mostly succeeds: it defines scope values (all | mine | others | fa), kind as comma-separated kinds, refresh semantics, and the min_confidence scale plus its default source. Only 'top' and 'new_only' go unexplained in either the schema or the description.

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 ('Early-signal feed') and enumerates exactly what it carries (buy_low/sell_high, role_change, opportunity, espn_revision) with the refresh cadence. An agent can tell it is a detection/signal feed rather than a raw data tool, though it never distinguishes itself from the overlapping sibling buy_sell or signal_grades.

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 through the scope values and the 'refresh=True re-runs detection' note, and the min_confidence caveat hints when low-confidence output is not worth reading. There is no explicit when-to-use-this-vs-alternative guidance, so the agent must infer the routing from the sibling list.

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

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

The description explicitly discloses a state-mutating side effect: 'record=True logs the prediction for calibration'. Persisting a prediction record modifies the environment, which directly contradicts the declared readOnlyHint=true annotation. Because the description contradicts the annotations, this is an Annotation Contradiction.

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 purpose is front-loaded in the first clause and the outputs are listed immediately, so an agent can stop reading early. Sentences are dense and param notes are tucked in backticks rather than bulleted, and the dangling '(daily-gm does this)' plus the phantom `if_opponent_streams` add mild noise, 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?

For a 5-parameter tool with no output schema and no parameter descriptions, the description compensates well by naming the returned statistics and explaining the streaming/record flags. But it leaves n and start undefined and, more importantly, contradicts the readOnly annotation regarding the record flag, so an agent cannot fully trust the behavioral picture.

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?

With 0% schema description coverage, the description must carry the parameter burden, and it does explain opponent ('team key or name'), opponent_streams ('adds optimally; 0 = skip'), and record ('logs the prediction for calibration'). However, n and start are left entirely unexplained, and the description references an `if_opponent_streams` parameter that does not exist in the schema, which risks confusing invocation.

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 operation (Monte Carlo matchup simulation) against a named resource (rest-of-week matchup vs an opponent) and enumerates concrete outputs (per-category win/tie/loss odds, expected categories won, swing categories). It is clearly distinguishable from siblings like scoreboard or playoff_outlook, which do not simulate matchups. It stops short of 5 only because it never explicitly names an alternative 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?

There is no when-to-use / when-not-to-use guidance and no mention of alternatives among the roughly 50 siblings (e.g., scoreboard, playoff_outlook, optimize_lineup). The closest thing to context is the parenthetical '(daily-gm does this)', which hints at a caller but gives the agent no decision rule for choosing this tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds real behavioral context beyond them: which Yahoo domains are re-read, that league transactions are synced into manager intel history, the exact return payload (week, opponent, fetched_at, sync result, unmapped Yahoo players plus remediation), and a demo-league caveat. It does not mention cost/latency of hitting the live API or how staleness is determined, but the added disclosure is substantial.

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

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

Three sentences in a sensible order: action, then return shape, then an edge-case note. The middle sentence is dense but every clause (sync result, unmapped players, how to fix) earns its place since there is no output schema. Only the trailing 'Demo league: a message.' fragment is slightly clipped.

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

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

With no output schema, the description correctly carries the burden of describing returns and does so thoroughly, and with zero parameters there is no schema gap to fill. What is missing is operational context: relative cost/rate-limit behavior against the live Yahoo API and when to prefer this over the near-identical 'refresh_data' sibling.

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 the 4 baseline applies; there is no parameter semantics to compensate for. Schema coverage is reported at 100% for the empty object.

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 concrete action (force a fresh read of the live Yahoo league) and enumerates exactly what is fetched (rosters, scoreboard, standings, waivers, ownership) plus the transaction sync. It is clear what the tool does, but it never differentiates itself from the very similar sibling 'refresh_data' (or 'draft_sync_yahoo'), so an agent has no textual basis for choosing between them.

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

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

There is no explicit when/when-not guidance and no named alternatives, even though 'refresh_data' and 'context_pack' plausibly overlap. The word 'Force' weakly implies 'use when data is stale', but that is inference rather than stated guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only the 'my row flagged' behavior, and the dangling 'Demo league: a message.' fragment suggests a demo/fallback mode without explaining it, so it contributes little usable behavioral context.

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

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

Two fragments, the second of which ('Demo league: a message.') is truncated and unparseable, so a meaningful share of the text earns no place. The useful scoping detail is front-loaded, which is the only structural positive.

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

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

There is no output schema and no parameters, so the description must carry the full burden for a simple read tool, yet it leaves the demo-league behavior unexplained and does not say what the returned standings contain or how 'my row' is marked. For a no-schema tool this is under-specified.

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?

With zero parameters the baseline is 4, but the description invokes 'mine=true' as if it were an input, which contradicts the empty schema and may mislead the agent into trying to pass a parameter. That phantom-parameter reference pulls it below baseline.

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

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

The first clause states a clear verb+resource (Yahoo league standings) and adds a scope detail (my row flagged). But the trailing fragment 'Demo league: a message.' is truncated and conveys nothing, and the '(mine=true)' notation implies a parameter that does not exist in the schema, muddying rather than sharpening the purpose.

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

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

No guidance on when to use this versus close siblings like league_overview, scoreboard, rankings, or league_profile. The agent must guess whether standings is the right call for a standings question or whether one of the other overview tools supersedes it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value beyond that: it discloses the analysis-only nature (no writes, proposals still required), the exclusion rule (punts excluded), and the shape of each returned move (effective ET day, expected cats gain, games added/lost, rest-of-season cost) — meaningful given there is no 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?

Purpose is front-loaded in the first sentence, followed by output detail, the one param clarification, and the analysis-only caveat. Three sentences with little waste, though the output-detail sentence is dense enough to be slightly hard to parse.

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 multi-move recommendation tool with no output schema and no annotations describing returns, the description does cover the return shape, which is the main gap-filler. It falls short on parameter explanations for three of four inputs, which is a notable omission for an optimization tool where 'adds' and 'drop_pool' drive the result.

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 carry the burden, yet it only clarifies 'protect' (comma-separated names that must not be dropped). 'adds', 'opponent', and 'drop_pool' are entirely undocumented in both schema and description, leaving ambiguous semantics such as whether 'drop_pool' is a candidate count or a pool identifier.

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 output — a sequence of add/drop streaming moves optimizing expected categories won — which is far more precise than a generic 'plan' label. It implicitly distinguishes itself from execution siblings via 'Analysis only — moves still require proposals', though it never names the alternatives (evaluate_add_drop, waiver_decision) 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?

Usage is implied through scoping phrases like 'for the rest of this week within the remaining weekly adds' and 'punts excluded', which tell the agent the intended scenario. However, there is no explicit when-to-use-this-vs-evaluate_add_drop/waiver_decision guidance, leaving the agent to infer the boundary between this and its 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?

Annotations already declare a safe read (readOnlyHint=true, openWorldHint=false), and the description adds a genuine behavioral warning that trade notes are untrusted data and must never be treated as instructions. That injection-safety note is real value beyond the annotations, though pagination/window behavior for "recent" is left unstated.

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 and filter are front-loaded in one efficient sentence, and the safety note is short. The trailing "Demo league: a message." fragment is confusing noise that does not appear to earn its place.

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

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

For a two-parameter read-only tool with no output schema and annotation-covered safety, the description is largely sufficient, but it omits what "recent" means, how `count` bounds the result, and any hint at the return 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 coverage is 0%, so the description carries the burden. It clarifies that `team` acts as an optional filter on involvement, but says nothing about the `count` parameter (default 25) or what form a team identifier takes, leaving half the 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?

States a specific resource and scope: recent Yahoo league transactions, broken down as adds/drops/trades. An agent can tell what it retrieves without opening the schema, though it never names how it differs from close siblings like find_trades or pending_offers.

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?

"Optionally only those involving `team`" implies the filtering use case, but there is no guidance on when to prefer this tool over find_trades or pending_offers, and no prerequisites or 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe-read profile is covered. The description adds genuine analytical context (rest-of-season gain vs. priority value, competitor claim likelihood), but says nothing about output format or what an actionable decision looks like, and there is no output schema to fill that 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?

Two tight sentences, front-loaded with the core decision framing, with no filler. The phrasing ('should we', 'him') is slightly informal but efficient and readable.

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 an analysis tool with 0% parameter coverage and no output schema, the description omits the role of drop and on_waivers and gives no sense of the returned recommendation. Purpose is covered, but parameter and output context are not.

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% for three parameters. The description implicitly touches on_waivers via 'wait for him to clear' vs 'add (free agent)', but never explains player, drop, or the boolean semantics. With no schema descriptions, 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?

The description states a specific decision problem: whether to claim a rolling waiver now, wait for clearance, add as a free agent, or pass. This is a clear verb+resource (waiver claim decision) distinct from a generic add/drop evaluation. It does not name a sibling tool, but the framing is specific enough to distinguish it.

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 rolling-waiver framing, but there is no explicit when-to-use or when-not-to-use guidance relative to close siblings like evaluate_add_drop, free_agents, or streaming_plan. The agent must infer that this is the priority-aware waiver variant.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful content scope by listing the returned data categories, but says nothing about return format, aggregation behavior, or how missing data is handled.

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

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

A single front-loaded sentence that opens with the tool's purpose and then enumerates contents. It is dense but earns its length; only the run-on list is slightly heavy.

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 aggregate tool with no output schema, the description adequately conveys what data is bundled, so the agent needn't have return values explained. Gaps remain around the week_start format and the default's precise semantics, which matter for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 1 parameter and 0% schema description coverage, the description carries some burden and does add value by specifying the default ('last completed week'). However, it never explains the expected format of week_start (ISO date, week number, label), leaving the one parameter partially 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?

The description states a clear resource (weekly retro data bundle) and enumerates its contents (graded decisions, predictions, calibrations, signal grades), so an agent knows what comes back. It does not explicitly name the sibling tools it aggregates (grade_decisions, prediction_calibration, projection_calibration, signal_grades), so it falls short of full sibling differentiation.

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

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

The phrase 'Everything the weekly retro needs' implies the usage context (assembling a weekly retro), but there is no explicit when-to-use vs when-not guidance and no alternatives named against the individual sibling tools. Usage is only implied.

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