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

Beyond the readOnly/idempotent annotations, it discloses cost (US$0.20 per batch, with the alternative rail's per-claim pricing and floor), that every verdict carries the register's own date and a citation, that the batch yields ONE receipt, and that the Ed25519 receipt is verifiable offline against a named well-known key. Those are exactly the traits an agent can't get from annotations: price, evidentiary output and auditability.

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 verb and resource are front-loaded in sentence one, and the verdict taxonomy follows immediately. It is a single dense paragraph with some redundancy around pricing/rails and receipt signing, but nearly every clause carries actionable information rather than filler.

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?

There is no output schema, so the description carries the return burden and does: per-claim verdicts, accompanying register dates, citations, and one signed receipt with offline verification. Combined with annotations covering safety and the fully documented single parameter, an agent has everything needed to call it and interpret the result.

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 enum already lists the vocabulary, so the baseline is 3; the description adds real meaning by explaining that field is closed-vocabulary and that an off-list field is answered not_checkable naming the list, and by describing subject as identifier, name or both. Much of this restates schema text, which keeps it from 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?

It opens with a specific verb+resource ('Audit what an agent believes about companies') and then defines the exact output taxonomy (supported / contradicted / stale / not_checkable) plus batch size, so the tool's function is unambiguous. It never names a sibling such as check_entity or route_claim, so an agent must infer why it would pick this over a single-entity lookup.

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 concrete boundary condition – up to 10 claims on this rail, longer audits go to POST /audit with its pricing – which is real routing guidance. It also states the consequence for out-of-vocabulary fields (not_checkable, not a guess). What's missing is explicit guidance on when to use this versus the sibling check/route/verify tools for a single belief.

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