LiquidVision — Crypto Derivatives Data

get_open_interest_history

Read-onlyIdempotent

[measured] Open interest over time for one contract, one row per venue per time bucket: ts (ms), exchange, oi (coins, one side), oi_usd. Use it to see how positioning built up or unwound; for the current snapshot with shares and 1h/4h/24h changes use get_oi_board, for every contract at once get_open_interest. symbol: BASEUSDT (BTCUSDT). minutes: look-back window, 5 to 20160 (14 days); snapped to a fixed set of windows.

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_open_interest_history"
  }
}

Input Schema

Name	Required	Description	Default
`symbol`	Yes	Contract as BASEUSDT, e.g. BTCUSDT, ETHUSDT, SOLUSDT (1000PEPE and kPEPE fold to PEPEUSDT).
`minutes`	No	Look-back window in minutes.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 6, 2026

addedInput schema / properties / minutes / description
```
Added value: +"Look-back window in minutes."
```

addedInput schema / properties / symbol / description

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

First observedSep 23, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety burden is lifted. The description adds real behavioral context beyond them: units are coins on one side, ts is milliseconds, there is one row per venue per bucket, and the minutes window is silently snapped to a fixed set of windows — a quirk an agent would otherwise not anticipate. It omits pagination/row-limit behavior, keeping it from a 5.

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-loads the core purpose and return shape, then routes to alternatives, then qualifies the parameters — a sensible order with no filler sentences. It is information-dense to the point of being slightly compressed (the snapped-window note and range limits sit in a single trailing sentence), but nothing is wasted.

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?

Though an output schema exists, the description still defines the row semantics (units, one-side convention, ms timestamps) that the schema cannot convey, and it bounds the one free-form parameter. Combined with the annotations, there is nothing an agent needs to call this correctly or interpret the result.

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, but the description adds meaning the schema lacks: the valid minutes range 5–20160 (14 days) and the fact that values are snapped to discrete windows. The symbol format note (BASEUSDT) largely repeats the schema, capping it below 5.

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 ('Open interest over time for one contract') plus the exact row shape returned (ts in ms, exchange, oi in coins one side, oi_usd), and explicitly names the two sibling tools it is not (get_oi_board, get_open_interest). An agent can distinguish it from all 40+ 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 a positive use case ('see how positioning built up or unwound') and two explicit exclusion routes with their selecting conditions: get_oi_board for the current snapshot with shares and 1h/4h/24h changes, get_open_interest for every contract at once. Routing is unambiguous.

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?