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

Annotations already declare read-only, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds meaningful disclosure beyond that: the caller-supplied jwks is silently replaced with published keys including predecessors, the service is free, and it explicitly disclaims granting authority, establishing current time, or verifying on-chain settlement. That last sentence is unusually useful scope-limiting information.

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?

Three compact sentences that are front-loaded with the operative action and follow with key-replacement semantics and scope disclaimers. No filler, though the final disclaimer clause is somewhat compressed into a list that requires parsing.

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 a deeply nested recursive schema and no output schema, the description gives the essential trust model (issuer keys replace caller keys, predecessors included) but leaves the response shape and most parameter contracts unexplained. It is enough to understand intent, not enough to call correctly without reading the raw schema closely.

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% across 7 parameters, so the description must carry the load. It explains the most counterintuitive one (jwks is overwritten, not trusted) and hints at the digest requirement, but says nothing about expected_nonce, expected_node_id, the recursive previous_receipt chain used for predecessor key verification, or what max_clock_accuracy_radius_ms controls.

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?

States a specific verb and resource: verify TAIN 2.0 evidence against keys from the fixed POPCORN issuer URL. That is concrete and scoped. It stops short of distinguishing itself from the sibling popcorn_verify (presumably the v1 path), so an agent must infer the difference from the version suffix alone.

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?

'Send a digest, never private work' is a real usage constraint, and the closing clause defines what the tool does not do. But there is no explicit routing guidance against the other six siblings, notably popcorn_verify, and no stated preconditions for choosing this over the v1 variant.

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