Skip to main content
Glama
hyperliquid-agent-gateway

hyperliquid-agent-gateway

hyperliquid-agent-gateway

CI PyPI PyPI downloads MCP Catalog License: MIT Python 3.11+

Hyperliquid puts about 233 perps, 326 spot pairs and a whole EVM chain in front of you, all readable through public endpoints. This MCP server does the reading for your agent: market and funding data, per-account risk, trader activity, HyperEVM (chain 999) token transfers. No keys, no signing, no writes; everything goes through api.hyperliquid.xyz/info and rpc.hyperliquid.xyz/evm, cached and rate-limited so an enthusiastic agent cannot hammer the upstream.

Use cases

The liquidation tool is the one people come for. Feed it any address and you get the margin summary, per-position leverage, and the distance to liquidation; when the venue publishes liquidationPx you get the real number, flagged as such, and when it doesn't you get an estimate that says it is one. We tested it on a $209M-notional 25x short book the day it was 17.6% from the cliff.

Funding: funding_carry_screener ranks all 233 perps from a single call and then fetches 168h of history only for the top few, because the API's weight budget (1200/min) punishes naivety. You see whether a rate is a spike or a regime.

HyperEVM transfers tie on-chain flow back to the perp markets; quote returns a book-derived mid that never leaves [bid, ask]; trader_activity dissects any address into fills, fees, win-rate, funding drag and open positions.

Full walkthroughs: examples/use-cases.md.

Related MCP server: market-depth-lab-mcp

Quickstart

Claude Code:

claude mcp add hyperliquid -- uvx hyperliquid-agent-gateway

stdio (default, for local agents):

uvx hyperliquid-agent-gateway

or from a checkout:

git clone https://github.com/alekskram/hyperliquid-agent-gateway
cd hyperliquid-agent-gateway
uv sync
uv run hyperliquid-agent-gateway

Claude Desktop / Cursor config:

{
  "mcpServers": {
    "hyperliquid": {
      "command": "uvx",
      "args": ["hyperliquid-agent-gateway"]
    }
  }
}

Hosted form, streamable HTTP on port 8903:

uvx hyperliquid-agent-gateway --http             # 127.0.0.1:8903
curl http://127.0.0.1:8903/health   # -> {"ok": true, "service": "hyperliquid-agent-gateway", ...}
[mcp_servers.hyperliquid]
command = "uvx"
args = ["hyperliquid-agent-gateway"]
# 1) start the gateway (keep it running)
uvx hyperliquid-agent-gateway --http --port 8903 &

# 2) register it (merges into ~/.zcode/cli/config.json)
python3 - <<'PY'
import json, os
p = os.path.expanduser("~/.zcode/cli/config.json")
os.makedirs(os.path.dirname(p), exist_ok=True)
cfg = json.load(open(p)) if os.path.exists(p) else {}
cfg.setdefault("mcp", {}).setdefault("servers", {})["hyperliquid"] = {
    "type": "http", "url": "http://127.0.0.1:8903/mcp"}
json.dump(cfg, open(p, "w"), indent=2)
print("hyperliquid-agent-gateway registered:", p)
PY

Tools

All 12 tools are read-only (annotated readOnlyHint: true, destructiveHint: false, openWorldHint: true).

#

Tool

Signature

What it does

1

market_overview

market_overview(limit=20, sort="open_interest")

Perp market snapshot from ONE metaAndAssetCtxs call: per-coin mark, open interest, day volume, premium, max leverage + totals. sort in {open_interest, volume, premium}.

2

spot_overview

spot_overview(limit=20)

Spot pairs from spotMeta + ctxs with HIP-1 to ERC-20 links; @{index} names resolved to readable token names.

3

quote

quote(coin)

Bid/ask/mid/spread + top-of-book sizes from l2Book. mid is the book midpoint (bid+ask)/2 when both sides exist (mid_source: "book"); allMids is only a labeled fallback when the book lacks a side (mid_source: "allMids"); mid_source: null when neither knows the coin. With both sides present mid never leaves [bid, ask]. coin is the ONLY parameter (no size/limit). Unknown coin raises with 5 examples.

4

order_book

order_book(coin, depth=10)

Book levels per side with nSigFigs aggregation and per-side total liquidity.

5

candles

candles(coin, interval="1h", limit=100)

