Vike Data API

Hyperliquid Twaps

hl_twaps

Read-onlyIdempotent

Hyperliquid TWAP orders, one row per status line, newest first. A line is a status CHANGE (activated, waitingForTrigger, then finished, terminated or stopped), not a slice fill: executed_size and executed_notional_usd are the cumulative totals when the line was written. Rejected placements (error) are hidden unless status=error. Across all wallets the window defaults to the last 24 hours and is at most 31 days; with wallet or twap_id neither applies. order=asc follows the feed: pass each nextCursor back and stop on an empty page. Same data as GET /v1/hyperliquid/twaps; with wallet it is GET /v1/hyperliquid/wallets/{address}/twaps (one feed: the cursors are interchangeable).

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

Input Schema

Name	Required	Description	Default
`end`	No	ISO-8601 UTC upper bound. Default: now. A window wider than 31 days is refused unless `wallet` or `twap_id` is given.
`limit`	No	Rows per page. Max 5000.
`order`	No	`desc` (default, newest first) or `asc`, oldest first: the mode for FOLLOWING the feed. Pass each `nextCursor` back verbatim and stop on an EMPTY page, not on a null cursor (an `asc` page with rows always carries one). A row written late with an older key is not seen by a poller already past it: re-read a small overlap with `start`.	desc
`start`	No	ISO-8601 UTC lower bound. Default: the 24 hours before `end`, unless `wallet` or `twap_id` is given.
`cursor`	No	`nextCursor` from the previous page, verbatim. It pins the call that returned it: send the same `order`, filters, `start` and `end` again, or the call is refused.
`status`	No	One status. Default: every status except `error` (a rejected placement, not an order); `error` shows those rows.
`symbol`	No	Hyperliquid instrument ticker, e.g. BTC, ETH, HYPE; a HIP-3 market is `dex:TICKER`, e.g. xyz:TSLA. Omit for all symbols.
`wallet`	No	One wallet, 0x followed by 40 hex characters, any case. With it (or `twap_id`) there is no default window and no 31-day cap.
`twap_id`	No	One TWAP id: every status line of that TWAP. 0 (the default) = every TWAP. Max 9007199254740991.

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?

Annotations already cover the read-only/idempotent/non-destructive profile, and the description layers on substantive behavior: cumulative (not per-line) `executed_size`/`executed_notional_usd`, error rows suppressed by default, window refusal rules, cursor pinning constraints, and the late-write/overlap caveat for pollers. It also discloses that the two endpoints share one feed with interchangeable cursors — context no annotation or schema field provides.

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: row semantics first, then filtering exceptions, then pagination protocol. Every sentence carries operational information, though the API endpoint mapping in the trailing sentence is lower value and the text is packed tightly enough to be slightly hard to scan.

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 no output schema, the description carries the burden of describing what a result row means, and it does: status-line granularity, cumulative execution fields, error-row visibility, pagination termination, and default window boundaries. An agent can call this correctly and interpret pages without further documentation.

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; the description goes beyond it only in places, notably how `wallet`/`twap_id` lift the default window and 31-day cap, and how `order=asc` pairs with `nextCursor` replay. Much of the cursor and late-write wording is duplicated from the schema's own parameter descriptions, which caps the credit.

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?

Opens with a specific verb+resource ('Hyperliquid TWAP orders') and immediately defines the row granularity ('one row per status line, newest first'), which is exactly what distinguishes it from an order/fill feed like hl_orders. The explicit contrast that a line is a status CHANGE, not a slice fill, removes the single most likely misread of the tool.

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?

Gives clear conditional guidance: default 24h window and 31-day cap apply across all wallets, but 'with `wallet` or `twap_id` neither applies', and rejected placements are hidden unless `status=error`. It also prescribes the follow-the-feed procedure (`order=asc`, pass `nextCursor` back, stop on an empty page). It stops short of naming sibling tools or saying when to prefer this over hl_orders/hl_wallet_activity.

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.