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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by disclosing the data granularity, fields returned, coverage scope, lookback limit, and the $0.05 USDC per-call cost via x402 on Solana mainnet. It does not mention rate limits, pagination, or response format, but for a read-only data retrieval tool the important operational traits are surfaced.

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 compact and front-loaded with the essential definition of what the tool returns before moving to scope and cost. The uniqueness claim ('this data exists nowhere else') and Bybit context add credibility but are not strictly necessary for invocation. Overall, it is efficient with only minor non-essential content.

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 there is no output schema, the description appropriately summarizes the response contents: total/long/short USD, prints, and biggest print per bucket. It also covers time range, universe selection, and cost, which are the key contextual facts an agent needs. A fully complete description might detail the exact response structure or error behavior, but what is provided is sufficient for most invocation scenarios.

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 covers all 4 parameters with descriptions, so the baseline is 3. The description adds useful semantic context: 'time-bucketed' informs bucket_min, 'up to 7 days back' maps to hours, and 'any USDT perp or the whole universe' clarifies scope and symbol. This goes beyond the schema by explaining why and how the parameters combine to shape the returned data.

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 clearly identifies the resource: historical liquidation tape, time-bucketed with total/long/short USD, prints, and biggest print per bucket. It is specific about scope (any USDT perp or whole ~600-perp universe) and lookback (up to 7 days), making the tool's function clear. However, it does not explicitly name sibling tools like get_recent_liquidations or get_last_liquidation to differentiate them, so it falls short of the strongest sibling-distinguishing bar.

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 implies use for historical liquidation analysis by emphasizing 'HISTORICAL' and time-bucketing, and it clarifies acceptable inputs (any perp or universe, up to 7 days). It does not provide explicit when-to-use or when-not-to-use guidance versus siblings, nor does it mention alternatives. The usage context is clear enough to infer the intended case but lacks direct routing.

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