Vike Data API

Hyperliquid Wallet Activity

hl_wallet_activity

Read-onlyIdempotent

A Hyperliquid wallet's event history, by view. fills: raw fills, newest first (size_usd, closed_pnl in USD; fee is in its own fee_token). funding: funding payments, payment_usd signed from the wallet's side (negative = the wallet PAID). ledger: deposits, withdrawals, transfers and vault events with amount_usd. builders: the builder codes the wallet's flow is routed through, by volume (share_of_volume is of its builder-routed volume only, not of all its trading). Keyset-paged: pass nextCursor back; it is null on the last page. Same data as GET /v1/hyperliquid/wallets/{address}/{fills, funding, ledger, builders}.

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

Input Schema

Name	Required	Description	Default
`end`	No	ISO-8601 UTC upper bound, e.g. 2026-10-02T00:00:00Z. Used by view: fills, funding, ledger.
`side`	No	`buy` or `sell`. Omit for both. Used by view: fills.
`view`	No	What to read. `fills`: raw fills, newest first. `funding`: funding paid and received, newest first. `ledger`: deposits, withdrawals, transfers and vault events, newest first. `builders`: which builder codes the wallet's flow is routed through, by volume. Default `fills`.	fills
`limit`	No	Rows per page, newest first. Default by view: fills 100, funding 100, ledger 100, builders 50. Max by view: fills 5000, funding 5000, ledger 5000, builders 500.
`start`	No	ISO-8601 UTC lower bound, e.g. 2026-10-01T00:00:00Z. Used by view: fills, funding, ledger.
`cursor`	No	`nextCursor` from the previous page, passed back verbatim; it is null on the last page. Omit it for the first page.
`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. Used by view: fills, funding.
`window`	No	Window of the builder-routed flow: `1d`, `7d`, `30d` or `all`. Used by view: builders.	all
`address`	No	Hyperliquid wallet address: 0x followed by 40 hex characters, any case. Required.
`event_type`	No	One ledger event type; an unknown value is refused, not answered with an empty list. Used by view: ledger.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 25, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive, but the description adds genuinely non-obvious behavior: newest-first ordering on every view, keyset pagination with null-terminated cursors, signed `payment_usd` semantics (negative = wallet paid), `fee` denominated in its own `fee_token`, and `share_of_volume` scoped only to builder-routed volume rather than total trading.

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?

The view-by-view enumeration is front-loaded and each sentence carries distinct information; nothing is padding. It is dense to the point of being telegraphic with heavy backtick use, which slightly taxes readability but not comprehension.

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 ten parameters, four enums, no output schema, and no required fields, the description supplies the missing connective tissue: paging protocol, ordering guarantees, per-view field caveats, and endpoint equivalents. An agent could call this correctly and interpret the rows without further documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description contributes semantics the schema cannot: the sign convention on funding payments, the fee-token caveat, and the denominator caveat on `share_of_volume`. Those are the exact misinterpretations an agent would otherwise make when reading results.

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 first clause names the resource precisely ('A Hyperliquid wallet's event history, by `view`') and the description then enumerates each of the four views with their contents. The final sentence maps each view to its concrete REST endpoint, leaving no ambiguity about what is returned.

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 `view` breakdown tells an agent exactly which mode to pick for fills vs funding vs ledger vs builder routing, and the keyset-paging instruction ('pass `nextCursor` back; it is null on the last page') gives clear operational context. It stops short of naming alternatives such as hl_wallet or wallet_transactions, so sibling routing is left to inference.

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.