Skip to main content
Glama
Sign In

Vike Data API

by io.vike
OverviewDiscussionsAdmin

Hyperliquid Wallet

hl_wallet
Read-onlyIdempotent

One Hyperliquid wallet, by view. summary: live equity, open positions, both cohort labels, the risk metrics of the window (win_rate is a FRACTION from 0 to 1; max_drawdown_pct and pnl_pct are percents, pnl_pct is null under $1 of equity), cumulative realized PnL since inception and lifetime deposits and withdrawals, all money in USD; equity.account_value is the wallet's whole value in the venue's unified and portfolio-margin modes (native perp account + builder accounts + USDC outside them, free spot tokens left out; those modes also read null on the drawdown fields), else the native perp account; equity.perp_account_value is always the native perp account and equity.account_mode is default, unifiedAccount, portfolioMargin or disabled; open_positions.perp_bias = (long - short) / equity.perp_account_value and equity_exposure = (long + short) / it, native perp account only: positions on the main dex over the native perp account value; builder-DEX positions are not included. Unbounded ratios, null with no main-dex position or no positive equity. trades_summary: closed round-trip trade statistics overall and per symbol, medians as well as means. An address we hold nothing for (summary) or that never traded (trades_summary) is an error, never a block of zeros. Find addresses with hl_leaderboard, hl_perp_top_traders or hl_position_match. Same data as GET /v1/hyperliquid/wallets/{address} and /wallets/{address}/trades/summary.

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

Input Schema

NameRequiredDescriptionDefault
viewNoWhat to read. `summary`: equity, open positions, cohort labels, risk metrics and lifetime flow. `trades_summary`: closed-trade statistics overall and per symbol. Default `summary`.summary
windowNoWindow of the risk metrics and trade statistics, by trade time: `1d`, `7d`, `30d` or `all`.all
addressNoHyperliquid wallet address: 0x followed by 40 hex characters, any case. Required.
opened_withinNoBounds the open-positions block ONLY (equity, lifetime and metrics are wallet-level totals with nothing per-position to filter): `24h`, `7d`, `30d` or `all`. Used by view: summary.all

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior5/5

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

Annotations already establish the safe read-only profile, and the description adds substantial behavioral detail beyond them: null semantics for drawdown fields under unified/portfolio modes, pnl_pct being null under $1 equity, error behavior for unknown addresses, and formulas for perp_bias and equity_exposure.

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

Conciseness2/5

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

The description is a single dense paragraph of semicolon-separated clauses. It is information-dense but poorly structured and hard to scan, with the core purpose buried after a terse opening.

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 no output schema and a complex two-view response, the description carries the full burden and does so thoroughly: it defines fields, formulas, null conditions, scope exclusions, and error behavior.

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 schema already documents all four parameters. The description still adds meaning by expanding what each view returns and clarifying that opened_within bounds only the open-positions block, though much of the field-level detail is response semantics rather than input semantics.

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 the resource (one Hyperliquid wallet) and its two views, and names sibling tools for address discovery. However, it does not distinguish itself from close siblings such as hl_wallet_trades or hl_wallet_activity, leaving the agent to infer when this tool is the right choice.

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

Usage Guidelines3/5

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

It routes the agent to hl_leaderboard, hl_perp_top_traders, or hl_position_match for finding addresses, and the view descriptions imply when each view is used. But there is no explicit when-to-use versus when-not guidance for this tool relative to related wallet-data tools.

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