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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior; the description adds substantial behavioral context by disclosing that CONCISE returns only the densest levels in a few hundred tokens, DETAILED returns the full grid, and the result carries provenance. No contradiction with annotations.

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?

Two sentences deliver the core concept, the non-forecast boundary, both response modes and their sizes, and provenance. The information is front-loaded and every sentence earns its place; there is no repetition of schema or annotation fields.

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 zero required parameters, no output schema, and a moderate tool, the description still supplies enough to invoke correctly: supported coins, timeframe semantics via schema, response_format behavior, and the meaning of returned data. The main unstated details are the exact JSON shape, which is not strictly necessary for a correct call.

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?

The schema already documents coin and timeframe defaults/options; the description compensates for the undocumented response_format parameter by explaining CONCISE (default) vs DETAILED and their output sizes. It also restates supported coins, adding practical context beyond the bare enum. It does not add further meaning to timeframe, but the schema covers that adequately.

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 opens with a specific verb and resource: it reports observed liquidation price levels for BTC, ETH, SOL, or HYPE, and specifies the output's content (price buckets, realized liquidations, share of open interest observed). The explicit 'Not a forecast' caveat further sharpens what the tool is and is not. Though it doesn't name a sibling tool, the description is detailed enough to distinguish it from a raw liquidation feed.

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?

It clearly implies the use case—requesting liquidation heatmap/coverage for major coins over a chosen timeframe—and adds an explicit when-not in 'Not a forecast.' It also explains when to choose CONCISE vs DETAILED. However, it never names an alternative such as tape_liquidations or says when to prefer that sibling over this heatmap.

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