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

Annotations already cover the safety profile (read-only, idempotent, non-destructive, open-world), and the description adds substantial context on top: the outputs it emits, the heuristic caveat that LPs and routers legitimately sit on both sides, the cost per call, and the header needed for unlimited use. That is exactly the extra behavioral layer the structured fields cannot convey.

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 core question and the mechanism are front-loaded in the first two sentences, which is the right ordering. The tail carries pricing, credit, and disclaimer boilerplate that is useful but denser than necessary for a tool-selection decision.

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 further explanation, and the description still summarizes the verdict vocabulary and the top round-trippers. Auth, cost, defaults, and the heuristic's limits are all covered, leaving nothing an agent needs before calling it.

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 description coverage is 100%, so both parameters are already documented, and the description largely restates the days default. It does reinforce that address is required and frames days as the analysis window, but adds no format or constraint detail beyond the schema. Baseline 3 is appropriate.

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 states a concrete verb-and-resource pair: it reads a token's transfer events and flags the wash/circular shape, returning clean / elevated / likely_wash. That is far more specific than the name alone. It never names a sibling such as volume_check or token_transfers, so differentiation is left to inference 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 clear operating context: pass days= (default 7), treat the result as a sizing signal rather than proof, and the payment/auth model (x402, prepaid header, one free call/day). It stops short of explicit when-not-to-use or naming alternative tools for volume questions, so it is strong but not complete routing guidance.

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