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

Annotations already declare read-only, idempotent, open-world, non-destructive, so the safety bar is met. The description adds genuinely useful behavior beyond them: per-call pricing ($0.09 USDC or prepaid credits) and, critically, that payment credentials go in MCP request headers (X-Payment / X-Payment-Tx / Bearer token) and must not be passed as parameters.

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 lead sentence is well front-loaded and the payment note is actionable, but the same vendor-asset and args information is repeated in both the [zh] and [en] blocks, and the Chinese full-report listing duplicates the English summary, adding bulk without new information.

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 does describe the returned fields (19 categories, malicious contract count, contract flag, entity labels, methodology boundary), which is valuable, and payment mechanics are covered. The remaining gap is the chain parameter's accepted values, which nothing in the definition or schema resolves.

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%, so the description must carry parameter meaning. It only restates that address is required and chain is optional — facts already in the schema's required array. It gives no accepted chain values, format, or default behavior for chain, leaving a real ambiguity for the caller.

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 question the tool answers ("has this address been involved in scams") and enumerates the report payload: 19 risk categories, malicious contract count, entity labels, contract-address flag. The word "full" signals it is the deeper version of a lighter screening sibling, though that sibling is never named.

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?

Framing the use case as a question an agent asks implies when to reach for it, and the paid-per-call model implies a cost tradeoff, but there is no explicit when-to-use/when-not-to-use or named alternative (e.g. address_screen vs address_report). The agent must infer the split.

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