Skip to main content
Glama

Hyperliquid Segments

hl_segments
Read-onlyIdempotent

The Hyperliquid cohort vocabulary and its latest-snapshot positioning, by view. cohorts: the label sets per ladder, the exact spellings every cohort parameter accepts. segments: the catalogue with bounds, ranks and what each ladder measures (size is account value in USD; pnl is a percentile rank of cumulative realized PnL, not dollars; pnl_abs is dollars). summary: everything ONE cohort holds right now across all symbols: long/short notional in USD, bias a fraction from -1 to +1, pct_wallets_in_profit a FRACTION from 0 to 1 despite its name, exposure_ratio = notional / margin used, perp_bias = (long - short) / equity and equity_exposure = (long + short) / equity, native perp account only: positions on the main dex over the native perp account value (each wallet once, the whole account even under opened_within); builder-DEX positions are not included; wallets without a known positive native equity are left out of perp_bias, equity_exposure and this share's numerator, see equity_covered_share (main-dex notional of the counted wallets / of the whole cohort). Unbounded ratios (above 1 = over 1x; null when equity <= 0); that equity is not total_equity, so perp_bias x total_equity != total_long_usd - total_short_usd. heatmap: the whole symbol x cohort board (large: every symbol with open interest; empty cells are omitted). Positions are the latest 5-minute snapshot. history: ONE cohort (cohort + axis, both required; axis is size or pnl only) hour by hour, summed over all symbols, newest first, from 2026-04-07: long_usd and short_usd in USD, bias = (long - short) / (long + short), a RATIO from -1 to +1 (null when both are 0), position_count = open positions, NOT wallets. Each hour carries the cohort label it had then (label_basis is point_in_time; pnl labels are daily before 2026-08-06, see label_computed). hours sizes the window, limit caps the rows, has_more says older rows exist. With include=leverage each hour also carries perp_bias, equity_exposure and equity_covered_share, the three summary ratios of that hour (null before 2026-08-11 and for a missing hour; perp_bias and equity_exposure are also null where no wallet has a known positive equity, and equity_covered_share is 0 when none is counted). An unknown cohort for the axis is an error. Same data as GET /v1/hl-cohorts/{cohorts, segments, segments/{cohort}/summary, heatmap, segments/{cohort}/history}.

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

Input Schema

NameRequiredDescriptionDefault
endNoISO-8601 UTC upper bound, e.g. 2026-10-02T00:00:00Z. `history` only: with no `start`, the window is the `hours` newest hours at or before it. Used by view: history.
axisNoCohort ladder: `size` = account-value tiers in USD, `pnl` = percentile rank of cumulative realized PnL (NOT dollars), `pnl_abs` = dollar bands of that same PnL. Per-position `trade_size` / `tier` is refused here. `history` serves history for `size` and `pnl` only, and requires `axis`. Default by view: summary size, heatmap size. Used by view: summary, heatmap, history. Required by view: history.
viewNoWhat to read. `segments`: the catalogue of every cohort bucket with its bounds and what the ladder measures. `cohorts`: the flat label sets, i.e. the exact spellings every `cohort` parameter accepts. `summary`: what ONE cohort holds right now across all symbols. `heatmap`: the whole symbol x cohort board at the latest snapshot. `history`: ONE cohort's hourly long, short and bias summed over all symbols, newest first (axis size or pnl only). Default `segments`.segments
hoursNo`history` only: window length in hours when `start` is omitted, ending at `end` or now. Max 8760. Used by view: history.
limitNo`history` only: max hourly rows, newest first; `has_more` says older ones exist, page back with `end` = the oldest `ts` minus 1 second. Max 5000. Used by view: history.
startNoISO-8601 UTC lower bound, e.g. 2026-10-01T00:00:00Z. `history` only; hours before 2026-04-07 are never returned. Used by view: history.
cohortNoOne label on `axis`, spelled exactly as `hl_segments` view=cohorts lists it, e.g. `whale` (size) or `3x smart` (pnl). Used by view: summary, history. Required by view: summary, history.
includeNo`history` only: comma list, only `leverage`; default none (nothing extra is read). Adds to every hourly row `perp_bias` = (long - short) / equity, `equity_exposure` = (long + short) / equity and `equity_covered_share` = main-dex notional of the counted wallets / main-dex notional of the whole cohort: unbounded ratios (above 1 = more than 1x of equity), native perp account only (main-dex positions of wallets with a known positive native equity, each wallet once; builder-DEX positions are not included). An hour with no stored row, and any hour before `leverage.data_from` (2026-08-11), is null on all three (never 0). `perp_bias` and `equity_exposure` are also null when no counted wallet has a positive equity; `equity_covered_share` is null when the cohort holds no main-dex notional and a real 0 when it holds some but no wallet is counted. Hours rebuilt from fills rather than read from snapshots are null. An unknown token is refused. Used by view: history.
opened_withinNoOnly positions opened within this window: `24h`, `7d`, `30d` or `all`; positions with no known open time are left out of every bounded window. Used by view: summary, heatmap.all

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already mark this read-only and idempotent, but the description goes far beyond that: it discloses the 5-minute snapshot cadence, data start dates (2026-04-07, leverage from 2026-08-11), null-vs-zero semantics for leverage ratios, that builder-DEX positions are excluded, that an unknown cohort or token is an error, and the subtle distinction that perp equity is not `total_equity`. This is unusually rich disclosure for a read tool.

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

Conciseness3/5

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

The opening is front-loaded with the view taxonomy, which is good, but the `summary`, `history`, and leverage passages are dense run-on clauses with heavy semicolon nesting and repeated detail already present in the schema (notably the `include=leverage` text). It is information-dense rather than wasteful, but it is not appropriately sized for scanning.

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, the description carries the full burden of explaining return shapes, and it does so for every view — long/short USD, bias definitions, position_count being positions not wallets, heatmap cell omission, has_more pagination, and leverage ratio nullability. Nothing material an agent needs to call this correctly is missing.

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 baseline is 3, but the description adds cross-parameter meaning the schema only partially carries: `pnl` is a percentile rank not dollars, `bias` is a -1..+1 ratio, `pct_wallets_in_profit` is a fraction despite its name, `cohort` must match `view=cohorts` spellings, `axis` is restricted to size/pnl for history, and `include` accepts only `leverage`. Much of this duplicates schema prose, keeping it below 5.

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?

The description names the resource (Hyperliquid cohort vocabulary and snapshot positioning) and defines each of the five views concretely, so an agent can tell what data each view returns. It does not, however, contrast itself with the visible sibling hl_cohort_metrics or any other cohort tool, leaving that separation to inference.

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 states per-view selection rules explicitly: `cohorts` for exact label spellings, `summary` for one cohort now, `heatmap` for the full board, `history` for hourly series, plus which parameters are required per view and that `history` accepts only `size`/`pnl`. There are no explicit 'do not use this when…' exclusions or named alternative tools, so it stops short of 5.

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.