Vike Data API

Hyperliquid Builders

hl_builders

Read-onlyIdempotent

Hyperliquid builder codes (front-ends and bots that attach their address to an order and take a slice of the taker fee), by view. leaderboard: builders ranked by fee revenue, routed volume, unique users or fills over a window. stats: venue-wide builder economics. profile: one builder's totals with per-symbol and per-dex breakdowns, user-volume deciles and lifetime totals. users: the wallets routing through one builder. fills: its raw routed fills (sum fee_usd; fee is in its own fee_token). series: fee, volume, users and fills per hour or day (users is NOT additive across buckets). fee_usd is the builder's own cut, trader_fee_usd what the trader paid; every *_pct is percentage points 0-100. History depth differs by builder: compare active_days and window before comparing windows. Same data as GET /v1/hyperliquid/builders and its sub-routes.

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

Input Schema

Name	Required	Description	Default
`end`	No	ISO-8601 UTC upper bound, e.g. 2026-10-02T00:00:00Z. Used by view: fills, series.
`side`	No	`buy` or `sell`. Omit for both. Used by view: fills.
`sort`	No	`leaderboard`: `fee` (the builder's own cut), `volume`, `users` or `fills`. `users`: `volume`, `fees` or `pnl` (the TRADERS' signed realized PnL, not the builder's). Default by view: leaderboard fee, users volume. Used by view: leaderboard, users.
`view`	No	What to read. `leaderboard`: builders ranked by fee revenue, volume, users or fills. `stats`: venue-wide builder-code economics. `profile`: one builder's totals with per-symbol and per-dex breakdowns. `users`: the wallets routing through one builder, ranked. `fills`: one builder's raw routed fills, newest first. `series`: one builder's fee, volume, users and fills per hour or day. Default `leaderboard`.	leaderboard
`limit`	No	Rows per page. Default by view: leaderboard 50, users 100, fills 100, series 500. Max by view: leaderboard 500, users 1000, fills 5000, series 2000. Used by view: leaderboard, users, fills, series.
`order`	No	`desc` or `asc`. Used by view: leaderboard, users.	desc
`start`	No	ISO-8601 UTC lower bound, e.g. 2026-10-01T00:00:00Z. Used by view: fills, series.
`bucket`	No	Bucket width: `1h` or `1d`. Used by view: series.	1d
`cursor`	No	`nextCursor` from the previous page, passed back verbatim; it is null on the last page. Omit it for the first page. Used by view: leaderboard, users, fills, series.
`symbol`	No	Hyperliquid instrument ticker, e.g. BTC, ETH, HYPE; a HIP-3 market is `dex:TICKER`, e.g. xyz:TSLA. Omit for all symbols. Used by view: fills.
`window`	No	Window: `1d`, `7d`, `30d` or `all`. Used by view: leaderboard, stats, profile, users.	30d
`builder`	No	Builder address: 0x followed by 40 hex characters. Used by view: profile, users, fills, series. Required by view: profile, users, fills, series.
`breakdown_limit`	No	Rows per breakdown (per-symbol and per-dex). Max 1000. Used by view: profile.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 25, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare read-only/idempotent, and the description adds substantial non-obvious context: fee_usd is the builder's cut vs trader_fee_usd paid by trader, *_pct are percentage points 0-100, and users is NOT additive across buckets. The history-depth warning (active_days/window differ per builder) is exactly the kind of caveat structured fields cannot convey.

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 core definition then enumerates views in one dense, information-rich sentence, with units and caveats trailing. Effective, though the parenthetical packing and run-on enumeration make it heavier than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter, multi-view tool with no output schema, the description covers view selection, key field meanings, additivity caveats and pagination cursor semantics (via schema). Minor gaps: no mention of what stats/profile return shapes look like beyond field names, but overall sufficient to call correctly.

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 still adds meaning beyond the schema by clarifying sort semantics (users' pnl is the TRADERS' realized PnL, not the builder's) and the fee/side/currency handling for fills. It does not restate every parameter, but the crucial ambiguities are resolved.

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 resource (Hyperliquid builder codes) and verb-like framing ('by view') followed by per-view semantics that let an agent distinguish leaderboard vs stats vs profile vs users vs fills vs series without opening the schema. The parenthetical defining what a builder code is adds precise scope.

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 per-view routing guidance ('leaderboard': builders ranked by fee revenue; 'profile': one builder's totals) and warns to compare active_days and window before comparing windows. It never names a sibling tool (e.g. hl_leaderboard) or states when to prefer those alternatives, so no exclusion guidance.

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.