LiquidVision — Crypto Derivatives Data

create_alert

Subscribe an HTTPS URL to push alerts instead of polling (Pro: 3, Bot: 20 subscriptions). type='condition': YOUR OWN trigger on one symbol — fires when metric op threshold becomes true (edge-triggered: once per crossing, again only after it was false). metric = funding_apr_pct (median annualised funding across venues) | oi_chg_1h_pct | oi_chg_24h_pct (Binance+Bybit+OKX, in coins) | liq_1h_usd | liq_24h_usd | price_chg_1h_pct | price_chg_24h_pct (Binance mark) | long_pct (mean long share of accounts) — the SAME definitions test_rule backtests, so test a rule first and alert on it after; op = gt | lt. Example: symbol='BTC', metric='funding_apr_pct', op='gt', threshold=50. The payload carries the value, the threshold and every other metric as context. Checked every 60 s. type='position': YOUR OWN position (symbol, side, entry, leverage, notional_usd, venue) — fires when it is within max_dist_pct of its liquidation price, computed every 60 s from the venue's maintenance-margin tier and the live mark (same numbers as check_position); again only when it gets a whole percent closer. type='cascade': a liquidation cascade just ended, over min_usd and x_normal times the coin's normal minute. type='hl_near_liq': a Hyperliquid whale position over min_usd within max_dist_pct of its liquidation price. type='cluster_sweep': price reached one of the 10 largest modeled liquidation-map clusters (size over min_usd; no symbol = BTC, ETH, SOL), sent 3 min later with modeled vs actually liquidated USD. Returns the signing secret ONCE: verify header X-LiquidVision-Signature = hex HMAC-SHA256(secret, raw body). Needs a Pro or Bot key.

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": {
      "type": "<type>",
      "url": "<url>"
    },
    "name": "create_alert"
  }
}

Input Schema

Name	Required	Description
`op`	No	Comparison: gt (greater than) \| lt (less than).
`url`	Yes	HTTPS endpoint that will receive the POST deliveries.
`side`	No	type=position: long \| short.
`type`	Yes	Type id, one of the values listed in the description.
`entry`	No	type=position: entry price (USDT).
`venue`	No	type=position: venue whose margin tiers and mark to use (default binance).
`metric`	No	Condition metric: funding_apr_pct \| oi_chg_1h_pct \| oi_chg_24h_pct \| liq_1h_usd \| price_chg_1h_pct \| long_pct.
`symbol`	No	Contract as BASEUSDT, e.g. BTCUSDT, ETHUSDT, SOLUSDT (1000PEPE and kPEPE fold to PEPEUSDT).
`api_key`	No	LiquidVision API key (lv_...). Omit when the key is sent as the X-API-Key header on the connection.
`min_usd`	No	Only rows at or above this notional in USD.
`leverage`	No	type=position: leverage, e.g. 20.
`x_normal`	No	Minimum cascade size as a multiple of the coin's normal minute of liquidations.
`threshold`	No	Threshold the metric is compared with, in the metric's own unit (percent or USD).
`max_dist_pct`	No	Only positions whose liquidation price is within this many percent of the mark price.
`notional_usd`	No	type=position: position size in USD (default 10,000).

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 8, 2026

addedInput schema / properties / entry

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "type=position: entry price (USDT).",
+  "title": "Entry"
+}

addedInput schema / properties / leverage

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "type=position: leverage, e.g. 20.",
+  "title": "Leverage"
+}

addedInput schema / properties / notional_usd

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "type=position: position size in USD (default 10,000).",
+  "title": "Notional Usd"
+}

addedInput schema / properties / side

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "type=position: long | short.",
+  "title": "Side"
+}

addedInput schema / properties / venue

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "type=position: venue whose margin tiers and mark to use (default binance).",
+  "title": "Venue"
+}

Changed10 schema fields changedNov 6, 2026

addedInput schema / properties / api_key / description

Added value: +"LiquidVision API key (lv_...). Omit when the key is sent as the X-API-Key header on the connection."

addedInput schema / properties / max_dist_pct / description

Added value: +"Only positions whose liquidation price is within this many percent of the mark price."

addedInput schema / properties / metric / description

Added value: +"Condition metric: funding_apr_pct | oi_chg_1h_pct | oi_chg_24h_pct | liq_1h_usd | price_chg_1h_pct | long_pct."

addedInput schema / properties / min_usd / description

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

addedInput schema / properties / op / description

Added value: +"Comparison: gt (greater than) | lt (less than)."

addedInput schema / properties / symbol / description

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

addedInput schema / properties / threshold / description

Added value: +"Threshold the metric is compared with, in the metric's own unit (percent or USD)."

addedInput schema / properties / type / description

Added value: +"Type id, one of the values listed in the description."

addedInput schema / properties / url / description

Added value: +"HTTPS endpoint that will receive the POST deliveries."

addedInput schema / properties / x_normal / description

Added value: +"Minimum cascade size as a multiple of the coin's normal minute of liquidations."

Changed3 schema fields changedNov 3, 2026

addedInput schema / properties / metric

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

addedInput schema / properties / op

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

addedInput schema / properties / threshold

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Threshold"
+}

AddedSep 30, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well past the annotations by disclosing the subscription quotas (Pro 3 / Bot 20), an evaluation cadence (checked every 60 s), edge-triggered firing semantics ('once per crossing, again only after it was false'), hysteresis for position alerts ('again only when it gets a whole percent closer'), a delayed cluster_sweep delivery, and the one-time signing-secret return with the X-LiquidVision-Signature HMAC verification recipe. This is exactly the operational context an agent needs before creating a write subscription.

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 core purpose and the crucial 'Returns the signing secret ONCE' note placed last where the eye lands. The per-type enumeration earns its length, but the prose is dense and could be broken into clearer per-type blocks; a few parentheticals are packed with more detail than an agent needs to select the tool.

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

Completeness4/5

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

For a 15-parameter mutation tool with no output schema, the description covers auth, quotas, cadence, firing semantics, secret-return behavior, and verification steps, so nothing critical to correct invocation is missing. The only soft spot is that return-payload shape beyond 'carries the value, the threshold and every other metric as context' is left thin.

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; however the description meaningfully enriches the parameters by defining each metric (funding_apr_pct as median annualised funding across venues, oi_chg in coins, liq in USD, long_pct as mean long share) and by grouping parameters under each type ('symbol, side, entry, leverage, notional_usd, venue' for position) with a worked example. It does not restate api_key or the cascade knobs beyond context, but the added metric semantics clearly exceed the schema.

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?

Opens with a specific verb+resource ('Subscribe an HTTPS URL to push alerts instead of polling') and then enumerates the five alert `type` values with distinct behavior for each, so an agent knows exactly what the tool creates and how each variant differs. It is clearly distinguished from siblings like delete_alert and check_position.

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?

Gives strong cross-tool routing: 'the SAME definitions test_rule backtests, so test a rule first and alert on it after', and notes that position alerts use 'the same numbers as check_position'. It also states the auth precondition ('Needs a Pro or Bot key') and quota limits. It lacks an explicit when-not-to-use statement (e.g. versus delete_alert or in-tool polling alternatives), which keeps it off a 5.

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?