Vike Data API

Hyperliquid Ledger

hl_ledger

Read-onlyIdempotent

Hyperliquid deposits, withdrawals, transfers and vault events ACROSS wallets, newest first, with wallet and amount_usd (USD) on every row; min_usd keeps the large ones (most events are small transfers). A transfer between two wallets is one row per affected wallet with the same hash. Without wallet the window defaults to the last 24 hours and is at most 31 days. order=asc follows the feed: pass each nextCursor back and stop on an empty page. One wallet's own ledger is also hl_wallet_activity view=ledger. Same data as GET /v1/hyperliquid/ledger.

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

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` 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`. A page can hold fewer than `limit` rows and still carry a cursor (duplicates are dropped after the read).	desc
`start`	No	ISO-8601 UTC lower bound. Default: the 24 hours before `end`, unless `wallet` 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.
`wallet`	No	One wallet, 0x followed by 40 hex characters, any case. With it there is no default window and no 31-day cap.
`min_usd`	No	Smallest absolute `amount_usd`, 0 or more. Default 0: no floor.
`event_type`	No	One ledger event type; an unknown value is refused, not answered with an empty list.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context: default 24h window with a 31-day cap that `wallet` removes, one row per affected wallet sharing a `hash` for inter-wallet transfers, cursor pinning that rejects mismatched filters, and refusal (not empty list) on unknown event types. Minor gap: it does not say anything about rate limits or response envelope shape beyond row fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the resource, scope, and ordering in the first clause, then adds constraints and the sibling pointer in descending priority. Semicolon-clause packing keeps it dense with no filler sentences; every clause carries a distinct call-time fact.

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 8 optional params and no output schema, the description fills the gap by naming the row fields (`wallet`, `amount_usd`, `hash`) and the pagination contract. Together with a fully documented schema and clear annotations, an agent has everything needed to call this correctly.

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, but the description adds rationale the schema lacks: why `min_usd` exists (most events are small transfers), what `wallet` changes about the window and cap, and how `order`/`cursor`/`start` interact when polling. Not a 5 because the numeric/format details (ISO-8601, max 5000, 0x address shape) are all already in the schema.

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?

States a specific resource (Hyperliquid deposits, withdrawals, transfers, vault events) with an explicit scope qualifier ('ACROSS wallets') and ordering ('newest first'). It also names the sibling that covers the single-wallet case (hl_wallet_activity view=ledger), so an agent can pick between them without reading schemas.

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

Usage Guidelines5/5

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

Explicit routing rules: use hl_wallet_activity for one wallet's ledger, pass `wallet` to lift the 24-hour default and the 31-day cap, use `min_usd` to keep large events, use `order=asc` with `nextCursor` to follow the feed. It even states when to stop (empty page, not null cursor) and how to handle late writes.

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.