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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so the safety profile is covered. The description adds semantic value by defining how a cascade is computed (a 4-hour move plus prior liquidation exposure), which goes beyond the annotations. It does not disclose return format, ordering behavior, or result limits, leaving that to the schema.

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?

A single front-loaded sentence that leads with the core concept and does not pad. Slightly dense with the back-referenced 'min_move_pct' and dash clause, but every part earns its place.

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 5-parameter read-only analytics tool with no output schema, the description conveys the concept but omits usage routing and any characterization of returned records. Adequate to understand the metric, but incomplete on when to reach for it over the many liquidation siblings.

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 60%: coin, sort and min_move_pct carry inline descriptions while days and limit do not. The description reinforces min_move_pct ('at least min_move_pct in one 4-hour step'), adding context on the unit, but adds nothing for coin, days, sort or limit. Baseline 3 is appropriate given the schema does most of the work.

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 specific analytical resource: past sharp moves paired with the liquidation exposure that sat in their path, framed as evidence about whether clusters get 'run'. This is distinct from siblings like liquidation_map or liquidation_totals, though it never names those siblings to sharpen the distinction. A clear verb+resource, but not explicitly differentiated from its alternatives.

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 explicit when-to-use, when-not-to-use, or routing to alternatives. The phrase 'the evidence for whether clusters actually get run' hints at the analytical purpose, but with siblings like liquidation_map, liquidation_totals and recent_liquidations present, the agent gets no guidance on which to pick. Usage is implied at best.

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