OHLCV rows newest-first; intervals 1m/15m/1h/4h/1d/1w/1M; startTime computed from limit.

6

trades

trades(coin, limit=20)

Recent public fills WITH both sides' addresses (users: [maker, taker]).

7

funding_history

funding_history(coin, limit=100)

Hourly funding rows + premium_now from the live asset ctx.

8

liquidation_risk

liquidation_risk(address)

Per-account risk: margin summary, cross maintenance margin, per-position leverage + liquidationPx when published; when null, an explicitly flagged ESTIMATED distance from the maintenance-margin ratio. Mark px is resolved per coin from metaAndAssetCtxs (fallback allMids) because live positions carry no markPx - see mark_px_source on each row. Includes funding drag.

9

trader_activity

trader_activity(address, limit=50)

Fills PnL/fees/volume/win-rate, funding net, open positions, per-coin breakdown.

10

funding_carry_screener

funding_carry_screener(topN=10, metric="premium")

Ranks ALL perps from ONE call; fundingHistory fetched only for the topN (weight economy).

11

token_transfers

token_transfers(contract, limit=100, from_block=None)

HyperEVM ERC-20 Transfer logs via adaptive-window eth_getLogs; rows carry from/to/value/txHash/blockNumber/ts with per-token decimals + decimals_source (static map or assumed_18).

12

wallet_balance

wallet_balance(address)

Native (eth_getBalance) + up to 20 ERC-20s (eth_call balanceOf, resolved from spotMeta) + Hyperliquid spot balances; every row carries decimals/decimals_source.

Why a gateway and not the raw API?

api.hyperliquid.xyz/info is open and one POST away. The traps start after that:

Raw API gives you

You would have to build

two mid-price sources that disagree (allMids vs l2Book)

the discipline of book-derived mids that never leave [bid, ask], with labeled fallbacks

candleSnapshot whose cache key ignores nested request params

per-coin cache isolation (a naive first-coin key poisons every subsequent coin for the TTL)

OI in base units, funding as an hourly rate

unit normalization (×price), annualized carry math, a one-call screener that fetches history only for the top-N

live positions that carry no markPx

per-coin mark resolution with a mark_px_source tag on every row, plus estimated-vs-published liquidation distance flags

raw HyperEVM RPCs

adaptive-window eth_getLogs, decimals resolution with decimals_source provenance

Rate limits

Two independent, locally enforced budgets protect the upstream:

