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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes further by disclosing a daily per-caller quota, tier gating of fields, and exactly how auth is transmitted (X-Payment / X-Payment-Tx / Authorization: Bearer fg_…) plus the explicit warning not to put payment in parameters. It does not describe behavior on quota exhaustion or payment failure, so not a 5.

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 content is repeated three times: an English/Chinese summary block, then a [zh] paragraph, then a near-identical [en] paragraph restating the same args. Marketing framing ("Ask 'who holds this token'", "various asset") and inconsistent language switching obscure rather than front-load the operative 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?

For a 3-param, read-only, no-output-schema tool, the definition does cover return shape at the free tier and the auth mechanism. It still leaves the 'top' parameter's effect and address input expectations undefined, and a caller cannot tell what happens when the daily quota is hit.

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 coverage is 0%, so the description must compensate. It does supply the chain enum (eth/base/bsc/arbitrum/optimism/polygon/solana/sui), which is genuinely absent from the schema, but it never explains address format (contract vs. wallet, per-chain normalization) or what the 'top' parameter actually controls — 'top1/5' refers to returned metrics, not the parameter.

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?

"Ask 'who holds this token'" plus an explicit enumeration of what the free tier returns (holder count, top-10 share, concentration grade) and what the paid tier adds (top1/5, lockup/contract share, risk flags, per-address detail) makes the resource and scope concrete. It never names holders.holder_list, so the boundary with the per-address sibling is left implicit, which keeps it out of 5 territory.

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 free-vs-paid split gives real context for expectations, but there is no explicit "use this when / use X instead" routing, and the sibling that returns per-address data is only alluded to as "付费档" rather than named. Usage is implied rather than stated.

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