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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), and the description adds material context beyond them: a free tier with a daily per-caller quota, and the auth mechanism (X-Payment / X-Payment-Tx / Authorization: Bearer fg_…) with the explicit warning not to put credentials in parameters. Quota-exceeded behavior and the shape of the paid response are left unstated.

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?

Opens with the question an agent would ask, then the free-tier payload, then params, then auth mechanics — a sensible front-to-back order. The trilingual repetition and the duplicated arg list ("参数 top 与 protocol 可选" then "Args: top, protocol") are redundant but short enough not to obstruct scanning.

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 carries the return-value burden and does so by enumerating count, top-5 ranks, names and 24h fee USD, plus the single-protocol variant. Given only two trivial params and rich annotations, the main remaining gap is default/bound semantics for `top`.

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% — both params are bare titles with null defaults — so the description must compensate, and it only partially does: it says both are optional and that `protocol` switches to a single-protocol summary. It never explains what `top` defaults to, its bounds, or whether `protocol` takes a slug or display name.

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 question the tool answers ("which protocols earn the most fees") and names the returned fields: protocol count, top-5 ranking, names and 24h fee USD. It never names the closest sibling (protocol-revenue.revenue_report), so an agent must infer differentiation from the name alone.

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?

Usage is implied through the framing question and the note that passing `protocol` returns that protocol's summary instead of the leaderboard, which is a genuine selection hint. There is no explicit when-not guidance, no mention of how this compares to revenue_report, and no stated behavior when the free quota is exhausted.

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