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

Goes well past the annotations: discloses $0.002/call x402 pricing with USDC on Base only, that Base bad input is not charged while other rails may be, that returned content is untrusted third-party data, and that 'allow' means only that no check flagged the address rather than a safety guarantee. The dated-snapshot and GPL-3.0 source caveats further set expectations. Nothing here contradicts readOnlyHint/openWorldHint/idempotentHint=false.

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-loaded with what is checked, then the verdict semantics, then cost and caveats — a sensible order with little filler. The clipped, fragment-dense phrasing ('GET chain ..., to; opt. expected, token') and the odd 'mechanical' cost some readability, but every sentence carries information an agent needs before calling a 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?

With four fully documented parameters and a clear safety annotation profile, the remaining burden is on return values and cost, and the description covers both: 'allow, warn or block per check' plus the explicit caveat on what 'allow' means, and the per-call price. The one gap is that the shape of the per-check results (verdicts, which check failed) is not sketched, and there is no output schema to fall back 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 description coverage is 100%, so the schema already explains to, chain, token and expected in detail. The description's terse restatement ('GET chain (base/polygon/solana/xrpl), to; opt. expected, token') adds no meaning beyond that, so the baseline 3 applies.

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?

Enumerates the concrete checks performed (lookalike, OFAC SDN snapshot, account age, ScamSniffer) against a named resource (a recipient address before a crypto transfer), which clearly separates it from siblings like tx_status, name_resolve or x402_check. The opening sentence is telegraphic ('..., mechanical') and takes a second read, but the resource and scope are unambiguous.

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?

'before a crypto transfer' implies the trigger condition, and the allow/warn/block explanation clarifies what the outcome means. However, no alternative tool is named (name_resolve, x402_check, tx_status), no when-not guidance is given, and the caller is left to infer that this is a pre-send gate rather than a general address lookup.

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