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

Annotations already declare readOnlyHint and idempotentHint, but the description adds substantial behavioral context beyond them: the tool DECLINES when history is too thin rather than guessing (and says why), every answer embeds self-settling instructions, the calibration provenance (28-day tape, 1.4M liquidations, 799 symbols) that cannot be reconstructed, the 0.02 USDC cost, and the free record location. These are exactly the behavioral traits an agent needs and the annotations do not carry.

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 description is front-loaded with the defining trait ('FORWARD-LOOKING and not a description of what already happened') and the core return value. Every subsequent sentence earns its place: calibration provenance, self-settling transparency, declination behavior, record URL, and cost. Despite its length, there is no filler — each clause adds information an agent needs.

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?

Given the output schema exists and annotations cover safety (read-only, idempotent), the description covers everything else an agent needs: what the probability means, when it declines, how to settle/verify, where the settled record lives, and how much it costs. The pricing and declination behavior are critical operational details that would otherwise be entirely absent.

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% — both 'symbol' (with default SOL) and 'symbols' (comma-separated, max 20) are fully documented in the input schema. The description adds no parameter-specific semantics beyond that, so the baseline of 3 for high schema coverage applies. This is acceptable since the schema already carries the parameter burden.

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 states a precise, specific computation: 'the probability that a symbol will liquidate more in the NEXT 15 minutes than its own 90th-percentile 15-minute window.' It explicitly distinguishes itself as FORWARD-LOOKING 'and not a description of what already happened,' which separates it from history siblings like get_cascade_history and get_liq_history. An agent can tell this tool apart from its siblings without opening the schema.

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 description gives clear context: this is for forward-looking liquidation probability, not historical reconstruction, and it explains the declination behavior ('DECLINES rather than guessing') and the per-call cost, which informs when it should be invoked. However, it never explicitly names alternatives — notably get_cascade_forecast_free, which is presumably the no-cost route — so it stops short of 5, which would require explicit when-not/alternative routing.

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