Skip to main content
Glama
Sign In

LiquidVision — Crypto Derivatives Data

by app.liquidvision
OverviewDiscussionsAdmin

get_history

Read-onlyIdempotent

[measured] Historical rows as CSV, for backtests. dataset: liquidations | funding_settlements (since 2024-09) | funding_hourly | open_interest_hourly | hl_positions (Hyperliquid whale positions with liquidation prices). start/end are ISO dates (UTC). Without a key or on the free tier only the last 24 hours are available; Pro: any 31-day window; Bot: full history. The key is read from the MCP connection's X-API-Key header, or pass api_key. limit caps rows here (max 5000); for bulk use download_url with the same 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": {
      "dataset": "<dataset>"
    },
    "name": "get_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
endNoEnd of the window, ISO date (YYYY-MM-DD) or datetime, UTC.
limitNoMaximum number of rows to return.
startNoStart of the window, ISO date (YYYY-MM-DD) or datetime, UTC.
symbolNoContract as BASEUSDT, e.g. BTCUSDT, ETHUSDT, SOLUSDT (1000PEPE and kPEPE fold to PEPEUSDT).
api_keyNoLiquidVision API key (lv_...). Omit when the key is sent as the X-API-Key header on the connection.
datasetYesDataset id: liquidations | funding_settlements | funding_hourly | open_interest_hourly | hl_positions | lighter_positions (see list_history_packages).
exchangeNoVenue id (binance, bybit, okx, bitget, hyperliquid, gate, htx, kucoin, mexc, bingx, aster, kraken, gmx) or 'all' where the tool allows it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / dataset / description
      Previous value: -"Dataset id, see list_history_packages: liquidations, funding_hourly, oi_hourly, long_short, hl_positions, ..."New value: +"Dataset id: liquidations | funding_settlements | funding_hourly | open_interest_hourly | hl_positions | lighter_positions (see list_history_packages)."
  2. Changed7 schema fields changed
    • 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 / dataset / description
      Added value: +"Dataset id, see list_history_packages: liquidations, funding_hourly, oi_hourly, long_short, hl_positions, ..."
    • addedInput schema / properties / end / description
      Added value: +"End of the window, ISO date (YYYY-MM-DD) or datetime, UTC."
    • addedInput schema / properties / exchange / description
      Added value: +"Venue id (binance, bybit, okx, bitget, hyperliquid, gate, htx, kucoin, mexc, bingx, aster, kraken, gmx) or 'all' where the tool allows it."
    • addedInput schema / properties / limit / description
      Added value: +"Maximum number of rows to return."
    • addedInput schema / properties / start / description
      Added value: +"Start of the window, ISO date (YYYY-MM-DD) or datetime, UTC."
    • addedInput schema / properties / symbol / description
      Added value: +"Contract as BASEUSDT, e.g. BTCUSDT, ETHUSDT, SOLUSDT (1000PEPE and kPEPE fold to PEPEUSDT)."
  3. Added

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, so the bar is lower, yet the description still carries real weight: CSV return shape, auth path (X-API-Key header or api_key param), tier-dependent retention windows, and the 5000-row cap. These are exactly the constraints an agent needs before calling, and none of them are restatements of the annotations.

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?

It is dense and front-loaded, with the return format and dataset list first and the tier/auth details after. The telegraphic style (pipes, '(since 2024-09)') is efficient but slightly clipped, and the trailing download_url clause is the one piece that would benefit from being flagged earlier.

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 7-parameter, no-output-schema tool, the description supplies the missing return format (CSV), the access tiers, and the row cap, which covers most of what the schema cannot. The only gap is the exchange parameter's venue-scoping behavior, which is left entirely to the schema text.

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 baseline is 3; the description earns an extra point by adding meaning the schema lacks — funding_settlements being available only since 2024-09, what hl_positions actually contains (whale positions with liquidation prices), and the hard 5000 limit cap. It does not explain the exchange param's 'all' behavior beyond what the schema says.

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 states a specific verb+resource ('Historical rows as CSV, for backtests') and enumerates the dataset ids that scope it, including what hl_positions means. It stops short of naming near-neighbor siblings like get_liquidations or get_funding_history, so an agent must infer that this is the bulk/backtest path rather than the live feed.

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?

It gives concrete routing guidance: 'for bulk use download_url with the same key' versus capping rows here, and it spells out the tier conditions (free/no key = 24h only, Pro = any 31-day window, Bot = full history). What's missing is an explicit when-not against the many per-metric history siblings, but the bulk-vs-paged distinction is clear.

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 toolsInspect
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