Vike Data API

Hyperliquid Orders

hl_orders

Read-onlyIdempotent

Hyperliquid standing orders, by view. open: every order resting at one instant (at, default the newest snapshot) for a symbol and/or a wallet, in key order, with snapshotTs and source: l4_5m = the node's 5-minute order snapshot (from 2026-10-23 21:45 UTC), state_12m = rebuilt from the ~12-minute checkpoints (from 2026-07-29; before the 5-minute feed, or while it is stalled), where short-lived orders can be missing. wallet: what became of one wallet's orders in a window, newest placement first: each order seen resting or filled in it, its fills in the window and a status (open, filled, partially_filled, canceled_or_expired); notes says what a snapshot cannot tell. clusters: one symbol's standing orders within range_pct of the mid of the best resting bid and ask, bucketed by price (bids and asks by limit price, take-profit and stop-loss by trigger price; trailing stops are not bucketed), optionally one cohort's. Same data as GET /v1/hyperliquid/orders, /wallets/{address}/orders and /symbols/{symbol}/order-clusters.

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

Input Schema

Name	Required	Description	Default
`at`	No	ISO-8601 UTC instant, floored to 5 minutes. Default: the newest snapshot; not before 2026-07-29, not in the future. An `at` with no complete 5-minute snapshot is rebuilt from the sightings around it, so short-lived orders can be missing. Used by view: open, clusters.
`to`	No	ISO-8601 UTC end of the window. Default: the newest order snapshot. At most 30 days after `from`. Used by view: wallet.
`oid`	No	One order id. 0 (the default) = every order. Used by view: open.
`from`	No	ISO-8601 UTC start of the window. Default: 7 days before `to`. Used by view: wallet.
`view`	No	What to read. `open`: the orders resting at one instant for a symbol and/or a wallet. `wallet`: what became of one wallet's orders in a window (open, filled, canceled), newest first. `clusters`: one symbol's standing orders bucketed by price around the mid. Default `open`.	open
`limit`	No	Rows per page. Max 1000. Used by view: open, wallet.
`cohort`	No	One label on `axis`, spelled exactly as `hl_segments` view=cohorts lists it, e.g. `whale` (size) or `3x smart` (pnl). Only that cohort's orders, by CURRENT labels, so it is refused with `at`. Used by view: clusters.
`cursor`	No	`nextCursor` from the previous page, passed back verbatim; it is null on the last page. Omit it for the first page. On `open` it pins the snapshot of the first page. Used by view: open, wallet.
`status`	No	`open`, `filled`, `partially_filled` or `canceled_or_expired`. Omit for every status. Used by view: wallet.
`symbol`	No	Hyperliquid instrument ticker, e.g. BTC, ETH, HYPE; a HIP-3 market is `dex:TICKER`, e.g. xyz:TSLA. On `open`, `symbol` and/or `wallet` is required: an unfiltered snapshot is the whole book. Required by view: clusters.
`wallet`	No	`open`: one wallet's resting orders, 0x followed by 40 hex characters. Used by view: open.
`address`	No	Hyperliquid wallet address: 0x followed by 40 hex characters, any case. Used by view: wallet. Required by view: wallet.
`step_bps`	No	Bucket width in basis points of the reference price, at least 1. Max 500. Used by view: clusters.
`range_pct`	No	Half-width of the price range around the mid, in percent, at least 1. Max 50. Used by view: clusters.
`created_to`	No	ISO-8601 UTC: only orders placed at or before this. Used by view: open.
`order_type`	No	One order type; an unknown value is refused. Used by view: open.
`cohort_axis`	No	The ladder `cohort` is read on: `size`, `pnl` or `pnl_abs`. Default `size`. Used by view: clusters.
`created_from`	No	ISO-8601 UTC: only orders placed at or after this. Used by view: open.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses real behavioral caveats: `l4_5m` vs `state_12m` sources with different fidelity (short-lived orders can be missing), the rebuild behavior for incomplete snapshots, cursor pinning the snapshot on `open`, and cohort being refused together with `at`. It also names return fields (snapshotTs, source, status, notes).

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 taxonomy, then per-view behavior; nearly every sentence carries non-obvious information. It is dense and long-winded in places (repeated restatement of view names), but no sentence is filler.

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?

With 18 optional parameters, no output schema, and a single tool multiplexing three endpoints, the description covers what annotations and schema cannot: mode selection, data provenance and staleness, required-filter constraints ('symbol and/or wallet is required' on open), and pagination semantics. Nothing essential for correct invocation is 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%, but the description still adds value by mapping parameters to views (at/symbol/wallet/oid/limit/cursor for `open`; from/to/address/status for `wallet`; range_pct/step_bps/cohort for `clusters`) and by stating that cohort uses CURRENT labels. It also notes the equivalence to three REST endpoints, clarifying the multiplexing.

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?

The description opens with a specific verb and resource ('Hyperliquid standing orders') and then defines each of the three `view` modes (`open`, `wallet`, `clusters`) with distinct scope and return content. An agent can distinguish this from hl_wallet_trades, hl_ledger or hl_segments without opening any schema.

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?

Each view is given a clear 'what to read' condition (a resting instant vs. one wallet's outcome over a window vs. price bucketing around the mid), which effectively routes the agent. It also points to `hl_segments` view=cohorts for cohort label spelling. It stops short of explicit 'use X instead of Y' sibling exclusions, but the view selector does most of the routing work.

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.