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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely useful non-schema behavior: it is a paid per-call asset ($0.07 USDC or credits) whose payment must travel in MCP headers (X-Payment / X-Payment-Tx / Bearer fg_…), never in arguments — a costly failure mode the agent otherwise wouldn't know. It does not describe latency, rate limits, caching, or what happens when payment is missing or rejected, which keeps this below a 4.

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 English sentences are front-loaded and dense with the right facts, and the payment-header instruction is well placed at the end. However, the vendor-asset blocks restate the same information three times across Chinese and English, including the $0.07 price and the identical argument list, so a meaningful share of the text is redundant boilerplate rather than decision-relevant content.

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, read-only lookup with no output schema, the definition covers what the agent needs to act: purpose, returned fields, tier tradeoff with the pricier sibling, price, and the payment-header mechanism. The remaining gap is input-side — no format or validity guidance for address and chain — which is significant but narrower than the behaviors that are documented.

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% across two parameters, so the description carries the full burden, and it only restates the argument names ("Args: address, chain") without saying what they mean. It never says whether address is a token contract versus a wallet, what address format is expected, or which chain identifiers are valid and what the null default implies — all of which an agent must guess.

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 opening sentence names a specific question ("is this token a honeypot or a scam") and enumerates the exact payload: verdict on a safe/caution/danger scale, risk flags with levels and explanations, buy/sell tax, and top-10 holder share. It also explicitly separates itself from the richer sibling report ("The full report adds liquidity pools, creator/owner and LP holders"), so an agent can choose between the entry and full tiers without opening a schema.

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 tier framing gives usable selection guidance: pick this entry tier for a quick verdict plus flags and taxes, and move to the full report when liquidity pools, creator/owner, and LP holder data are needed, with a price ($0.02) attached to the larger option. There is no explicit negative guidance (e.g. when token safety is irrelevant or what to do if the address is not a contract), but the entry-vs-full tradeoff is stated clearly enough to route correctly.

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