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

Annotations already cover readOnlyHint/idempotentHint, and the description adds genuinely new operational context: auth headers on /mcp, REST dual-auth with x402 settlement after HTTP 402, and a latency-driven preference for small limits. The 'Read-only' restatement is redundant, and the trailing pricing sentence concerns meteora_brief rather than this tool, so it is 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 first two sentences are well front-loaded and earn their place, but the remainder is generic cross-tool boilerplate about REST content negotiation, signup URLs, and dynamic pricing on meteora_brief — a different tool entirely. Roughly half the text is unrelated to selecting or calling dex_top_movers.

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 read-only, zero-required-parameter list tool with full schema coverage and no output schema, the definition supplies the ranking logic, the volume floor, latency advice, and auth/payment paths. An agent has everything needed to call it correctly on first attempt.

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 100%, so the documented chain/limit/min_volume_24h_usd fields already carry their own semantics. The description still adds value beyond the schema by advising a small limit (3–5) to control latency, which the schema's default of 10 and max of 50 would not suggest. The chain parameter is never contextualized in prose.

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 gives a specific verb and resource plus the ranking rule ('largest absolute 1d volume change %') and a filter ('above a minimum 24h volume'), which is precise enough to distinguish this from dex_overview or solana_dex_brief. It does not name or contrast any sibling explicitly, so it stops short of a 5.

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?

'Use to prioritize venues with unusual flow' states the intended decision context, and 'prefer small limit (3–5)' gives concrete invocation guidance for latency. There is no statement of when NOT to use it or which sibling to pick for the alternative (e.g., a full per-chain overview), so no explicit alternatives are offered.

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