market_historical_oi and market_recent_candles are Pro; the archetype tools are split between Starter and Pro. Check the tier matrix for the endpoint a tool wraps rather than inferring from its name.
Every tool reads from a public API endpoint, so the API reference is where the response fields live. The inputs are not always the endpoint’s: as of connector v0.13.7 eight tools accept shaping parameters the route itself does not take — see Connector-side parameters. As of v0.12.0 the catalog includes the L4 order book: four book_* tools answering a question each, rather than handing you a raw book to parse. v0.11.0 added builder analytics: eleven builder_* tools covering the leaderboard, per-builder profiles, attributed traders and fills, cohort composition, retention, audience overlap, user lifecycle, journey economics and order intent, plus the inverse per-wallet view.
Builder analytics (v0.11.0)
All eight carry the attribution caveat in their responses (
dataNotes): trigger-order (stop/TP) fills attribute at ledger level only until the parser upgrade completes, so attributed detail slightly undercounts exact ledger revenue.
Discovery & taxonomy
Pulse — trader & cohort analytics
Pulse — single trader
Pulse — cohorts
Pulse — position lifecycles
Every position reconstructed open→close from on-chain fills, with MAE/MFE. See Position lifecycles.Pulse — execution quality (MAE/MFE) · Pro
Pulse — trader archetypes
Pulse — market structure
Pulse — refreshed cohorts (30-day rolling tier)
Cohorts labelled by last-30-day tier (pnl_tier_recent / size_tier_recent) — who’s printing right now, not all-time.
Live — real-time market + risk
Market — direct Hyperliquid passthrough
Entity resolution — owner-level intelligence · Pro new in 0.9
Hyperliquid traders run named sub-accounts that trade independently — per-wallet views undercount every multi-account trader. These tools resolve wallets to their owner entity and aggregate across the whole family.Exchange aggregates new in 0.9
Plans & limits new in 0.9
HIP-4 — outcome contracts
L4 order book (v0.12.0)
Four tools over the order-level book — every resting order with the wallet behind it — each shaped around a question rather than returning a book to parse yourself. All four are Pro.
The wallet addresses join to the trader tools.
book_whales returns addresses that go straight into pulse_trader_profile or pulse_trader_performance — so “who is holding up this bid, and are they any good” is one follow-up call, not a research project.
Bounds: book_stop_map takes within_pct 1–10 (default 10), book_whales takes limit 1–50 (default 20), book_levels takes depth 1–100 (default 50). All three are integers — a fraction is rejected before a request is made.
Snapshot-derived, latest-only. The gateway re-exports the node’s full L4 book on a fixed cadence and the rollups are recomputed per coin, so there is no history — one row per coin, replaced each time its block height advances. Every response carries
as_of_height (the L1 block the answer is true at) and age_s; check age_s before citing a number. Past the staleness ceiling the routes answer 503 rather than serving a stale book. For the aggregated L2 view with no tier gate, use market_orderbook.data_coverage reports a book dataset with coins covered, the latest height and its freshness.l4Book websocket feed.
Connector-side parameters
Eight tools return payloads too large to hand an agent whole, so shaping parameters were added to them — five in v0.13.0, three more by v0.13.7. These are applied by the connector after it fetches the endpoint — the routes themselves take none of them, and you will not find them in the API reference or the OpenAPI spec. Calling the endpoint directly returns the full payload.
Parenthesised numbers are the default and the maximum. Every capped response carries
totalCount, truncated and a note naming the next offset, so an agent can page without guessing.
Around twenty other tools also take limit and offset, and those are passed straight through to the route, which pages for itself. The distinction only matters if you are calling the REST API directly: for the eight above, the parameter names in this table do not exist on the endpoint.
Every tool accepts a
useToonFormat flag (default true) that returns data in compact TOON format — about 50% fewer tokens than JSON for tabular data. Agents typically want this on; set to false if you need standard JSON.