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

With no annotations, the description carries the full burden and does real work: 'Nothing is fetched' rules out network side effects, and 'Embedded keys establish internal consistency only; revocation is not affirmed' is a genuinely valuable limitation that prevents an agent from over-reading a success result. It does not describe failure modes or what an unsuccessful verification looks like, but the output schema covers the shape.

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 and scope, then the no-fetch guarantee, then the trust limitation. No filler, and the most decision-relevant caveat is placed last for emphasis rather than buried.

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?

An output schema exists, so return values need not be explained, and the description covers side effects and trust semantics well. The remaining gap is sibling disambiguation against verify_trace_record, which matters for a dense verify_* family.

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 50%, so the description must compensate partially. It maps 'optional caller public key' to trusted_key and 'freshness controls' to the age/time parameters, which is useful. But it never clarifies what `now` is for (an override of the evaluation clock) or how max_age_seconds is applied, leaving two of four parameters semantically thin.

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 with qualifiers: verify a TRACE v0.2 Ed25519 Trust Record, performed locally. 'Locally' and 'Ed25519' sharply scope it. However, a sibling is literally named verify_trace_record, and the description never explains how this differs from it, leaving an ambiguity an agent must resolve by opening both schemas.

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 description implies the use case (offline verification of a trust record you already hold) and notes optional caller key and freshness controls, which hints at when those parameters matter. It never states explicit when-to-use or when-not-to-use conditions, nor names an alternative among the many verify_* siblings.

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