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

With no annotations available, the description carries the full burden and does so well: it explains what `ok=true` means, that unsigned receipts fail, that a passing verification does not prove signer identity, and that post-quantum keys are not covered by the `kid`. These are exactly the behavioral caveats an agent needs before relying on the result.

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 description is dense but front-loaded: verification scope arrives first, followed by the exact meaning of `ok`, then the signer-pinning caveat, then the post-quantum `kid` caveat. Every sentence adds decision-relevant information without 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?

For a verification tool with no annotations and an output schema, this description supplies the key verification semantics, failure conditions, trust limitations, and parameter behavior needed to call and interpret it correctly. The presence of an output schema reduces the need to explain return fields in detail.

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 0%, so the description must compensate. It explains `require_pq` as defaulting on and requiring at least one post-quantum leg, and it explains that `expected_kid` pins the signer's Ed25519 key only when that key's own signature verifies. The `receipt` object itself is only characterized as a certificate, leaving its nested structure to the schema and output 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 states a specific verb and resource: verify a TrustGate receipt from the certificate alone, offline. It makes the scope and meaning of `ok=true` clear, though it does not explicitly contrast this tool with sibling tools such as `get_receipt_evidence` or `mint_action_receipt`.

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 clear usage context: perform verification offline from the certificate alone, and use `expected_kid` when the caller needs to pin the signer. It does not explicitly state when to choose this tool over sibling evidence-retrieval or receipt-minting tools, but the operational context is clear.

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