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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses how windows are produced ('placed by word overlap'), that the judgement is deliberately left to the caller ('The windows are placed by word overlap; the judgement is yours'), the rough window size (~2,500 chars, configurable), and the 12-cite batch limit. This is exactly the behavioral context annotations cannot carry.

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 question, then when to call, then inputs, then return shape, then scope and batch limits — a logical order with no filler sentences. It is a single dense paragraph, so the length is justified by information density but not maximally skimmable.

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 fully carries the return contract (case identity fields, two windows, overlap scores, the judgement enum) and adds the constraints an agent needs — verdict is the caller's responsibility, case opinions only, 12-cite cap. Nothing required to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning: the citation must be a reporter cite with its first page or a cluster_id, cluster_id is 'the cluster_id check_brief resolved the cite to', and a pin embedded inside the citation is also read. It restates max_chars defaults already in the schema, so it does not fully escape redundancy.

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 opening question, 'Does the cited case actually say what the brief says it says?', states the specific job in one line, and the return description (pinned_window, best_window, overlap scores, a supported/overstated/unsupported/cannot_tell instruction) makes the pin-cite-against-sentence check unmistakable. It is clearly separable from verify_quote (exact quote matching) and check_citation (citation validity), and explicitly carves out scope with 'Case opinions only (statutes and rules are out of scope).'

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

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

Explicit triggering rule: 'Call it after check_brief for every cite you rely on whose support_check says available, or for any sentence you want to test against the case it cites' — names the prerequisite tool, the field to consult, and the fallback condition. Scope exclusions are stated (statutes and rules out of scope) and the batch ceiling ('Up to 12 cites in one call with items') tells the agent when to batch.

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