/info - 1200 weight per rolling 60s (Hyperliquid's documented weight pricing), tracked per request type:

type

weight

allMids

2

l2Book

2

meta, metaAndAssetCtxs, spotMeta, spotMetaAndAssetCtxs

20

recentTrades, clearinghouseState, userFills, userFunding, spotClearinghouseState

20

fundingHistory

20 base + extra per 20 items beyond the first

candleSnapshot

60

When the next request would exceed the budget the client waits once (<=5s) for the window to roll, then raises a clear error naming the limit - it never sleep-blocks forever.

HyperEVM RPC - 100 requests per rolling 60s (flat 1 per request), enforced separately from /info. Over-budget calls raise immediately (rpc-limit) - tools surface an honest error dict, and wallet_balance stops its ERC-20 scan at the cap.

TTL caches also dedupe repeated calls per data type: allMids 15s, recentTrades 15s, l2Book 5s, metaAndAssetCtxs 60s, spotMeta 3600s, spotMetaAndAssetCtxs 60s, candleSnapshot 300s, fundingHistory 300s, per-address account types 60s.

Data notes

  • Every numeric from the API is a STRING upstream; the gateway parses them with a never-raising helper - null always means "not available", never zero.

  • Every upstream failure returns an error dict {"error": ..., "source": ..., "reason": ...}, never a traceback; partial data degrades field-by-field with warnings[].

  • liquidation_risk never invents a liquidation price: when the venue publishes none, liq_px stays null and the distance is an explicitly flagged estimate (formula in the tool's note). Mark px is likewise never invented: live positions carry no markPx, so it is resolved from metaAndAssetCtxs (fallback allMids) and the row's mark_px_source says which; no source -> null.

  • funding_drag / funding_net: the venue's userFunding returns only NON-ZERO funding events, so a live null/empty for a fresh or quiet address is expected behaviour, not a bug.

  • ERC-20 amounts use a static decimals map for canonical HyperEVM tokens (6 for USDC/USDT-style, 18 for PURR/HYPE); unknown tokens assume 18 and every row says decimals_source: "assumed_18" - do not trust 6dp precision for unmapped tokens.

  • Cached responses carry age_seconds / fetched_at freshness fields.

Part of the suite

Four sibling read-only MCP gateways, one style: keyless, cached, honest degradation.

Gateway

Focus

dydx-agent-gateway

dYdX v4: verified trader PnL, funding/OI anomaly detectors, leaderboard

arcus-agent-gateway

194 tokenized US equities on Robinhood Chain: quotes, holders, whale transfers

hyperliquid-agent-gateway (you are here)

Hyperliquid: 233 perps + spot, funding carry, account risk, HyperEVM

aster-agent-gateway

Aster DEX: ~580 futures incl. 24/7 TradFi perps, funding caps/floors

All four are on glama.ai and PyPI; any of them installs with uvx <name>.

License

MIT.

Available Tools

12 tools
candlesCandlesA
Read-only

OHLCV candles from candleSnapshot for coin: rows newest-first, capped at limit (max 500). startTime is computed so roughly limit candles of interval are requested. Valid intervals: 1m, 15m, 1h, 4h, 1d, 1w, 1M. Example: candles(coin="BTC", interval="4h", limit=50)

Inputs: coin (required), limit, interval. Returns: object

funding_carry_screenerFunding Carry ScreenerA
Read-only

Rank ALL perps from ONE metaAndAssetCtxs call by metric (premium default; oi / volume options) and return the topN rows with premium, oi, dayVolume, markPx. fundingHistory rows are fetched ONLY for the topN coins (weight economy) and appear as 'funding_history' on rows where that call succeeded. Example: funding_carry_screener(topN=5, metric="premium")

Inputs: topN, metric. Returns: object

funding_historyFunding HistoryA
Read-only

Hourly funding history for coin (fundingHistory) plus the CURRENT premium from metaAndAssetCtxs (premium_now): rows carry fundingRate (hourly), premium, time (ms). Newest-first, capped at limit (max 500). Example: funding_history(coin="BTC", limit=48)

Inputs: coin (required), limit. Returns: object

liquidation_riskLiquidation RiskA
Read-only

KEY TOOL. Liquidation risk for one perp account (clearinghouseState + userFunding): margin summary (accountValue, totalRawUsd, totalMarginUsed, withdrawable), cross maintenance margin, per-position leverage/entry/mark/unrealizedPnl and liquidationPx when the venue provides it. Positions in the LIVE clearinghouseState response carry NO markPx: mark is resolved per coin from metaAndAssetCtxs (fallback allMids) and each row says where it came from in mark_px_source ('position' | 'metaAndAssetCtxs' | 'allMids' | null). When liquidationPx is null, liq_distance_pct is an ESTIMATE from the maintenance-margin ratio (crossMaintenanceMarginUsed / marginSummary.accountValue; isolated positions use marginUsed / positionValue) - flagged 'estimated': true, liqPx stays null (honest). funding_drag totals negative funding payments from userFunding. Address must be 0x + 40 hex. Example: liquidation_risk(address="0x...")

Inputs: address (required). Returns: object

market_overviewMarket OverviewA
Read-only

Perp market overview from ONE metaAndAssetCtxs call (~233 perps): per-coin mark, open interest, day volume, premium (funding basis), max leverage, plus totals (sum OI, sum day volume). Rows are sorted by sort in {open_interest (default), volume, premium} descending and capped at limit (max 100). Example: market_overview(limit=10)

Inputs: sort, limit. Returns: object

order_bookOrder BookA
Read-only

Aggregated order book for one coin from l2Book: depth levels per side (default 10, max 100), aggregated by the book's nSigFigs precision (default taken from the response levels), with total liquidity (sum px*sz) per side. Example: order_book(coin="ETH", depth=20)

Inputs: coin (required), depth. Returns: object

quoteQuoteA
Read-only

One coin's live quote from l2Book: bid/ask/mid/spread and top-of-book sizes. mid is the book midpoint ((bid+ask)/2) whenever both sides are present ('book'); allMids is only a labeled fallback when the book lacks a side ('allMids'), so mid never escapes the [bid, ask] range. The coin is validated against the perp universe (spot '@{index}/NAME' pairs pass through to the book). Example: quote(coin="BTC")

Inputs: coin (required). Returns: object

spot_overviewSpot OverviewA
Read-only

Spot market overview (~326 pairs) from spotMeta + spotMetaAndAssetCtxs: pair rows (name, mark, day volume, OI where published) with HIP-1 <-> ERC-20 links resolved - '@{index}' spot coin names are mapped to token names via spotMeta.tokens. Sorted by day volume descending, capped at limit (max 100). Example: spot_overview(limit=10)

Inputs: limit. Returns: object

token_transfersToken TransfersA
Read-only

Recent ERC-20 Transfer events for contract on HyperEVM via eth_getLogs with an ADAPTIVE window (starts 30 blocks, halves on too-big/failing responses, doubles on quiet ones up to 60; active tokens need ~30-60 block windows). Rows (newest-first, max 500): from, to, value (raw/1e18, 6dp), txHash, blockNumber, ts when the log carries a timestamp. from_block anchors the walk (default: latest - 300). Errors degrade to an honest error dict naming the RpcError kind (rate-limit vs window-too-wide narrative). Example: token_transfers(contract="0x...", limit=50)

Inputs: contract (required), limit, from_block. Returns: object

trader_activityTrader ActivityA
Read-only

Trading profile for one address (userFills + userFunding + clearinghouseState): total closed PnL, fees (fee + builderFee), volume, fill count, win-rate-ish share of fills with closedPnl > 0, per-coin breakdown, net funding and open positions. limit caps fills analyzed (max 500, newest-first). Example: trader_activity(address="0x...", limit=100)

Inputs: address (required), limit. Returns: object

tradesTradesA
Read-only

Recent public fills from recentTrades(coin) WITH both sides' addresses: rows (newest-first, max 500) carry side, px, sz, time, coin, hash and users [maker, taker]. Example: trades(coin="BTC", limit=10)

Inputs: coin (required), limit. Returns: object

wallet_balanceWallet BalanceA
Read-only

Wallet balances on HyperEVM + Hyperliquid spot: native balance (eth_getBalance), ERC-20 balances via eth_call balanceOf for up to 20 tokens resolved from spotMeta tokens with 0x contract addresses (cap respects the 100 req/min rpc budget), and Hyperliquid spot balances via spotClearinghouseState. Per-token rows: token, balance_raw (wei), balance (units, 6dp), source. Example: wallet_balance(address="0x...")

Inputs: address (required). Returns: object

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.4/5.0

    Scored across 12 tools

    Disambiguation5/5

    Each tool targets a distinct data category or resource: market data, funding analytics, account risk, wallet balances, and transfers all have clear owners. Even the two funding-related tools differ obviously by single-coin history versus cross-perp screening.

    Naming Consistency5/5

    All tool names are lowercase snake_case noun phrases that directly describe their output, such as funding_carry_screener, market_overview, and token_transfers. There are no mixed conventions or vague generic verbs.

    Tool Count5/5

    12 tools is well-scoped for a Hyperliquid data/risk gateway. Each tool earns its place by covering a distinct part of the domain without redundancy.

    Completeness4/5

    The read-side surface is nearly complete for an analytics-focused gateway: market data, account risk, funding, wallet balances, and transfer events are all covered. Minor gaps include no direct open-orders view and no native ETH transfer history, but these are workable and order execution appears outside the server's apparent scope.

    Maintenance

    ActivityNo data
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      C
      quality
      D
      maintenance
      A read-only Model Context Protocol server for Hyperliquid that exposes over 30 tools to query public market data and user state via the Hyperliquid Info API, without requiring a private key.
      41
      MIT
    • A
      license
      A
      quality
      C
      maintenance
      Read-only Hyperliquid and cross-exchange market research for AI agents, providing structured tools for live market data without requiring authentication.
      9
      90 npm
      MIT
    • A
      license
      Not graded
      quality
      C
      maintenance
      Enables read-only access to Hyperliquid's public market, user, vault, and staking data via 61 MCP tools, covering perpetuals, spot, and borrow-lend information.
      MIT
    • A
      license
      Not graded
      quality
      C
      maintenance
      Enables read-only access to Hyperdash market intelligence for Hyperliquid, including per-asset price changes, trader performance and positions, liquidations, open interest, news, and TWAP orders via 28 MCP tools.
      MIT