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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, but the description goes further: it discloses the backing file, the sole human operator, that write_api is always false, that approve/reject is offline file editing, and that agents must never auto-clear trust flags or invent CE/EINs/donate URLs. This is meaningful behavioral context beyond the annotation set.

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 and default behavior are front-loaded, and the safety constraints come after, which is a sensible order. It is slightly dense with five clauses, but each sentence carries real operational or safety content, so it is appropriately sized for a read-only queue tool with write-adjacent risks.

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 one optional parameter, full schema coverage, and read-only annotations, the description supplies everything needed: what the queue is, whose queue it is, default and historical filtering, and the crucial fact that mutations are offline-only and must not be improvised. No output schema exists, but no return-value details are necessary for a straightforward filtered list.

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% and the schema already documents the status enum and default, so the baseline is 3. The description adds value by explaining what the 'all' enum value means ('pass status=all for history'), which is more than the bare enum list conveys, though the default status=open is repeated from the 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 ('Returns items') and resource ('Human exception-review queue'), plus the exact backing store (data/review/queue.json). It also distinguishes this read-only queue from offline approval workflows, so an agent can identify its role without opening 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?

It states the default (status=open) and explicitly says to pass status=all for history, giving concrete selection guidance. It also clarifies when NOT to use it for writes ('Approve/reject is offline file edit only ... there is no unauthenticated write/approve API'), which is exactly the kind of when/when-not routing an agent needs.

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