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

Annotations already mark it read-only, idempotent, and non-destructive. The description adds operational context: x402 pricing on Base, free call/day, prepaid header option, and no wallet/API key required. This complements annotations without contradiction.

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?

Two sentences front-load the core behavior and then add pricing/access details. The information density is high; the only slightly extraneous part is the billing detail, but it is useful for an agent deciding whether to call the paid tool.

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?

Given a rich annotation set, an output schema, and a single parameter, the description covers purpose, outputs, access constraints, and cost. It is complete enough to invoke correctly; no pagination or network details are missing for a simple lookup.

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% and the sole address parameter is already described as 'Wallet address'. The description merely restates that address is required, adding no format, validation, or example beyond the schema.

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?

Describes the tool with a specific verb ('Lists') and resource ('a wallet's active token approvals'), enumerating outputs (contracts, allowance, USD at risk, risk factor) and citing a known style (revoke.cash). This clearly differentiates it from sibling tools like revoke_builder or approval_advisor.

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?

Provides clear context as an 'essential wallet-security check' and states required input and cost/access considerations. However, it does not explicitly name alternatives or conditions for when to use this over approval_advisor or spend_audit.

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