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

Annotations already declare readOnly, idempotent and closed-world, so the baseline is low; the description adds genuinely non-derivable context: the call is metered ("Paid per call. Price: 20 sats or US$0.02 (USDC)") and the output is a heuristic signal rather than evidence. It does not say whether the stats are node-local-only in scope or how fresh/stale the underlying data is.

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?

Three short sentences, front-loaded with the returned breakdowns, then the heuristic caveat, then pricing. No filler and nothing an agent must read past to find the core purpose.

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 no output schema, the description usefully enumerates the return contents, and it covers cost and the heuristic caveat, which is what an agent needs before calling. The remaining gap is sibling disambiguation against bitcoin_aml_live and bitcoin_whale_stats_24h, plus any note on the payment handshake outcome on an unpaid first call.

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% — both l402 and pay_with are documented inline, including the '<token>:<preimage>' format and the enum meanings. The description adds nothing about the payment/retry flow (e.g. that a first call without payment returns an invoice), so the 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?

States a specific resource and time window ("Laundering-pattern statistics for the last 24 hours from this node") and enumerates the exact breakdowns returned: cases by score band, by rule, by severity, flagged cases per hour, US$ flagged, and the 5 largest cases. That inventory implicitly distinguishes it from the live/streaming sibling (bitcoin_aml_live) and from single-entity checks (bitcoin_transaction_aml_check, bitcoin_address_risk).

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 24-hour aggregate framing implies the use case (trend/period summary rather than per-transaction screening), and "Heuristic, not proof" warns against relying on it as a determination. However, it never names bitcoin_aml_live, bitcoin_transaction_aml_check or bitcoin_whale_stats_24h to route the agent, and gives no explicit when-not-to-use condition.

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