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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the marginal burden is low, and the description still adds real substance: enumerated verdict outcomes, per-check pass/fail reporting, a verifiable signed record, and the explicit caveat about what consistency does NOT imply. It also states cost and statefulness ('Free; nothing stored'), which is exactly the kind of operational fact annotations cannot express.

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?

Four tight sentences, front-loaded with purpose, then input shape, then return values, then caveats and cost — a sensible order. There is minor redundancy between the verdict list and 'It shows the evidence is consistent and was signed by those keys', but no filler sentences.

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 two-parameter tool with deeply nested arrays and no output schema, the description covers what the agent must supply, what outcomes come back, how the result is verifiable, and the trust boundary of the result. Nothing an agent needs in order to call it correctly or interpret the verdict 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 description coverage is reported at 0%, so the description carries the semantic load, and it does: parties are two ids with Ed25519 public keys in buyer/seller roles, and events are one of six types signed by their maker and chained to an earlier event by hash. This explains the meaning of the `ref` and `sig` fields and the required role pairing better than the bare schema does. It leaves `at`, `body` and the maxItems caps unaddressed, so not quite a 5.

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 opens with a specific verb and resource ('Audit a finished deal between two parties from its signed evidence') and immediately narrows the scope to signed evidence, verdicts and a signed record. That is clearly distinct from adjacent tools such as underpayment_audit_compare or countersign_verify, which compare amounts or verify a single signature. An agent can tell what this produces 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?

Usage context is clear: a *finished* deal with *signed* evidence, two role-bound parties and a hash-linked event chain. The description also fences the scope by saying it does not prove money moved, goods arrived or who the parties are, which tells an agent when the answer is insufficient. It names no explicit alternative tool, so it stops short of a 5.

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