Vike Data API

Hyperliquid Leaderboard

hl_leaderboard

Read-onlyIdempotent

Rank Hyperliquid wallets with the full risk set, by view. ranking: precomputed per-window metrics sorted on any of 20 keys (PnL, ROI, win rate, Calmar, profit factor, drawdown, streaks, ...), filtered by cohort and by minimum trades / win rate / volume, cursor-paged. A window is what was REALIZED in it (the trades closed in it) and a wallet needs 3 closed trades in it unless min_trades says otherwise (0 = no floor). flow_adjusted: ranks FILLS-DERIVED realized trading PnL, which excludes deposits by construction, with deposits, withdrawals and daily attribution returned beside it, both of the NATIVE perp account only (flow_unbalanced marks rows whose attributed block is off the fills; attributed and flow_unbalanced are null for a wallet now in unified or portfolio-margin mode, whose native account follows margin). account_value and roi use the wallet's whole value in those two modes, which read null on the drawdown fields; perp_account_value and account_mode show the native account and the mode. UNITS differ from hl_perp_top_traders: here win_rate and min_win_rate are FRACTIONS (0.6 = 60%), there percents; max_drawdown_pct and pnl_pct are percents, and pnl_pct is null under $1 of equity (prefer it to the raw roi); money is USD. Same data as GET /v1/hyperliquid/leaderboard and /leaderboard/flow-adjusted.

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

Input Schema

Name	Required	Description	Default
`axis`	No	Cohort ladder: `size` = account-value tiers in USD, `pnl` = percentile rank of cumulative realized PnL (NOT dollars), `pnl_abs` = dollar bands of that same PnL. Selects the ladder `cohort` filters on. Used by view: ranking.	size
`sort`	No	Ranking metric; an unknown key is refused, never replaced by a default. Used by view: ranking.	pnl
`view`	No	What to read. `ranking`: traders ranked on any of 20 metrics with the full risk set. `flow_adjusted`: traders ranked on fills-derived trading PnL, deposits reported beside it. Default `ranking`.	ranking
`limit`	No	Rows per page. Max 500.
`order`	No	`desc` (best first) or `asc`. Used by view: ranking.	desc
`cohort`	No	One label on `axis`, spelled exactly as `hl_segments` view=cohorts lists it, e.g. `whale` (size) or `3x smart` (pnl). Omit for no cohort filter. Used by view: ranking.
`cursor`	No	`nextCursor` from the previous page, passed back verbatim; it is null on the last page. Omit it for the first page. Resend the same window / sort / order / axis / cohort with it.
`window`	No	Window: `1d`, `7d`, `30d` or `all`. The trades CLOSED in the current UTC day and the 1, 7, 30 or 365 days before it: PnL, trade counts, win rates and tags are what was realized in it.	30d
`min_trades`	No	Minimum closed trades in the window. Default 3, the floor hl_perp_top_traders applies; pass 0 for no floor (view `flow_adjusted` then still needs at least one).
`min_volume`	No	Minimum total volume in USD. Used by view: ranking.
`min_win_rate`	No	Minimum win rate as a FRACTION from 0 to 1 (0.6 = 60%), compared with the `win_rate` the rows show; 60 is refused, not read as 60%. hl_perp_top_traders takes a percent instead. Max 1. Used by view: ranking.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 25, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare this a read-only, idempotent, non-destructive call, so the bar is lower, yet the description adds far more than required: window semantics are defined as realized (closed) trades, a 3-closed-trade floor is disclosed, `flow_unbalanced` and `attributed` null behavior is explained for unified/portfolio-margin wallets, and the description warns that drawdown fields read null in those modes. Unit traps (fractions vs percents, `pnl_pct` null under $1 equity) are called out explicitly, which prevents concrete misuse.

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?

Purpose is front-loaded in the first clause and almost no sentence is padding given the number of unit and null traps being flagged. The downside is that it is one dense run-on block with heavy backtick notation; grouping the unit caveats into a separate sentence or line would improve scanability without losing content.

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?

For an 11-parameter, two-mode tool with no output schema, the description covers what an agent needs to call it correctly: mode selection, pagination contract, cohort label sourcing, filtering floors, units, and null-field behavior. Return-value shape is explained exactly where it matters (flow_unbalanced, attributed, account_mode, pnl_pct), so the missing output schema is not a gap in practice.

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 baseline is 3; the description earns above that by adding cross-parameter meaning the schema doesn't carry — that `axis` selects which ladder `cohort` filters on, that `window` defines what PnL/trade counts/win rates mean, and that a cursor must be resent with the identical window/sort/order/axis/cohort set. It also clarifies the min_trades interaction for flow_adjusted (still needs at least one trade), which is absent from the individual parameter docs.

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 opening sentence states a specific verb and resource ('Rank Hyperliquid wallets') and immediately names the two modes the tool serves. The two views are then defined in distinct terms — precomputed per-window metrics vs fills-derived realized PnL — so an agent can tell hl_leaderboard apart from hl_perp_top_traders and hl_cohort_metrics without opening schemas.

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?

It gives clear selection logic between the two views (ranking for the full risk set, flow_adjusted when deposits must be excluded by construction) and points at hl_segments view=cohorts for valid cohort labels and hl_perp_top_traders as the contrasting tool for units. What's missing is an explicit 'use that tool instead when...' statement, so the alternatives are implied rather than prescribed.

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.