whale-data

Market-wide liquidations

market_liquidations

Read-onlyIdempotent

The whole market's forced closes in one call rather than per pair: 24h dollars and counts split long vs short, hour by hour so a cascade is locatable, ranked by coin, plus the biggest single event. Perp dollars come from the venues that publish a liquidation feed, not from every venue we stream, and the Hyperliquid share is a sample of that venue read from tracked wallets, so the totals are a FLOOR. Includes named_liquidations, the wallets that were closed out on Hyperliquid, which no other venue publishes. lending_liquidations rides alongside as a SEPARATE lane (an on-chain debt repaid and collateral seized) and must never be added to the perp numbers. A long is force-closed by selling, so long dollars are sell-side pressure. Descriptive market data only.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No	One line saying what the numbers cover, or why there are none. Read it before reporting any zero as a market reading.
`as_of`	No	When the combined snapshot was taken, as an ISO stamp.
`stale`	No	True when the snapshot is older than it should be.
`coverage`	No	Which feeds fed this snapshot.
`available`	No	False when this lane could not answer: a producer is dark, the pair sits outside this plan, or the argument named something we do not carry. Absent or true means the numbers are a real reading, not a guess.
`perp_liquidations`	No	The 24h forced-close picture on leveraged markets: count, total_usd, the long and short split in both dollars and counts, hour by hour, the peak hour, the ranked coins, the biggest single event, and which exchanges are behind the totals. Long dollars are sell-side pressure.
`named_liquidations`	No	Hyperliquid closures with the wallet named, which no other market publishes.
`lending_liquidations`	No	A SEPARATE 24h lane: on-chain debts repaid and collateral seized. count, total_usd, protocols, chains and recent rows. Never add these to the leveraged numbers.

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (read-only, idempotent, non-destructive), the description discloses critical caveats: data only from venues publishing liquidation feeds, the Hyperliquid share is a sample, totals are a floor, and long dollars represent sell-side pressure. This is exactly the kind of behavioral context annotations do not provide.

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

Conciseness5/5

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

The description is dense but every sentence adds unique value: scope, data caveats, separate lanes, and interpretation. It is structured logically, starting with the definition, then limitations, then usage warnings, and ending with a clarifying statement about descriptive data. No filler.

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?

Given the tool has an output schema and zero parameters, the description carries the responsibility of explaining the nuanced data behavior. It covers data provenance, aggregation method, the floor nature of totals, the unique named_liquidations, and the separation of lending liquidations. This is complete for a tool of this complexity.

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?

The input schema has zero parameters, so the baseline is 4 per the rubric. The description does not need to add parameter detail because there are none, and the schema coverage is effectively 100%.

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?

The description opens with a specific verb and resource: "The whole market's forced closes in one call rather than per pair." This clearly distinguishes it from per-pair liquidation tools, and the detailed breakdown (24h dollars/counts, long vs short, hourly, ranked by coin) makes the tool's purpose unambiguous.

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 description states the tool is market-wide rather than per-pair, implying it should be used when a whole-market view is needed. It also provides an explicit when-not: lending_liquidations must never be added to perp numbers. However, it does not name specific sibling tools as alternatives, so it stops short of the highest bar.

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

All whale-data tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0

Disambiguation3/5

Many tools share the same broad purpose domains, such as market_digest vs market_overview vs market_snapshot and whale_context vs whale_profile vs whale_flow, making selection genuinely ambiguous for an agent. The long descriptions help separate them, but the sheer number of overlapping 'one-call' market and whale views still invites misselection, and whale_tape is a direct duplicate alias.

Naming Consistency4/5

Names are consistently snake_case and mostly follow a clear domain-prefix pattern: market_*, whale_*, hl_*, defi_*. Minor deviations like liquidations vs market_liquidations, liq_zones, my_access, and the deprecated whale_tape keep it from a perfect score, but the overall convention is predictable and readable.

Tool Count2/5

With 30 tools, the server exceeds the reasonable upper bound and feels heavy even for a broad data domain. Many tools could be consolidated—for instance, several one-call market summary tools and multiple whale-flow variants—without losing capability.

Completeness4/5

The tool set covers an impressively wide range of whale and market data: news, liquidations, funding, DEX activity, Hyperliquid wallets, market scans, history, and plan access. There are minor gaps such as no general price/OHLC history or per-wallet trade history beyond swaps and fills, but agents can work around these using the existing surface.

Resources

Need Help?