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

Annotations already declare read-only, idempotent, non-destructive, open-world, but the description adds substantial extra context: it is a heuristic that must be verified, it compares against head/tail of addresses the wallet actually transacts with, and it discloses the pricing/rate-limit model ($0.03/call via x402 on Base, prepaid header, 1 free call/day, no API key). That goes well beyond structured fields.

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?

Front-loads the core question effectively, but the body carries promotional and disclaimer filler ('An auto-paying agent is the perfect victim', 'Not financial advice') and pricing detail that dilutes an otherwise compact definition. Several sentences repeat what the annotations and schema already state.

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?

With an output schema present, return values need no explanation, and the description covers the attack model, required inputs, heuristic caveat, and payment mechanics. It is complete for invocation; only minor ambiguity remains about how 'near-miss' results should be acted on.

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% with only two documented params, so the schema already carries the meaning. The description restates them ('Pass wallet= (yours) and to= (the recipient)') and adds the 'sender' framing, but provides no format or validation detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 check ('is this recipient a look-alike trap') on a specific resource (recipient address) and explains the attack it detects via head/tail matching against real counterparties. Clearly separable from siblings like address_check, safe_to_send, or pre_trade_gate because it names the exact heuristic and scenario.

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?

Explicitly says to run it 'before your agent pays' and that an auto-paying agent is the target victim, and instructs passing wallet= (yours) and to= (recipient). It gives clear situational context but does not name alternative sibling tools (e.g., address_trust, counterparty_check) for cases where the check is inconclusive.

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