Skip to main content
Glama
Sign In

Vike Data API

by io.vike
OverviewDiscussionsAdmin

Hyperliquid Wallet Trades

hl_wallet_trades
Read-onlyIdempotent

One Hyperliquid wallet's CLOSED round-trip trades, newest close first, keyset-paged: per trade the symbol, direction, open_ts / close_ts, entry and exit price, the largest size held (max_size_usd), traded volume_usd, realized_pnl and total_fee in USD and the fill count. A trade still open is not listed. For statistics over these trades use hl_wallet view=trades_summary; for the raw fills hl_wallet_activity view=fills. Same data as GET /v1/hyperliquid/wallets/{address}/trades.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "address": "<address>"
    },
    "name": "hl_wallet_trades"
  }
}

Input Schema

NameRequiredDescriptionDefault
endNoISO-8601 UTC upper bound, e.g. 2026-10-02T00:00:00Z. Bounds the close time.
limitNoTrades per page, newest close first. Max 5000.
startNoISO-8601 UTC lower bound, e.g. 2026-10-01T00:00:00Z. Bounds the close time.
cursorNo`nextCursor` from the previous page, passed back verbatim; it is null on the last page. Omit it for the first page.
symbolNoHyperliquid instrument ticker, e.g. BTC, ETH, HYPE; a HIP-3 market is `dex:TICKER`, e.g. xyz:TSLA. Omit for all symbols.
addressYesHyperliquid wallet address: 0x followed by 40 hex characters, any case.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/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 goes beyond them: newest-close-first ordering, keyset pagination, exclusion of open trades, and the meaning of max_size_usd as peak size held. It stops short of operational details like rate limits or behavior for unknown addresses, which keeps it off a 5.

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?

Two sentences, front-loaded with the resource and its defining constraint, then the field list, then the alternative routing. Every clause carries information; nothing repeats the title.

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?

No output schema exists, and the description compensates by naming every returned field (symbol, direction, timestamps, prices, max_size_usd, volume_usd, realized_pnl, total_fee, fill count). Combined with paging and exclusion rules, an agent has everything needed to call and interpret this tool correctly.

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

Parameters3/5

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

Schema coverage is 100% and each parameter already carries a precise description (ISO bounds, cursor semantics, HIP-3 symbol format), so the baseline is 3. The description adds only the paging order and the fact that bounds apply to close time, both of which are 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 verb and resource ('CLOSED round-trip trades' for 'one Hyperliquid wallet') with an explicit scope boundary ('A trade still open is not listed'). The field enumeration and the named sibling alternatives make it trivially distinguishable from hl_wallet_activity and hl_wallet.

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?

Explicitly routes the agent elsewhere with conditions: 'For statistics over these trades use hl_wallet view=trades_summary; for the raw fills hl_wallet_activity view=fills.' It also states the inverse case (only closed trades here), which is the key when-not-to-use signal.

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 toolsInspect
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.

Resources