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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description reinforces this with 'Pure, offline computation (blocktools); nothing is fetched or stored' rather than contradicting it. Beyond that it discloses the return shape (status ok or signer_mismatch, chain, address, recovered signer) and two specific error codes, which annotations cannot convey since there is no output schema.

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 verb and subject are front-loaded and the paragraph is information-dense rather than padded. The final sentence advertising swapchan_playbook workflows is tangential to a stateless signature-verification dev tool and dilutes an otherwise tight definition; the long single block also makes the per-chain rules harder to scan than a short list would.

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 7-parameter tool with zero schema coverage and no output schema, everything an agent needs is present: supported algorithms and expected encodings per chain, the disambiguation rule, the error names it may receive, and the verification result fields. Remaining ambiguity (e.g. whether message is treated as UTF-8 text by default) is minor and partially addressed by message_is_hex.

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?

With 0% schema description coverage, the description carries the full burden and does: it ties sig encoding to chain (65-byte hex vs base64), states chain is derived from the address and required only for the Cosmos-bech32/Solana-key collision, marks format raw|offchain-v0 as required for Solana and pubkey (base64 33-byte compressed) as required for Cosmos, and explains message_is_hex. That is conditional, format-level meaning the bare schema does not contain for 7 parameters.

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?

Opens with a specific verb+resource: 'Check a PUBLIC message signature', then enumerates the exact signature schemes supported (EIP-191 personal_sign, Bitcoin signmessage, Tron signMessageV2, Solana, Cosmos ADR-036). The 'PUBLIC message' / EIP-191 framing implicitly separates it from typed_data_verify (EIP-712), but it never names that sibling, so the differentiation is inferred rather than stated.

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 strong conditional guidance inside the operation (when chain must be supplied, when format/pubkey are required, and the exact errors ambiguous_address and chain_does_not_match_address), which effectively tells the agent how to call it successfully. However there is no explicit 'use this instead of X' routing, and the only cross-reference is a generic pointer to swapchan_playbook playbooks, which is not a selection rule for a dev-tool signature verifier.

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