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

No annotations exist, so the description carries the disclosure burden. It goes beyond a one-line summary by exposing non-obvious processing details: stripping preview/demo post-sign fields, JCS canonicalisation with both ASCII escaping modes, signer recovery, and checking against manifest signers. It does not disclose failure/return behavior, but the core behavior is transparent.

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?

A single dense sentence front-loads the operation name, scope, and method, with no filler. Every clause adds meaningful detail about canonicalisation, signer recovery, and manifest comparison.

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?

The description gives a thorough algorithm but omits the return/result semantics and failure behavior. Since there is no output schema, an agent is left to infer whether the tool returns a boolean, a report, or throws on mismatch. This is a notable gap for a verification tool.

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?

The schema gives only the parameter name and a generic 'string' type. The description compensates by identifying the input as a signed nsgoods response and explaining what happens to it. It lacks an explicit example or formal schema, but it conveys the essential meaning of response_json.

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?

The description opens with a precise verb and resource: 'Offline EIP-191 verify of a signed nsgoods response.' It also details the verification pipeline, making the purpose unmistakable and clearly distinct from the sibling statistics and status tools.

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 intended use is implied: when one needs to cryptographically verify a signed nsgoods response offline. However, no explicit when-to-use guidance or comparison against alternatives is provided, though the sibling tools are sufficiently different that confusion is unlikely.

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