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

With no annotations, the description carries the full behavioral burden, and it does disclose two useful traits: it is read-only and performs no remote fetching. It does not say whether a failed signature check raises an error or returns a negative result, nor how expensive/authoritative the recomputation is. Adequate but incomplete for an unannotated tool.

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 lead sentence states the action, the second states the operating constraint, and the Args block documents each parameter. Front-loaded and free of filler, though the docstring-style indentation is slightly awkward for a tool description.

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 offline/read-only note covers the main environmental concern. Given four parameters with nested objects and zero schema description coverage, an agent still lacks detail on the expected shape of the mandate and action objects, which is the main gap.

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% and there are four parameters including nested objects, so the description must compensate, and it largely does: agent is 'public agent identifier', mandate is 'the public AAE Verifiable Credential', actions are 'public, already-decoded on-chain actions', and signature is 'optional prior MolCheck signature to check'. The 'already-decoded' qualifier is genuinely useful input-shape guidance, though the expected internal structure of mandate/actions remains unspecified.

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: recompute a verdict from public inputs and check its signature. It is clearly distinguishable from molcheck_verdict (produce a verdict) and from the moltproof_verify sibling family. It does not, however, explicitly contrast itself with those siblings in the text.

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 gives a real usage constraint ('Offline and read-only: no DID/mandate/context is fetched here'), which tells the agent this is a self-contained check rather than a live lookup. It stops short of saying when to choose this over molcheck_verdict or moltproof_verify, or what preconditions the caller must satisfy.

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