LiquidVision — Crypto Derivatives Data

get_liquidations

Read-onlyIdempotent

[measured, PAST] Individual liquidation ORDERS that already happened (side, price, qty), newest first, at most limit rows (max 2000). This is the raw feed: use it when you need the orders themselves. For totals use get_liquidations_summary; for cascades as events use get_liquidation_cascades; for where OPEN positions would be liquidated use a *_liquidation_map tool. Market-wide, 500 rows is only a few minutes of a busy hour: pass symbol (BTCUSDT) and/or min_usd to look further back. side=long means a long position was liquidated.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_liquidations"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Maximum number of rows to return.
`symbol`	No	Contract as BASEUSDT, e.g. BTCUSDT, ETHUSDT, SOLUSDT (1000PEPE and kPEPE fold to PEPEUSDT).
`min_usd`	No	Only rows at or above this notional in USD.
`minutes`	No	Look-back window in minutes.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 6, 2026

addedInput schema / properties / limit / description

Added value: +"Maximum number of rows to return."

addedInput schema / properties / min_usd / description

Added value: +"Only rows at or above this notional in USD."

addedInput schema / properties / minutes / description
```
Added value: +"Look-back window in minutes."
```

addedInput schema / properties / symbol / description

Added value: +"Contract as BASEUSDT, e.g. BTCUSDT, ETHUSDT, SOLUSDT (1000PEPE and kPEPE fold to PEPEUSDT)."

Changed3 schema fields changedSep 30, 2026

addedInput schema / properties / limit

Added value: +{
+  "default": 500,
+  "title": "Limit",
+  "type": "integer"
+}

addedInput schema / properties / min_usd

Added value: +{
+  "default": 0,
+  "title": "Min Usd",
+  "type": "number"
+}

addedInput schema / properties / symbol

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Symbol"
+}

First observedSep 23, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds behavior the annotations do not: newest-first ordering, a hard ceiling of 2000 rows beyond the schema's generic 'limit', and the domain-specific meaning of side=long. It does not contradict any annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the nature of the data and a compact '[measured, PAST]' qualifier, then sibling routing, then tuning advice; nearly every clause carries information. It is dense but slightly crammed into one block, making the sibling-routing sentence easy to skim past.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only 4 optional params, an output schema present, and rich annotations, the description supplies everything an agent still needs: what the rows represent, ordering, row cap, how to reach further back, and the side semantics. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the 2000-row maximum on `limit` is not stated in the schema, and the advice to combine `symbol` with `min_usd` to extend the look-back window explains how `minutes`, `symbol` and `min_usd` interact in practice.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: individual liquidation ORDERS that already happened, with the fields returned (side, price, qty) and ordering (newest first). It also explicitly distinguishes itself from four siblings (get_liquidations_summary, get_liquidation_cascades, *_liquidation_map), so an agent can select it without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit use condition ('use it when you need the orders themselves') and names the alternative for each adjacent need: totals, cascade events, and open-position maps. It adds tuning guidance ('pass `symbol` and/or `min_usd` to look further back' when market-wide) rather than leaving the agent to guess.

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

All LiquidVision — Crypto Derivatives Data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?