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

With no annotations, the description carries the full transparency burden and does well by disclosing cost ('Costs $0.01 USDC per call'), the empty-cascades behavior, and the narrow asset/exchange scope. It doesn't mention error handling, rate limits, or exactly how x402 payment is executed, but the disclosed operational traits are substantial.

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, each serving a clear purpose: the first defines the tool and its outputs, the second clarifies empty results, and the third gives the alternative and cost. Information is front-loaded with the core purpose, and there is no filler.

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 no output schema and no annotations, the description covers the essentials: return payload, empty-array semantics, cost, and scope. The main omissions are the meaning of severity thresholds and how to interpret the cascade clustering, but the description is complete enough for an agent to select and call the tool 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?

The input schema already documents all three optional parameters with descriptions and defaults, giving 100% coverage. The description does not add new parameter-level meaning; it only refers to output fields like USD total and prints, which relate to min_usd and min_events only indirectly.

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 specific action and resource: it detects liquidation cascades for exactly SOL, BTC, ETH, XRP, and DOGE, and lists the returned fields (symbol, side, USD total, prints, duration, severity). It also distinguishes itself from sibling get_cascade_scan by explicitly limiting scope to the 5 majors.

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 explicitly names the alternative and the condition that selects it: 'For all ~600 USDT perps across 3 exchanges, use get_cascade_scan.' Additionally, 'active NOW' implies this tool is for current real-time detection, separating it from history/forecast siblings.

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