Skip to main content
Glama
Sign In

Vike Data API

by io.vike
OverviewDiscussionsAdmin

Hyperliquid Stats

hl_stats
Read-onlyIdempotent

Hyperliquid venue-wide hourly series, newest hour first, by view. ecosystem: perp equity, open interest and position counts per hour. volume: traded perp notional per hour, of the whole venue (builder-DEX perps included; spot and outcome markets left out) or of one symbol: volume counts each trade ONCE (one side), the figure the candles report, while n_fills counts fill records, two per trade. Money is USD. Keyset-paged with cursor. Same data as GET /v1/hyperliquid/stats and /stats/volume.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "hl_stats"
  }
}

Input Schema

NameRequiredDescriptionDefault
endNoISO-8601 UTC upper bound, e.g. 2026-10-02T00:00:00Z.
viewNoWhat to read. `ecosystem`: hourly venue-wide perp equity, open interest and position counts, newest first. `volume`: hourly perp volume of the whole venue or one symbol, newest first. Default `ecosystem`.ecosystem
limitNoHourly rows per page, newest first. Max 5000.
startNoISO-8601 UTC lower bound, e.g. 2026-10-01T00:00:00Z.
cursorNo`nextCursor` from the previous page, passed back verbatim; it is null on the last page. Omit it for the first page.
symbolNoHyperliquid instrument ticker, e.g. BTC, ETH, HYPE; a HIP-3 market is `dex:TICKER`, e.g. xyz:TSLA. `volume` only; omit for the whole venue (perps, builder-DEX perps included; spot and outcome markets are left out). Used by view: volume.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already carry readOnly/idempotent/non-destructive/closed-world, so the bar is lower, yet the description adds real context: newest-hour-first ordering, keyset pagination with `cursor`, USD units, and the crucial volume-vs-n_fills double-counting distinction. Return shape is only loosely described, which keeps it at 4 rather than 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?

Dense but front-loaded with the resource and view split, and every clause (units, ordering, pagination, volume-vs-fills) adds information. It's a single long paragraph; light structural breaks would improve scannability, but there is no filler.

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?

With no output schema, the description must convey return shape, and it does: hourly rows, newest first, USD, keyset-paged. Combined with a fully documented schema this is nearly complete; only the exact fields per view are left implicit.

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, but the description adds semantics beyond the schema, notably that `volume` counts each trade once while `n_fills` counts two records per trade and that spot/outcome markets are excluded. It does not clarify start/end/limit interplay further, so it stays just above baseline.

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?

States a specific resource (venue-wide hourly series, newest first) and splits it clearly into `ecosystem` vs `volume` views, and ties it to the underlying REST endpoints. It's clear what the tool does, but it never names the overlapping siblings (hl_ohlcv, perp_open_interest) that also serve hourly/position data, so the agent must infer boundaries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the view descriptions and the `symbol` note ('volume only; omit for the whole venue'), and paging via `cursor` is explained. There is no explicit when-to-use-this-vs-alternatives guidance against hl_ohlcv or perp_open_interest, leaving routing to inference.

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

All Vike Data API 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