Vike Data API

Hyperliquid Vaults

hl_vaults

Read-onlyIdempotent

Hyperliquid vaults across the platform, by view. list: one row per vault family (HLP and its sub-vaults are one row) with current TVL, APR (our 30-day share-price return, annualised) and the window's PnL, return, net flow, volume and fills, plus leverage (gross notional / equity) and the leader's and top-5 depositors' shares; q searches by name or address. A family is measured from the first day all its open vaults are recorded (start, partial); its flows are the parent's. stats: platform TVL, deposits, withdrawals and net flow over the window, vaults created per month. flows: deposits and withdrawals of at least min_usd across all vaults, newest first. A window ends on the newest recorded day; one shorter than asked says partial. Money is USD, *_pct percentage points. Same data as GET /v1/hyperliquid/vaults, /vaults/stats and /vaults/flows.

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

Input Schema

Name	Required	Description	Default
`q`	No	Search, 2-64 characters: a case-insensitive part of the vault name, or an address prefix starting `0x` (a sub-vault's address finds its family). Used by view: list.
`sort`	No	Ranking: `tvl`, `apr`, `pnl`, `return`, `net_flow`, `volume`, `age`, `leverage` or `top5_share` (the five largest depositors' share). Used by view: list.	tvl
`type`	No	`all`, `deposit`, `withdraw`, `distribution` or `commission`. Used by view: flows.	all
`view`	No	What to read. `list`: every vault family with TVL, APR, the window's PnL, return, net flow and volume, leverage and depositor concentration; `q` searches by name or address. `stats`: platform TVL, flows over the window and vaults created per month. `flows`: deposits and withdrawals across all vaults, depositor side, newest first. Default `list`.	list
`limit`	No	Rows per page. Default by view: list 50, flows 100. Max by view: list 500, flows 1000. Used by view: list, flows.
`order`	No	`desc` or `asc`. Used by view: list.	desc
`cursor`	No	`nextCursor` from the previous page, passed back verbatim; it is null on the last page. Omit it for the first page. Used by view: list, flows.
`status`	No	`open`, `closed` or `all` vaults. Used by view: list.	open
`window`	No	Window ending on the newest recorded day: `7d`, `30d`, `90d`, `365d` or `all` (all history). Default by view: list 30d, stats 30d, flows 7d.
`min_tvl`	No	Minimum current TVL in USD. Used by view: list.
`min_usd`	No	Smallest flow in USD. Used by view: flows.
`deposits`	No	`any`, or only vaults whose deposits are `open` or `closed`. Used by view: list.	any
`smart_only`	No	Only depositors in the top 1,000 of the all-time PnL leaderboard. Used by view: flows.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 30, 2026

addedInput schema / properties / q

Added value: +{
+  "description": "Search, 2-64 characters: a case-insensitive part of the vault name, or an address prefix starting `0x` (a sub-vault's address finds its family). Used by view: list.",
+  "type": "string"
+}

changedInput schema / properties / sort / description

Previous value: -"Ranking: `tvl`, `apr`, `pnl`, `return`, `net_flow`, `volume` or `age`. Used by view: list."New value: +"Ranking: `tvl`, `apr`, `pnl`, `return`, `net_flow`, `volume`, `age`, `leverage` or `top5_share` (the five largest depositors' share). Used by view: list."

changedInput schema / properties / sort / enum

Previous value: -[
-  "tvl",
-  "apr",
-  "pnl",
-  "return",
-  "net_flow",
-  "volume",
-  "age"
-]New value: +[
+  "tvl",
+  "apr",
+  "pnl",
+  "return",
+  "net_flow",
+  "volume",
+  "age",
+  "leverage",
+  "top5_share"
+]

changedInput schema / properties / view / description

Previous value: -"What to read. `list`: every vault family with TVL, APR and the window's PnL, return, net flow and volume. `stats`: platform TVL, flows over the window and vaults created per month. `flows`: deposits and withdrawals across all vaults, depositor side, newest first. Default `list`."New value: +"What to read. `list`: every vault family with TVL, APR, the window's PnL, return, net flow and volume, leverage and depositor concentration; `q` searches by name or address. `stats`: platform TVL, flows over the window and vaults created per month. `flows`: deposits and withdrawals across all vaults, depositor side, newest first. Default `list`."

AddedOct 27, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent/non-destructive annotations: explains that HLP and sub-vaults collapse into one row, that a family is measured from the first day all its open vaults are recorded (`start`, `partial`), that flows belong to the parent, that windows end on the newest recorded day and are flagged `partial` when shorter, and that `cursor` is null on the last page.

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 view selector, then each view's contents, then cross-cutting semantics (windows, partial, units, endpoint mapping). It is a single dense block with no filler, though the view recap partially duplicates the schema's `view` description.

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 13-param, three-mode tool with no output schema, it covers aggregation rules, window/partial behavior, currency and percentage units, pagination, and REST equivalence. What is missing is shape-level return detail and any pointer to the singular `hl_vault` sibling for single-vault lookups.

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; the description earns more by defining metrics the schema does not, e.g. APR as the annualised 30-day share-price return, `leverage` as gross notional / equity, `top5_share`, and USD vs `*_pct` units. It largely restates the schema's per-view applicability, which caps it below 5.

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?

Specific verb+resource: 'Hyperliquid vaults across the platform, by `view`', with each view's payload spelled out (list = per-family TVL/APR/PnL, stats = platform aggregates, flows = deposits/withdrawals). It implies platform-wide scope versus the singular `hl_vault` sibling, but never names that sibling, so full sibling differentiation is left to inference.

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?

The three views are described in enough detail that an agent can pick between them (aggregate platform metrics -> stats, individual flow events -> flows, ranked vault families -> list), and the schema reinforces which params apply per view. It stops short of explicit when-to-use/when-not phrasing or routing to `hl_vault` for a single vault.

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