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

Annotations already declare read-only, idempotent, closed-world, non-destructive behavior. The description goes further by disclosing the absence of web access, storage, payments, semantic correctness guarantees, and downstream prompt capture, plus an explicit data-handling prohibition. That is real added behavioral context beyond structured fields.

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 that front-load the core behavior before the constraint list; the negation list is slightly enumerative but each item carries a distinct safety or scope signal. Little waste overall.

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, annotated, no-output-schema tool, the scope and safety envelope are well covered, and the return semantics are implied (selected passages plus evidence-retention status). The unexplained 'task' parameter and the 40% schema coverage leave a noticeable gap an agent must fill by inference.

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 only 40%, so the description must compensate. It implies the roles of documents, tokenBudget, sanitized, and expectedEvidence (including that an empty list means completeness was not tested), but the required 'task' parameter is never explained or referenced.

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 two concrete operations against a named resource: passage selection under a token budget, and verification that declared excerpts survive selection. It is specific and non-tautological, though bundling two distinct behaviors into one description slightly blurs the primary 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?

The description sets preconditions ('explicitly supplied sanitized documents', 'user-declared exact evidence excerpts') and lists exclusions (no web access, storage, payments, semantic correctness guarantee, prompt capture), which implies the appropriate context. However, there is no explicit when-to-use statement or framing of the intended task, and no siblings exist to route against.

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