Skip to main content
Glama

Hyperliquid Account History

hyperliquid_account_history
Read-onlyIdempotent

Account value and PnL history for one Hyperliquid wallet address over a day, week, month or all time -- starting and ending account value, PnL change, trading volume, then a downsampled series. Scope "combined" is perp plus spot; "perp" is perp only. Public on-chain data, keyless. e.g. {address:"0x31dea2516beee92135b96f464eeec3cf292a13f2", period:"week"}.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "period": "week",
      "address": "0x31dea2516beee92135b96f464eeec3cf292a13f2"
    },
    "name": "hyperliquid_account_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
scopeNo"combined" (default) = perp + spot; "perp" = perp only.
periodNoWindow (default "week").
addressYes0x-prefixed 42-character wallet address.

Output Schema

NameRequiredDescriptionDefault
noteNo
foundNo
scopeNo
periodNo
seriesNo
sourceNo
addressNo
window_endNo
points_totalNo
window_startNo
pnl_change_usdNo
trading_volume_usdNo
end_account_value_usdNo
start_account_value_usdNo
account_value_change_usdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world. The description adds value beyond them by disclosing that the data is public on-chain and keyless (no credentials), and that the returned series is downsampled rather than raw granular points — a meaningful expectation-setter about output fidelity.

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?

Front-loads the resource and time windows, then scope semantics, then the keyless/public caveat. Four dense sentences with little waste, though the full 42-character address in the example is heavier than needed to convey the call shape.

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?

Given an output schema exists, return values need not be spelled out — yet the description still previews the response shape. Between annotations, the description and the schema, an agent has everything needed: address format, period and scope semantics, auth posture, and data fidelity.

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 both enums are self-documented in the schema, so the description's restatement of combined/perp and the day/week/month/allTime window adds little beyond it. The worked example with a real address and period is mildly useful but does not extend parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and scope: 'Account value and PnL history for one Hyperliquid wallet address' over defined periods, and enumerates what comes back (start/end value, PnL change, volume, downsampled series). It implicitly separates itself from hyperliquid_account_state by being explicitly historical, though it never names that sibling.

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 context for invocation: one wallet at a time, period choices, combined vs perp scope, and confirms the data is public and keyless (so no auth setup needed). It omits any explicit 'use this instead of X' routing against hyperliquid_account_state or hyperliquid_spot_balances.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.