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

Annotations already declare read-only, idempotent and open-world, so the safety profile is covered. The description adds genuinely useful context beyond them: a per-call cost of 0.02 USDC settled via x402 across five named chains, plus which venues are aggregated and what each row contains. It does not mention rate limits or data freshness/lag, which would have pushed it to 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?

Three sentences, front-loaded with the core capability and the scope constraint before the payoff line and the payment detail. The rhetorical opener 'What is blowing up RIGHT NOW' costs a few words but is short enough not to bury the substance.

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 an output schema present, return values need not be explained, and the description still usefully enumerates the per-symbol fields. Combined with full parameter documentation, annotation coverage and explicit payment/coverage details, an agent has everything needed to select and call it correctly.

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 100% – both limit (1-50, default 10) and window_min (5-1440, default 60) are fully documented with ranges and defaults. The description adds no additional semantics for either parameter, so the baseline 3 applies.

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 verb+resource (top symbols ranked by liquidation USD) and constrains scope precisely: 'every USDT perp we record on Bybit, OKX and Binance'. The ranking framing clearly separates it from siblings like get_liq_feed, get_recent_liquidations and get_liq_heatmap, which are feeds/views rather than leaderboards.

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 line 'The fastest read on where leverage is being flushed' implies a use case, but there is no explicit when-to-use vs when-not guidance and no sibling alternative is named (e.g. get_liq_pulse or get_cascade_alert for other angles). 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.