whale-insights

liquidations

Read-onlyIdempotent

Get leveraged-position liquidation estimates — long and short liquidation amounts in USD per token (5-min cache) — Estimated leveraged-position liquidations by token — how much USD in long positions and short positions were force-liquidated recently. Useful for identifying tokens with high leverage risk and likely volatility triggers. Derived from market price action and open interest data. Cached ~5min. Note: these are estimates, not exact exchange data (Binance Futures and Bybit are geo-restricted from the server).

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`tokens`	No
`updatedAt`	No
`attribution`	No
`binanceSources`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "attribution": {
+      "$ref": "#/components/schemas/Attribution"
+    },
+    "binanceSources": {
+      "type": "boolean"
+    },
+    "tokens": {
+      "items": {
+        "properties": {
+          "longLiquidations": {
+            "type": "number"
+          },
+          "shortLiquidations": {
+            "type": "number"
+          },
+          "symbol": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "updatedAt": {
+      "format": "date-time",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedJun 17, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds meaningful behavioral detail: a ~5-minute cache, estimates rather than exact exchange data, geo-restrictions for Binance Futures and Bybit, and derivation from price action and open interest. This goes well beyond the structured annotations.

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

Conciseness3/5

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

The description is front-loaded with the core purpose, but it contains redundancy: the 5-minute cache is mentioned twice ('(5-min cache)' and 'Cached ~5min'), and the first two sentences both restate 'long and short liquidation amounts in USD per token'. Trimming would improve precision.

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?

For a zero-parameter tool with an output schema and a read-only annotation profile, the description covers everything needed to invoke it correctly: what is returned, token-level granularity, recency, cache behavior, estimate caveat, and geo-restrictions. Nothing essential 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?

With zero parameters, the baseline is 4, and the description correctly avoids inventing parameter details. No parameter explanation is required, so this dimension is satisfied by the design rather than the prose.

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

Purpose4/5

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

The description gives a specific verb and resource ('Get leveraged-position liquidation estimates') and concretely defines the output as long and short liquidation amounts in USD per token. It is clear even without naming siblings, but it does not explicitly distinguish itself from related leverage tools like leverage_radar, so it earns a 4 rather than a 5.

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

Usage Guidelines4/5

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

The phrase 'Useful for identifying tokens with high leverage risk and likely volatility triggers' gives a clear, actionable context for when to call this tool. It doesn't state when not to use it or point to alternatives, so it falls short of the explicit routing standard.

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

All whale-insights 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?