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

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description nonetheless adds two things annotations cannot: the leaf_hash case also emits an inclusion proof for local recomputation without trusting Certisyn, and an unknown root resolves to 'not anchored, never verified' — an explicit fail-closed semantic. It stops short of describing the result shape itself.

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 short sentences, front-loaded with the action, then the conditional branch, then the failure rule. No restatement of the title or schema and no 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?

With only two parameters and full schema coverage, the definition covers invocation and the trust model well. The remaining gap is the verification outcome itself — no output schema exists and the description never says whether success is returned as a boolean, a status string, or an attestation object.

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%, so baseline is 3, but the description adds real meaning: leaf_hash exists to produce an inclusion proof the caller can independently recompute, which explains why you would supply it rather than merely that it is optional.

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?

A specific verb plus resource: verify an anchored evidence root, with the 'independently' framing signalling trustless recomputation. It does not distinguish itself from the several sibling verify tools (verify_mandate, consilience_verify, bastion_verify_credential), so an agent must still infer which verification target applies.

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?

Conditional guidance is present for the optional parameter ('With leaf_hash, also returns the inclusion proof'), but there is no statement of when to use this over a sibling verification tool or any stated preconditions beyond needing a root hash.

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