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

With no annotations supplied, the description carries the full behavioral burden and does meaningful work: it discloses a hard cost ($0.01 USDC per call), the settlement chain (eip155:8453), the exact payment mechanism (x402 via params._meta['x402/payment']), and the HTTP endpoint. What is missing is any statement about response shape, failure modes, or what happens on unpaid calls, but the payment/auth disclosure is substantial.

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-loaded with the value proposition, then the commercial and transport facts. Every clause supplies information an agent needs before calling; nothing is padding.

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?

For a paid, no-annotation, no-output-schema tool, the description covers cost, payment path, endpoint, and return contents well. It falls short on the two input parameters, which are completely undocumented, leaving an agent to guess whether addr is a token or wallet address.

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 0% and the schema's addr and chain properties carry no description at all, so the description must compensate and largely does not. It never explains what addr should contain (token contract vs. wallet address) or which chain identifiers chain accepts, despite chain being effectively pinned to Base by the payment info.

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 and enumerates the concrete deliverables: token report, wallet context, and a plain-English risk verdict with aggregated flags. That makes the bundle scope clear enough to distinguish it from narrower siblings like token_dd__dd or token_dd__wallet, though no sibling is named explicitly.

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 phrase 'BEST VALUE: one call returns the complete due-diligence bundle' implies this should be preferred over making several narrower calls, which is useful routing guidance. However, it never states when NOT to use it or names a specific alternative, so the guidance remains implied rather than explicit.

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