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

Annotations already establish read-only, idempotent, closed-world behavior; the description adds meaningful non-obvious context on top — that the response carries an ADR 0007 disclaimer with mixes_units_in_ranking:false, that boards never cross-mix WELLBYs with lives_saved, and that the tool never invents cross-unit moral weights. The guarantee about board immutability ('frozen') is also useful. It stops short of describing response shape or ordering, so not 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 tight sentences with the source and scope front-loaded, then the two call modes, then the invariants. The ADR reference and unit-mixing clause are dense but carry real behavioral meaning rather than 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?

No output schema, but the description compensates by disclosing the disclaimer field and the no-cross-unit-mixing guarantee that shape the return value, and it covers both zero-arg and one-arg invocations. Only the concrete response structure (board entries, ranking fields) is left unstated, which is a modest gap for a read-only list tool.

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

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

Schema description coverage is 100% and the schema already documents both outcome and its alias outcome_preference, including accepted values and the omit-for-all behavior. The description restates the omit/pass semantics and adds that a single family's board is 'frozen ranked', which hints at ordering, but contributes little the schema doesn't already convey. Baseline 3 applies.

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

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

The description names a specific resource (per-outcome-family leaderboards sourced from data/ranking/leaderboards.json) and defines scope precisely, including the two modes (all families vs. one frozen board). It never states the verb explicitly ("list") and makes no reference to any sibling tool, so differentiation comes from the resource noun rather than an explicit contrast.

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?

"Omit outcome to list all families" and "Pass outcome= to fetch one family's frozen ranked board" give clear mode-selection guidance covering both call patterns. What's missing is any pointer to which sibling to use instead for comparison or impact questions (compare_charities, estimate_impact), so an agent gets context but no exclusions.

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