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

Beyond the read-only and non-destructive annotations, it discloses the exact data boundary, pricing, rolling free-call allowance, wallet-proof binding, and signed receipt. It also explains important result behavior: measurements are made where stated by the delivery, and unsupported figures, certainty claims, and superlatives are flagged.

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?

Purpose and output are front-loaded, followed logically by scope, pricing, authorization, and receipt details. It is nevertheless a dense single paragraph with several appended endpoints and reference links, which reduces scanability despite minimal redundancy.

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 usefully supplies the report’s checklist statuses, measurements, unsupported-claim findings, and Ed25519 signed receipt. Combined with the complete input schema and annotations, its operational, cost, and authorization details leave no major selection or invocation behavior undocumented.

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 already documents all three parameters, including the nested deliverable and evidence forms. The description mostly restates those roles; its evaluation details clarify behavior but add little new per-parameter syntax or invocation guidance.

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 identifies the exact operation and resources: compare a job’s acceptance criteria with delivered text, metadata, or both, optionally using supporting evidence. The addressed/missing/not-met checklist and unsupported-claim reporting distinguish it functionally from the sibling claim-, data-, and terms-evidence checks.

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 job-and-deliverable framing makes the intended post-delivery verification scenario clear, while the no-fetch and no-account-access boundary explains when the supplied material is insufficient. It does not explicitly route agents to related tools for other kinds of checks, so alternative selection remains inferential.

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