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

Annotations only declare it is a non-read-only, non-destructive, non-idempotent write; the description adds real behavioral context on top — the report feeds a weekly review, is not itself a verdict, requires the caller's key, and is capped at 20 per day. It stops short of saying what a duplicate report does or what the caller sees back, which the non-idempotent hint would make useful.

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 purpose first, then the downstream consequence and limits. Every clause carries information — the kind definitions, the weekly-review framing, the key requirement, and the daily cap — 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 write-style report tool with no output schema, this covers the essential decision inputs: what counts as wrong, what happens next, auth, and rate limits. What is missing is minimal — response shape after filing and whether repeat reports on the same pass are deduplicated.

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

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

Schema coverage is 100%, so baseline is 3; the description earns an extra point by giving plain-language meaning to three of the five enum values (fake_pass, copied_pass, sham_orders) that the schema itself defers to the description for. The other parameters (url, note, agent_id) are left entirely to the schema, which documents them adequately.

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 (report) and resource (a Word Pass) plus the exact condition that triggers it ('looks wrong'), and enumerates the reportable kinds. The clause 'never a verdict on its own' separates it from verification siblings like check_word_pass, verify_pass, or get_pass without needing to open a schema.

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

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

Clear context for when to file: something about a pass is wrong and should go to the weekly review rather than be adjudicated. It does not name a specific alternative tool (e.g. check_word_pass for a quick lookup, word_pass_signals for aggregate signals), so the routing is implied rather than spelled out.

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