Decode 'what am I signing' EIP-712 signature (paid $0.01)

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

With no annotations, the description carries the full burden, and it excels. It discloses that this is a PAID tool ($0.01, x402/USDC on Base), explains the payment/response flow, and explicitly states 'Pure offline decode — never signs/broadcasts', which is critical safety information. It also indicates what happens without payment (returns challenge), giving the agent a clear behavioral model.

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 description is dense but each sentence provides distinct value: payment notice, decode functionality with risk flags, context on wallet-drainers, safety guarantee, payment flow, and free alternative. It is front-loaded with the most critical pricing/payment information and avoids fluff.

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?

Despite lacking an output schema, the description adequately covers the return behavior (plain English with risk flags, challenge vs real result). It provides enough context for an agent to understand the tool's role in wallet-drainer defense, its offline nature, and the payment mechanism, making the description self-sufficient for a tool of this complexity.

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 the baseline is 3, but the description adds meaning beyond the schema by explaining the payment workflow (x_payment forwarded as X-PAYMENT header, omitted to get price challenge) and how chain relates to domain.chainId (override semantics). It clarifies why typed_data is required and how it is used, exceeding the schema's bare property descriptions.

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 uses a specific verb ('Decode') and clearly specifies the resource (off-chain EIP-712 typed-data signatures) and the output (plain English with risk flags). It lists concrete signature types (Permit, Permit2, Seaport, generic) and enumerates the risk flags, making the tool's function unmistakable and distinct from sibling tools like decode_signature_free.

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 provides operational guidance: it explains the payment flow (without payment returns an x402 challenge; pass x_payment to get the real result) and points to decode_signature_free as a free alternative. It implies the tool is for paid/production use and the free version for teasers, but it does not explicitly contrast with siblings like approvals or simulate beyond stating its offline nature.

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