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

Annotations already cover read-only, idempotent, open-world, non-destructive, so the safety profile is settled. The description then adds genuinely non-obvious behavioral context: a per-call price ($0.09 USDC or credits) and the requirement that payment credentials travel in MCP headers (X-Payment / Authorization: Bearer) rather than in arguments. It also sketches the returned fields in the absence of an output schema, though it gives no pagination or size limits for the 'every protocol' full listing.

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 text is duplicated across English and Chinese, the argument list is repeated three times, and marketing framing ('供应方资产', price blurb) is interleaved with the functional description. The useful scope statement is buried in the middle rather than front-loaded, and the pipe-separated formatting adds noise.

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 two-parameter, no-output-schema read tool, the description does supply payment mechanics and a rough return-field inventory, which covers the biggest unknowns. What it leaves out is exactly what an agent needs to call it correctly: the semantics and accepted format of top and protocol, and any indication of result size or cost scaling when returning the full leaderboard.

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% and both parameters are bare (top: number, protocol: string) with no titles beyond the field name. The description only repeats the names twice in two languages and says they are optional; it never says whether top is a result count, whether protocol takes a slug or display name, or what the default (return everything?) means. With zero schema coverage the description had the full burden and did not carry it.

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 names a concrete resource (protocol fee/revenue leaderboard) and enumerates the metrics returned: 24h/7d/30d fees and trend vs the 30d average, plus the fees-vs-revenue distinction. It is not a tautology. However, it never distinguishes itself from the sibling fee_leaderboard, which by name alone suggests overlapping scope, so the agent cannot tell the two apart from this text.

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?

There is no when-to-use or when-not-to-use guidance: nothing says when to pick this over fee_leaderboard or protocol_card, and no prerequisites are stated beyond payment. The only usage-adjacent statement is that top and protocol are optional, which merely restates the schema's required:0.

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