LiquidVision — Crypto Derivatives Data

get_lighter_liquidation_map

Read-onlyIdempotent

[measured, RISK AHEAD, Lighter] REAL open positions on Lighter (zk perp DEX; crypto plus equity indices, stocks, forex, commodities) binned by Lighter's own liquidation price. Not a model. Use this for Lighter; get_hl_liquidation_map for Hyperliquid; get_liquidation_map (modeled) for the CEXs. Accounts are discovered from the public trade stream, so coverage (covered_long_pct/covered_short_pct of venue open interest) grows with time. Returns long/short notional per bin, cumulative curves and the largest positions. range: 12h | 1d | 3d | 7d | max.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "symbol": "<symbol>"
    },
    "name": "get_lighter_liquidation_map"
  }
}

Input Schema

Name	Required	Description	Default
`range`	No	Price range around the current price: 12h \| 1d \| 3d \| 7d (and 'max' where stated), the traded range of that window.	1d
`symbol`	Yes	Contract as BASEUSDT, e.g. BTCUSDT, ETHUSDT, SOLUSDT (1000PEPE and kPEPE fold to PEPEUSDT).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 6, 2026

addedInput schema / properties / range / description

Added value: +"Price range around the current price: 12h | 1d | 3d | 7d (and 'max' where stated), the traded range of that window."

addedInput schema / properties / symbol / description

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

AddedOct 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations it discloses the non-obvious provenance caveat: accounts are discovered from the public trade stream, so coverage (covered_long_pct/covered_short_pct of venue open interest) grows with time — a real limitation an agent must caveat. It also summarizes the payload (long/short notional per bin, cumulative curves, largest positions), which no output schema exists to convey.

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 and dense — routing and the "not a model" distinction come first, caveat second. Every sentence carries information, though the trailing range enumeration duplicates the schema and the telegraphic style ("RISK AHEAD,") costs a little readability.

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 two-parameter read-only tool with no output schema, the description covers all three things an agent needs: what the bins mean, that the data is measured rather than modeled, and that coverage is partial and time-dependent. Safety profile is covered by annotations, so nothing material is missing.

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

Parameters3/5

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

Schema coverage is 100%, so both parameters are already documented, and the description's trailing "range: 12h | 1d | 3d | 7d | max" largely restates the enum in the schema. It adds no extra syntax or semantics (e.g. what 'max' implies for coverage), so baseline 3 applies.

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 ("REAL open positions on Lighter ... binned by Lighter's own liquidation price") and immediately negates the obvious misreading with "Not a model." It also delimits the venue scope (zk perp DEX; crypto, equity indices, stocks, forex, commodities), so the tool is distinguishable from the modeled LiquidationMap siblings without opening a 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 explicit routing: "Use this for Lighter; get_hl_liquidation_map for Hyperliquid; get_liquidation_map (modeled) for the CEXs." When-to-use and named alternatives are both present, with the discriminating condition (venue) spelled out.

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?