Tessera turns the whole Hyperliquid perp universe into a single cross-section you can query. The hosted MCP server answers the questions a raw-data pipe can't: which markets are crowded, who is paying the most funding, how far one market's funding has diverged from ETH, what open interest and positioning look like across every market on the last completed day, and what the live market is doing right now. Nine tools — four ranking/screening tools, a series tool for one market, a coverage tool, the catalog/dictionary trio, and a live market read — over a completed-day rollup built from the venue's own trade feed. Rows and full history stay on the REST API: three Parquet datasets (order-flow-enriched 1-minute OHLCV, hourly funding, hourly positioning) partitioned per coin-month, downloadable with a key. Free keys work end to end; Pro removes the history and coverage limits.
Scored across 9 tools
The three metadata helpers (list_datasets, describe_dataset, list_fields) target distinct objects—dataset catalog, one dataset's schema, and queryable fields—and live_market is clearly separated as the 'now' tool versus interval-based tools. The main overlap risk is query_cross_section vs screen_universe (both operate on one completed interval and rank/filter markets) and funding_divergence vs query_cross_section, though descriptions draw usable lines between ranking-with-conditions and ranking-by-dedicated-metric.
Seven of nine names follow a clean verb_noun pattern (describe_dataset, get_universe, list_datasets, list_fields, query_cross_section, query_series, screen_universe), and the query_* / list_* prefixes are used coherently. Only funding_divergence and live_market break the convention as noun phrases, a minor deviation.
Nine tools is well within the 3-15 sweet spot for a market-intelligence API and each maps to a distinct access pattern (metadata, live, cross-section, screening, series, universe, funding divergence). No tool appears redundant or bolted on.
The surface covers the full lifecycle an agent needs: dataset discovery and schema, field discovery, live snapshots, cross-sectional ranking, conditional screening, per-market time series, and universe coverage plus a specialized funding-divergence ranking. Minor gaps exist—no single-market detail/profile endpoint or explicit historical snapshot tool—but core workflows are complete with no hard dead ends.
The full dictionary for ONE downloadable dataset: description plus every column's type, nullability and plain-English meaning. Pass a name from list_datasets. Open — no key needed. For the fields the query tools accept, use list_fields.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Dataset name, as returned by `list_datasets`. |
| Name | Required | Description |
|---|---|---|
| name | Yes | Dataset name, exactly as `list_datasets` reports it. |
| note | No | Optional "how to use this" callout. |
| tier | Yes | Display tier: `free` or `pro`. Re-derived from `policy.rs` on read, so it always matches actual entitlement regardless of the on-disk value. |
| title | Yes | Human-friendly title, e.g. "Order-flow OHLCV (1-minute)". |
| cadence | Yes | How frequently the data is sampled, e.g. "1-minute bars". |
| summary | Yes | One-line intuitive summary — the catalog card. |
| category | Yes | Presentation category, e.g. `raw-tiles` or `forecast-layer`. |
| keywords | No | Per-dataset discovery keywords (schema.org keywords on the web). |
| temporal | No | Machine-readable timestamp/interval contract: what the label marks and how to join without leaking the future. Defaulted so snapshots predating the field still deserialize. |
| use_case | No | One-line "what you'd use it for" (buyer-intent) copy. |
| seo_title | No | Keyword-first SEO title tag (web `<title>`). Defaulted so older snapshots without the field still deserialize. |
| description | Yes | Longer prose — the dictionary page header. |
| column_count | Yes | Number of documented columns. |
| column_groups | Yes | Columns, grouped for presentation, in schema order. |
| direct_answer | No | 40-60 word keyword-first lead answer — the definitional "what is this" blurb, and the strongest AI-citation extraction target. Defaulted for forward/backward compatibility with snapshots predating the field. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that no key is needed (auth) and implies a read-only operation by describing a dictionary retrieval. It does not mention error handling or side effects, but for a simple read tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste: the first front-loads the purpose and scope, the second clarifies usage and alternative. Highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter read tool with an output schema, the description fully covers what it returns, how to obtain the input, and when to use an alternative. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of 'asset' as 'Dataset name, as returned by list_datasets.' The description adds no new information beyond the schema, merely repeating the instruction, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('returns') and resource ('the full dictionary for ONE downloadable dataset'), and explicitly contrasts it with list_fields for query tools. This distinguishes it from siblings without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to pass a name from list_datasets and provides an alternative (list_fields) for when the fields are needed for query tools. The 'Open — no key needed' also sets expectations for access, making usage conditions explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank markets by how far their funding has diverged from a benchmark (default ETH) over a trailing window. Pick bar (1d, the default, or 1h on a Pro key) to read completed days or completed hours. metric=rate compares mean funding over the window; metric=cum_funding_spread compares how far a market's cumulative funding level travelled inside the window (its high minus its low, so never negative) — that is not the funding the window accumulated, which is funding_paid_7d (or funding_rate_7d_avg times the window's completed-interval count). Returns the most diverged in each direction. Markets with no funding reading are excluded from both lists. Descriptive only.
| Name | Required | Description | Default |
|---|---|---|---|
| bar | No | `1d` (the default) for completed UTC days, `1h` for completed UTC hours. An interval, at either grain, is stamped by the instant it **closes** — an hourly `…T09:00:00Z` is the hour that ended at 09:00. | |
| coins | No | Restrict to these markets. | |
| scope | No | `crypto` (the default), `hip3`, or `all`. | |
| top_n | No | Markets per ranked list, 1..50. Defaults to 10. | |
| metric | No | `rate` (the default) ranks each market's mean funding over the window minus the benchmark's; `cum_funding_spread` ranks the **spread of the cumulative funding level** over the window — its high minus its low, so always non-negative — minus the benchmark's. That is not the funding the window accumulated: `cum_funding` is a running total, so a market whose level retraced has a large spread and a *negative* accumulation (and one that reversed inside the window has a spread several times its true accumulation). Measured 2026-10-13 over 34 markets and the trailing 168 hours, the expression below reproduced the served value exactly, while `SUM(funding_paid)` over the same window disagreed in sign for 11 of them (TRX +0.00440 vs −0.00445) and by up to 100× (CASHCAT 0.2050 vs 0.0020). The accumulation is `funding_paid_7d`, or equivalently `funding_rate_7d_avg` × the window's completed-interval count — 7 intervals at the daily grain and 168 at the hourly one. | |
| benchmark | No | The market whose funding is the yardstick. Defaults to ETH. | |
| window_days | No | Length of the trailing window in days, 1..365. Defaults to 7. |
| Name | Required | Description |
|---|---|---|
| bar | Yes | The grain this answer was computed at: `1d` or `1h`. |
| as_of | Yes | |
| notes | Yes | |
| scope | Yes | |
| metric | Yes | |
| source | Yes | |
| benchmark | Yes | |
| truncated | Yes | |
| window_days | Yes | |
| top_negative | Yes | The largest divergences toward the benchmark's opposite, most extreme first. |
| top_positive | Yes | The largest divergences away from the benchmark, most extreme first. |
| matched_count | Yes | Markets that had a funding reading in the window. Markets without one are excluded from both lists and from this count — a missing reading must never appear as an extreme. |
| visible_count | Yes | Markets in your plan's slice on this interval, before any filter you passed. |
| eligible_count | Yes | Markets left after your explicit market filter. |
| benchmark_value | Yes | The benchmark's own value for the metric. |
The coverage picture: the last complete interval, how many markets are in the universe for a scope, how much history sits behind them, and how densely it is populated. Pick bar (1d, the default, or 1h on a Pro key) to describe completed days or completed hours. The range counts cover the last 7 days at bar: 1h (pass days, 1..30, to widen them) and the whole published range at bar: 1d. A compact SUMMARY by default — pass top_n (1..50) only if you need the per-market counts.
| Name | Required | Description | Default |
|---|---|---|---|
| bar | No | `1d` (the default) for completed UTC days, `1h` for completed UTC hours. An interval, at either grain, is stamped by the instant it **closes** — an hourly `…T09:00:00Z` is the hour that ended at 09:00. | |
| day | No | The day or hour to describe: `YYYY-MM-DD` or `latest` at `bar: 1d`, a completed `YYYY-MM-DDTHH:00:00Z` (the hour that *ended* there) or `latest` at `bar: 1h`. | |
| days | No | How many days of completed intervals the range counts cover, 1..30. Defaults to 7 at `bar: 1h` — the hourly source publishes one object per completed hour, so an unbounded inventory would open every hour ever published — and to the whole published range at `bar: 1d`, whose source is one object per month. The window the counts actually covered is `interval_start`..`interval_end`, and `notes` says when it was bounded. | |
| scope | No | `crypto` (the default), `hip3`, or `all`. | |
| top_n | No | Per-market detail is off by default; passing a value (1..50) returns that many markets, listed by name, alongside the summary. |
| Name | Required | Description |
|---|---|---|
| bar | Yes | The grain this answer was computed at: `1d` or `1h`. |
| as_of | Yes | The interval the per-population counts describe. |
| coins | No | Per-market detail, only when requested. Markets are listed by name. |
| notes | Yes | |
| scope | Yes | |
| source | Yes | |
| row_count | Yes | Rows in scope over the counted range. |
| truncated | Yes | True when more markets exist than the detail list returned. |
| interval_end | Yes | The newest interval the counts below cover — the same interval `as_of` describes, since the counts are the history behind those populations. |
| matched_count | Yes | Markets the counted range actually represents — the ones with at least one row in it, which is every market in `eligible_count` at the described interval. |
| visible_count | Yes | Markets in your plan's slice on the described interval, before any scope class is applied. |
| eligible_count | Yes | Distinct markets in scope over the counted range. |
| interval_count | Yes | Distinct intervals in the range the counts below cover. |
| interval_start | Yes | The oldest interval the counts below cover: the published range start, the caller's history floor when the plan clips it, or the start of the window `days` bounded them to. The response says which, in `notes`. |
| months_covered | Yes | |
| market_count_hip3 | Yes | Markets with a deployer prefix on the described interval. |
| market_count_total | Yes | Distinct markets in scope over the counted range. |
| market_count_crypto | Yes | Markets without a deployer prefix on the described interval, whatever scope was asked for. |
| coverage_from_manifest | Yes | True when the interval range came from the published coverage manifest, false when it had to be read from the data or the object listing itself. |
| rows_per_market_interval | Yes | `row_count` divided by (intervals × markets) — how densely the counted range is populated. Below 1.0 means some markets are missing some intervals. |
List the downloadable datasets: one-line summary, the plan required, and the month range available. Open — no key needed. Then use describe_dataset for one dataset's columns, or list_fields for the fields the query tools accept.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| datasets | Yes | |
| your_tier | Yes | The caller's own plan (`free`, `pro` or `anonymous`). |
| generated_at | Yes | When this catalog was produced. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that no key is needed, that some datasets require a plan, and what the response summarizes. This is solid behavioral context for a simple read-only list operation, though it does not mention pagination or output shape beyond the summary fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, with the core listing behavior and output contents front-loaded, followed by a useful pointer to related tools. Every clause earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with an output schema and low complexity, the description is complete: it explains what is listed, the access model, and the next steps. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the empty schema fully covers parameter semantics. The description appropriately adds no redundant parameter details; per the rubric, zero parameters earns a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Begins with a specific verb and resource: 'List the downloadable datasets.' It also spells out exactly what the list contains (one-line summary, plan required, month range) and names successor tools, making its role distinct from siblings like describe_dataset and list_fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives direct workflow guidance: 'Then use describe_dataset for one dataset's columns, or list_fields for the fields the query tools accept.' It also states the access condition ('Open — no key needed'), so an agent knows when and how to invoke this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every field the query tools accept, each with its meaning, unit, whether it can be missing, and which bars (1d, 1h) it exists on. Open — no key needed. Call this before query_cross_section, screen_universe or query_series. Percentile, z-score and the top_pct/bottom_pct conditions rank within the markets your plan can see, so they need a wide slice.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| fields | Yes | Every field the query tools accept. |
| generated_at | Yes | When this vocabulary was produced. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the load; it discloses that access is open (no auth) and explains that percentile/z-score/top_pct/bottom_pct ranking is scoped to the markets a plan can see, which is non-obvious behavioral context. It does not state side-effect/read-only status explicitly, but a field catalog is implicitly read-only and the output schema covers the return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the payload description before prerequisites and semantics. The final sentence on plan-scoped ranking is informative but slightly tangential to a field-listing call, keeping it just short of a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no inputs and an output schema present, the description need not explain return values; it instead covers the essentials an agent needs — what it returns, that it is keyless, when to call it, and the plan-scoped ranking caveat.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to disambiguate. The mention of 'bars (1d, 1h)' is descriptive of returned data, not of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise resource ('every field the query tools accept') and enumerates the metadata returned per field (meaning, unit, nullable, available bars). An agent immediately understands this is a schema/catalog lookup, distinct from siblings like describe_dataset or list_datasets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'Call this before query_cross_section, screen_universe or query_series', naming the exact downstream tools it feeds. Also notes it is open with no key needed, removing a common prerequisite question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What is happening right now: mark price, current hourly funding, open interest (one-sided — counted once per contract, half of the both-sides figure Hyperliquid's own UI shows, so it is directly comparable with the oi_usd column the bar tools return), 24-hour traded notional and premium for up to 25 markets, taken straight from the venue's public API and stamped with the moment it was read. Use this for 'now' questions; the bar=1d and bar=1h tools answer completed intervals only.
| Name | Required | Description | Default |
|---|---|---|---|
| coins | Yes | The markets to snapshot, 1..25. |
| Name | Required | Description |
|---|---|---|
| rows | Yes | |
| as_of | Yes | When the snapshot was taken, UTC. |
| notes | Yes | |
| source | Yes | `hyperliquid_rest` — this is the live market, not the completed-day data. |
| coin_count | Yes |
Rank the whole market on ONE completed interval: pick bar (1d, the default, or 1h on a Pro key), columns, an order_by field and top_n. Answers 'top markets by funding / open interest / returns on the latest day or hour' and 'what percentile is BTC on open interest'. day defaults to the last complete interval; scope defaults to crypto (HIP-3 markets track an underlying that closes, so their flow is not comparable); stat=percentile|zscore ranks within your eligible markets; window_days recomputes the trailing-window fields; min_usd_volume_7d_avg keeps dust out of the ranking and the ranking is computed after it. Field names come from list_fields — never guess them, they are snake_case compound names and each one lists the bars it exists on; for a cut ('top decile by X') use screen_universe.
| Name | Required | Description | Default |
|---|---|---|---|
| bar | No | `1d` (the default) for completed UTC days, `1h` for completed UTC hours. An interval, at either grain, is stamped by the instant it **closes** — an hourly `…T09:00:00Z` is the hour that ended at 09:00. | |
| day | No | The day or hour to rank. For `bar: 1d`, `YYYY-MM-DD` or `latest` (the default: the most recent complete day). For `bar: 1h`, a completed hour as `YYYY-MM-DDTHH:00:00Z` — the hour that *ended* at that instant — or `latest`. | |
| stat | No | `raw` (the default), `percentile`, or `zscore`. Percentile and z-score are ranked **within the markets your plan can see**, so they need a slice of at least four markets. | |
| coins | No | Restrict to these markets. A market outside your plan's coverage is ignored rather than widening the answer. | |
| scope | No | `crypto` (the default), `hip3`, or `all`. Restricted markets track an underlying that closes, so their flow is not comparable on a weekend. | |
| top_n | No | How many markets to return, 1..50. Defaults to 20. | |
| columns | No | Fields to return per market, from `list_fields`. `coin` is always included. Defaults to price, traded notional and the interval's return. | |
| order_by | No | The field to rank by. Need not appear in `columns`. Defaults to the interval's traded notional. | |
| descending | No | Rank largest first (the default). Set false for the smallest. | |
| window_days | No | Recompute the trailing-window fields over this many days, 1..365 (default 7). The response always states the window it used. | |
| min_usd_volume_7d_avg | No | Drop markets whose average daily traded notional over the window is below this value, so dust cannot top a ranking. |
| Name | Required | Description |
|---|---|---|
| bar | Yes | The grain this answer was computed at: `1d` or `1h`. |
| rows | Yes | |
| stat | Yes | The ranking treatment actually applied: `raw`, `percentile` or `zscore`. |
| as_of | Yes | The UTC day (`YYYY-MM-DD`) or completed hour (`YYYY-MM-DDTHH:00:00Z`) the answer describes. An interval is stamped by the instant it closes, so an hourly `…T09:00:00Z` is the hour that ended at 09:00. |
| notes | Yes | |
| scope | Yes | The market population the ranking ran over. |
| source | Yes | `tessera_daily` or `tessera_hourly` — the clock this answer came from, never the live market. |
| row_count | Yes | How many markets are in `rows`. |
| truncated | Yes | True when `matched_count` exceeds `row_count`. |
| matched_count | Yes | Markets that reported the ranked field and passed every filter. This is the count the rows are drawn from. |
| visible_count | Yes | Markets in your plan's slice with a row on this interval, before any filter you passed. This is the universe the answer is a statement about. |
| eligible_count | Yes | Markets left after your explicit market filter and any traded-notional floor — the population the percentile, z-score and deciles were computed over. |
The series for one market or a few (max 10): one row per market per interval over a trailing window, oldest first. Pick bar (1d, the default, for one row per day, or 1h on a Pro key for one row per completed hour). Answers 'is this move backed by real flow' and 'how has positioning built up'. ending_day defaults to the last complete interval. The whole answer is capped, so markets times window_days (times 24 at bar 1h) must stay inside the row cap; the response states the window it used.
| Name | Required | Description | Default |
|---|---|---|---|
| bar | No | `1d` (the default) for completed UTC days, `1h` for completed UTC hours. An interval, at either grain, is stamped by the instant it **closes** — an hourly `…T09:00:00Z` is the hour that ended at 09:00. | |
| coins | Yes | The markets to return, 1..10. | |
| scope | No | `crypto` (the default), `hip3`, or `all`. | |
| columns | No | Fields to return per row, from `list_fields`. The interval column (`day` at 1d, `hour` at 1h) and `coin` are always included. | |
| ending_day | No | The last interval to include: `YYYY-MM-DD` or `latest` at `bar: 1d`, a completed `YYYY-MM-DDTHH:00:00Z` (the hour that *ended* there) or `latest` at `bar: 1h`. | |
| window_days | No | Length of the trailing window in days, 1..365. Defaults to 7. At `bar: 1h` one window day is 24 hourly rows. |
| Name | Required | Description |
|---|---|---|
| bar | Yes | The grain this answer was computed at: `1d` or `1h`. |
| rows | Yes | |
| as_of | Yes | The last interval in the series. |
| notes | Yes | |
| scope | Yes | |
| source | Yes | |
| row_count | Yes | |
| truncated | Yes | |
| window_days | Yes | The window the trailing fields were computed over, in days. |
| matched_count | Yes | How many of the requested markets the series actually has rows for — less than `eligible_count` when one of them has no data in the window. |
| visible_count | Yes | Markets in your plan's slice with a row on the last interval. |
| eligible_count | Yes | The markets you asked for, after the plan's slice and your filter were intersected. |
Screen the whole market on ONE completed interval with several conditions ANDed together. Pick bar (1d, the default, or 1h on a Pro key; a free key is screened at 1d). Conditions use op >, <, >=, <=, between, top_pct or bottom_pct; top_pct/bottom_pct are deciles of your eligible markets, and the liquidity floor is applied before the deciles so they are measured over the population you are choosing from. Answers 'top-decile funding with bottom-decile open-interest change' and 'open interest rising faster than volume'. A market that does not report a field never satisfies a condition on it.
| Name | Required | Description | Default |
|---|---|---|---|
| bar | No | `1d` (the default) for completed UTC days, `1h` for completed UTC hours. An interval, at either grain, is stamped by the instant it **closes** — an hourly `…T09:00:00Z` is the hour that ended at 09:00. | |
| day | No | The day or hour to screen: `YYYY-MM-DD` or `latest` at `bar: 1d`, a completed `YYYY-MM-DDTHH:00:00Z` (the hour that *ended* there) or `latest` at `bar: 1h`. | |
| coins | No | Restrict to these markets. | |
| scope | No | `crypto` (the default), `hip3`, or `all`. | |
| columns | No | Fields to return per market, from `list_fields`. | |
| order_by | No | The field to rank the matches by. Defaults to the interval's traded notional. | |
| conditions | Yes | Conditions, all of which must hold. A market that does not report a field never satisfies a condition on it. | |
| descending | No | Rank largest first (the default). | |
| max_results | No | How many markets to return, 1..50. Defaults to 25. | |
| min_usd_volume_7d_avg | No | Drop markets below this average daily traded notional over the window. |
| Name | Required | Description |
|---|---|---|
| bar | Yes | The grain this answer was computed at: `1d` or `1h`. |
| rows | Yes | |
| as_of | Yes | |
| notes | Yes | |
| scope | Yes | |
| source | Yes | |
| row_count | Yes | |
| truncated | Yes | |
| matched_count | Yes | Markets that met every condition. |
| visible_count | Yes | Markets in your plan's slice with a row on this interval, before any filter you passed. |
| eligible_count | Yes | Markets left after your explicit market filter and any traded-notional floor — the population the percentage conditions were measured against. |
Read-only Hyperliquid analytics: orderflow, liquidation levels, whale positioning, funding.
Exchange-exact crypto derivatives data for AI agents: open interest, funding and liquidations on 13 venues, measured Hyperliquid and Lighter positions with liquidation prices, tokenized stocks, Parquet history. 42 tools; the conclusion tools are free (also at /mcp/lite), raw rows need a Pro/Bot key or one USDC payment per call (x402).
Hyperliquid MCP — read-only market data from Hyperliquid's public info API.
Hyperliquid - 2 tools for perpetuals, options, and position data
Add one secure layer between your agents and this server.
