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

The annotations only cover safety/scope (readOnly, idempotent, non-destructive, closed-world); the description adds genuinely new behavior: the exact artifact produced, that it is verifiable by third parties, and that it costs $1.50 per packet, which an agent must factor into the decision. It stops short of stating failure modes for an invalid or missing receipt_id.

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?

One front-loaded sentence leads with the invocation condition, then the payload, then audience, then price — no filler despite the length. The long parenthetical inventory of evidence is dense but each item earns its place by telling the agent what the packet will contain.

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 correctly takes on the burden of describing the return value (printable page plus JSON with named sections), and it discloses the per-call cost. What remains unstated — what happens when receipt_id is unknown or the dispute window has passed — is minor for a one-parameter read-only 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?

There is a single parameter and the schema already documents it at 100% coverage (rcpt_... for the decision made before the purchase). The description adds only the indirect cue that a receipt must exist, which the schema text arguably already conveys, so it stays at the baseline rather than adding meaning.

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 uses a specific verb ('we assemble the evidence ... into one printable page and JSON') on a specific resource, and enumerates the packet contents (decision, products checked, sources with dates, order/mandate, recall notices, outcomes, signature verification). It does not name or differentiate itself from plausible siblings such as file_claim or verify_receipt, so a straightforward 4 rather than a 5.

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 gives a clear trigger condition (purchase disputed, returned as wrong, or charged back) and a prerequisite (a Tethered Trust receipt must exist for that purchase), plus the audience. It is weaker on exclusions: it never says what to do when no receipt exists or when a claim should be filed instead of a packet assembled.

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