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
Each tool has a distinct role: catalog tools (list_datasets/describe_dataset/list_fields), a live snapshot (live_market), a screener (screen_universe), a single-field ranking (query_cross_section), a time-series puller (query_series), and a specialized divergence ranker. The pairing of query_cross_section and screen_universe is the closest overlap (both operate on one completed interval), but the descriptions clearly separate single order_by ranking from multi-condition ANDed filtering.
Six of nine tools follow a clean verb_noun pattern (list_datasets, describe_dataset, list_fields, get_universe, query_cross_section, query_series, screen_universe). The remaining analytical tools (funding_divergence, live_market) use noun phrases, which is a minor but readable deviation rather than a conflicting convention.
Nine tools is well within the ideal range and each one earns its place: catalog, metadata, live state, two ranking/screening modes, series retrieval, universe summary, and a niche divergence metric. No redundant or trivial tools.
The surface covers discovery (datasets, fields), current state (live_market, get_universe), and both cross-sectional and time-series querying, plus a specialized funding view. Gaps are minor: there is no dedicated per-market profile/lookup beyond query_series and no export or bulk-download operation despite the 'downloadable datasets' framing.
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. day defaults to the last complete interval. 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, each row with usd_volume_7d_avg so a spread can be sized; pass min_usd_volume_7d_avg (USD/day) to exclude markets too illiquid to trade the divergence in. 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. | |
| day | No | The day or hour to rank as of: `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`. | |
| top_n | No | Markets per ranked list, 1..100 (values outside are clamped to the nearest bound and the response says so). 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. | |
| min_usd_volume_7d_avg | No | Drop markets whose average **daily** traded notional over the divergence window is below this value, in USD/day at either bar. Each row carries that figure as `usd_volume_7d_avg`, so the floor decides which spreads are tradeable rather than which are largest. |
| 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 | |
| published_at | No | |
| 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. |
| bar_age_hours | Yes | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and does substantial work: it declares the tool 'Descriptive only' (read-only), notes the Pro-key requirement for hourly bars, states that markets with no funding reading are excluded from both lists, and explains that cum_funding_spread is a high-minus-low spread rather than accumulated funding. It does not cover rate limits or explicit pagination behavior, but for a read-only ranking this is solid.
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?
The description is front-loaded with the core purpose and then walks through the key parameters, exclusions, and return shape in a logical order. It is dense and the metric explanation is long and partly duplicative of the schema, but every sentence carries relevant information and none is pure 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?
Given nine optional parameters, no annotations, and an output schema already present, the description covers the essentials: what is ranked, the benchmark default, interval semantics, the metric caveat, and the exclusion of markets without funding readings. It is complete enough to call correctly, with only minor gaps around ordering/ties and explicit sibling routing.
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 description coverage is 100%, so the baseline is 3. The description reinforces key meanings — bar granularity, metric choice, and the tradeability purpose of min_usd_volume_7d_avg — but most of that is already in the parameter descriptions, and it adds little new syntax or format detail beyond what the schema provides.
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 opens with a specific verb and resource: 'Rank markets by how far their funding has diverged from a benchmark (default ETH) over a trailing window.' That is unambiguous and an agent can tell this is a divergence-ranking tool rather than a generic query. It does not explicitly differentiate itself from siblings like query_cross_section or screen_universe, so it stops short of a 5.
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?
The description gives useful in-tool guidance — 1h bars require a Pro key, day defaults to the last complete interval, and min_usd_volume_7d_avg filters out illiquid markets. However, it never says when to choose this tool over a sibling such as screen_universe or query_cross_section, leaving that choice implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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..100, clamped) 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..100, clamped) 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. |
| published_at | No | |
| bar_age_hours | Yes | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses that output is a compact SUMMARY by default, that top_n is clamped to 1..100, that the range counts are bounded (7 days at bar:1h, whole published range at 1d), and that 1h requires a Pro key. It stops short of stating read-only-ness explicitly or naming the cost/size of the default response, but the behavioral picture is unusually complete for an unannotated tool.
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?
The lead sentence front-loads the returned artifacts, which is the right choice, and later sentences are parameter-scoped rather than filler. It is slightly overstuffed — the days/bar windower explanation is dense prose that duplicates schema text, and one sentence runs long.
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?
Five optional parameters, a rich schema, and an output schema that already documents return values mean the description does not need to explain response shapes — and it correctly does not. What remains is the default-vs-expanded output behavior, which is covered; only the relationship to sibling coverage/dataset tools 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 description coverage is 100%, so the schema already documents bar, day, days, scope, and top_n in detail — the description largely restates those defaults. It does add a small amount of framing (SUMMARY is the default shape; only request per-market counts if needed), but not enough to exceed the baseline.
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 opening sentence names the deliverable concretely — last complete interval, market counts for a scope, history depth, and density — which is a specific resource description rather than a restatement of the name. It is clearly distinguishable from query_series/screen_universe by being a coverage/metadata summary, but it never explicitly contrasts itself with describe_dataset or list_datasets, which sit closest to it.
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?
Usage is implied rather than stated: the reader infers this is the 'check coverage before querying' tool. Guidance is given for parameters (default bar, when to pass top_n) but there is no explicit when-to-use-this-vs-alternatives statement naming describe_dataset, list_datasets, or screen_universe, which is the main gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
With no annotations, the description carries the full burden and does disclose two non-obvious traits: it requires no key, and the percentile/z-score/top_pct conditions of the query tools rank only within markets the plan can see, motivating a wide slice. Return values are covered by the output schema, so no gap there; only the absence of any mention of scan size or latency keeps it from a 5.
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 short sentences: what it returns, whether it is gated, and when to call it. Front-loaded and mostly waste-free. The closing remark about plan-scoped ranking is useful but sits slightly outside the tool's own contract, adding a little breadth.
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?
An output schema exists, so the description rightly does not explain the return shape, and a zero-parameter tool needs no parameter guidance. Coverage of auth and call ordering is complete. The only missing piece is how this tool divides labour with describe_dataset and list_datasets.
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 there is nothing for the description to disambiguate and the baseline of 4 applies. The field attributes named in the description describe the output, not inputs, and are consistent with the schema.
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 states a concrete deliverable: every field the query tools accept, with meaning, unit, nullability, and availability per bar (1d, 1h). That is far more informative than the name alone. It stops short of explicitly distinguishing itself from the sibling describe_dataset, which covers adjacent metadata territory.
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 gives a clear, actionable directive: call before query_cross_section, screen_universe or query_series, and notes it is open with no key needed, so an agent knows there is no prerequisite. It does not address when to prefer describe_dataset or list_datasets instead, leaving one sibling routing decision to inference.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the data source (venue's public API), that the response is stamped with the read moment, and critically that open interest is one-sided/counted once per contract versus Hyperliquid's UI both-sides figure. It does not mention auth, rate limits, or staleness windows, which is a minor gap for a public read endpoint.
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?
One front-loaded paragraph: what you get first, the important OI caveat parenthetical, then the when-to-use rule. Every sentence carries information. Slightly dense with the nested parenthetical, but nothing is wasted.
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?
An output schema exists, so return values need not be explained — yet the description still flags the one non-obvious output semantic (one-sided OI vs. the oi_usd column in bar tools) that an agent could otherwise misread. Combined with the usage routing, an agent has everything needed to call and interpret this tool correctly.
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 description coverage is 100% and the single parameter (coins, 1..25) is fully documented in the schema. The description only restates "up to 25 markets," adding no syntax, symbol-format, or ordering guidance beyond structured data. Baseline 3 is appropriate when the schema does the work.
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 names a specific resource (live market snapshot) and enumerates the exact fields returned — mark price, hourly funding, open interest, 24h notional, premium — so an agent knows precisely what it gets. It also distinguishes itself from the bar-based tools that cover completed intervals. No ambiguity about what 'live_market' does.
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 gives an explicit when-to-use rule: "Use this for 'now' questions," contrasted with the bar=1d/bar=1h tools that answer completed intervals only. This is real routing guidance. Minor deduction because the referenced alternatives ("bar=1d and bar=1h tools") are not named among the actual siblings, so the agent must infer they map to query_series.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 (USD/day at either bar) 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..100 (values outside are clamped to the nearest bound and the response says so). 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 trailing window is below this value, in USD/day at either bar — a floor chosen at `1d` means the same thing at `1h` — 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`. |
| published_at | No | When the newest interval in this answer was actually published (written), UTC. Absent at the daily grain, whose coverage comes from the manifest rather than the object's write time. Compare with `bar_age_hours` to see the publication lag. |
| bar_age_hours | Yes | How many hours ago the newest interval closed. The published hourly source is written ~1.5–2.5 h after its bar, so `bar_age_hours` is the decision lag: the bar is already this old before anyone can trade on it. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the burden and does well: defaults for bar/day/scope, why hip3 scope is not comparable (underlying closes), that percentile/zscore rank only within plan-visible markets, and that the volume floor is applied BEFORE ranking. It omits error/permission behavior beyond the Pro-key note for 1h and any rate/limit context.
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?
Front-loaded with the core action and the answering scenarios, with defaults and edge rules following in priority order. It is dense and clause-heavy in a single paragraph, but no sentence is 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 an 11-parameter tool with an output schema, the description covers the decisions an agent must make: bar/day defaults, scope semantics, stat eligibility, filtering order, and column-name sourcing. Return values need not be explained because an output schema exists.
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%, so parameter meaning is already documented and the baseline applies. The description adds modest value by explaining order of operations ('the ranking is computed after' the volume floor) and where field names come from, but most parameter specifics duplicate the schema text.
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?
Opens with a specific verb+resource+scope ('Rank the whole market on ONE completed interval') and immediately differentiates itself from query_series and screen_universe. An agent can tell it is a market-wide ranking tool, not a per-coin time series or a filtering/cut tool.
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 concrete answering scenarios ('top markets by funding / open interest / returns', 'what percentile is BTC on open interest') and an explicit exclusion with the alternative: for a cut ('top decile by X') use screen_universe. It also forbids guessing field names by routing to list_fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The series for one market or a few (max 10): one row per market per interval over a trailing window, ordered by interval then market. 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 | Ordered by interval, then market. |
| 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. |
| published_at | No | |
| bar_age_hours | Yes | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does real work: it discloses the hard row cap, that the response self-reports the window it used, that ending_day defaults to the last complete interval, and that 1h requires a Pro key. It does not say what happens when the cap is exceeded (error vs truncation), which is the main remaining behavioral gap.
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?
Front-loaded with the return shape, then defaults, then the cap constraint; four sentences with little waste. The 'Answers ... questions' sentence is slightly rhetorical, and the cap explanation is dense enough to need a second read, but nothing is padding.
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?
Output schema exists, so return values need no explanation, and the description still covers the non-obvious operational facts: grain/ordering, the row cap and its arithmetic, default ending interval, and key-tier requirement. An agent has everything needed to construct a valid call.
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%, so the baseline is 3, and the schema already documents bar, coins, scope, columns, ending_day, and window_days thoroughly. The description adds genuine cross-parameter meaning — the markets x window_days x 24 row-cap interaction and the ending_day default — which nudges it upward, but most of its parameter text restates schema content.
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 opening states the resource and its exact shape: 'one row per market per interval over a trailing window, ordered by interval then market,' with a hard max of 10 markets. That grain description implicitly separates it from query_cross_section, but no sibling is ever named, so the differentiation is inferential rather than explicit.
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?
Usage is conveyed through the questions it answers ('is this move backed by real flow', 'how has positioning built up') and through explicit constraints on when it is valid (markets x window_days x 24 must fit the row cap; 1h needs a Pro key). It never states when NOT to use it or names an alternative such as query_cross_section, which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 (USD/day at either bar) 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..100 (values outside are clamped to the nearest bound and the response says so). Defaults to 25. | |
| min_usd_volume_7d_avg | No | Drop markets whose average **daily** traded notional over the trailing window is below this value, in USD/day at either bar — a floor chosen at `1d` means the same thing at `1h`. |
| 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 | |
| published_at | No | |
| bar_age_hours | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and discloses important traits: completed intervals, ANDed conditions, free vs Pro bar gating, deciles computed over eligible markets, pre-decile liquidity flooring, and the rule that missing fields never satisfy a condition. It does not cover rate limits or explicitly state read-only behavior, so it is strong but not exhaustive.
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?
The description is front-loaded, dense, and appropriately sized for a 10-parameter screening tool. The final sentence about unreported fields repeats a point already present in the schema, which is a minor redundancy.
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?
Given the complexity, full schema coverage, and an output schema, the description is largely complete: it explains the critical interval, condition, decile, and liquidity-floor semantics. It leaves smaller parameters such as coins, scope, and order_by to the schema, but those are adequately documented there.
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%, so the schema already documents parameters well. The description still adds meaningful interpretation beyond the schema by explaining that top_pct/bottom_pct are deciles of eligible markets and that the liquidity floor is applied before decile calculation.
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 states a specific verb and resource ('Screen the whole market') and adds the key scope ('ONE completed interval with several conditions ANDed together'). It does not explicitly distinguish itself from siblings such as query_cross_section or get_universe, so it falls short of a 5.
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 gives example screening questions and explains the bar/plan constraint, which implies when the tool is useful. However, it never names an alternative or states when not to use this tool versus query_cross_section or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
funding_divergence3 fields changedInput schema / properties / min_usd_volume_7d_avgAdded value: +{
+ "default": null,
+ "description": "Drop markets whose average **daily** traded notional over the divergence\nwindow is below this value, in USD/day at either bar. Each row carries\nthat figure as `usd_volume_7d_avg`, so the floor decides which spreads\nare tradeable rather than which are largest.",
+ "format": "double",
+ "nullable": true,
+ "type": "number"
+}Output schema / $defs / DivergenceRow / properties / usd_volume_7d_avgAdded value: +{
+ "description": "Average **daily** traded notional over the same window, in USD/day at\neither grain. A funding spread is only as interesting as the size a\nposition in it can take, and the widest divergence in a slice is\nregularly a quiet day in an illiquid market — read this column before\nreading `divergence`.",
+ "format": "double",
+ "type": "number"
+}Output schema / $defs / DivergenceRow / requiredPrevious value: -[
- "coin",
- "value",
- "divergence"
-]New value: +[
+ "coin",
+ "value",
+ "divergence",
+ "usd_volume_7d_avg"
+]funding_divergence3 fields changedOutput schema / properties / bar_age_hoursAdded value: +{
+ "format": "double",
+ "type": "number"
+}Output schema / properties / published_atAdded value: +{
+ "nullable": true,
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "bar",
- "source",
- "as_of",
- "scope",
- "visible_count",
- "eligible_count",
- "matched_count",
- "metric",
- "benchmark",
- "window_days",
- "benchmark_value",
- "top_positive",
- "top_negative",
- "truncated",
- "notes"
-]New value: +[
+ "bar",
+ "source",
+ "as_of",
+ "bar_age_hours",
+ "scope",
+ "visible_count",
+ "eligible_count",
+ "matched_count",
+ "metric",
+ "benchmark",
+ "window_days",
+ "benchmark_value",
+ "top_positive",
+ "top_negative",
+ "truncated",
+ "notes"
+]get_universe3 fields changedOutput schema / properties / bar_age_hoursAdded value: +{
+ "format": "double",
+ "type": "number"
+}Output schema / properties / published_atAdded value: +{
+ "nullable": true,
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "bar",
- "source",
- "as_of",
- "scope",
- "interval_start",
- "interval_end",
- "interval_count",
- "months_covered",
- "visible_count",
- "eligible_count",
- "matched_count",
- "market_count_total",
- "market_count_crypto",
- "market_count_hip3",
- "row_count",
- "rows_per_market_interval",
- "coverage_from_manifest",
- "truncated",
- "notes"
-]New value: +[
+ "bar",
+ "source",
+ "as_of",
+ "bar_age_hours",
+ "scope",
+ "interval_start",
+ "interval_end",
+ "interval_count",
+ "months_covered",
+ "visible_count",
+ "eligible_count",
+ "matched_count",
+ "market_count_total",
+ "market_count_crypto",
+ "market_count_hip3",
+ "row_count",
+ "rows_per_market_interval",
+ "coverage_from_manifest",
+ "truncated",
+ "notes"
+]list_fields6 fields changedOutput schema / $defs / FieldDoc / properties / best_horizon_hoursAdded value: +{
+ "description": "Horizon (hours) at which the field's signal is strongest/most durable.",
+ "format": "uint32",
+ "minimum": 0,
+ "nullable": true,
+ "type": "integer"
+}Output schema / $defs / FieldDoc / properties / classAdded value: +{
+ "description": "Which signal class the field belongs to, when it has been measured:\n`state` (durable, 24 h horizon, retention ≈ 1), `microstructure`\n(same-bar, decays under the entry delay), `momentum` (short-term\nreversal that survives the delay) or `no_signal`. Absent for stored\ncolumns that were never measured on their own.",
+ "nullable": true,
+ "type": "string"
+}Output schema / $defs / FieldDoc / properties / delay_retentionAdded value: +{
+ "description": "Share of `ic_fwd` left when entry is delayed by the source's real\npublication lag (~2 h). Near 1 means durable; near 0 means same-bar only.",
+ "format": "double",
+ "nullable": true,
+ "type": "number"
+}Output schema / $defs / FieldDoc / properties / horizon_hoursAdded value: +{
+ "description": "Horizon (hours) at which `ic_fwd`, `ic_back` and `delay_retention` are\nstated.",
+ "format": "uint32",
+ "minimum": 0,
+ "nullable": true,
+ "type": "integer"
+}Output schema / $defs / FieldDoc / properties / ic_backAdded value: +{
+ "description": "Backward-placebo IC at `horizon_hours`: large values mean the forward IC\nis partly contemporaneous with the return, not predictive of it.",
+ "format": "double",
+ "nullable": true,
+ "type": "number"
+}Output schema / $defs / FieldDoc / properties / ic_fwdAdded value: +{
+ "description": "Forward cross-sectional rank IC at `horizon_hours`.",
+ "format": "double",
+ "nullable": true,
+ "type": "number"
+}query_cross_section3 fields changedOutput schema / properties / bar_age_hoursAdded value: +{
+ "description": "How many hours ago the newest interval closed. The published hourly source\nis written ~1.5–2.5 h after its bar, so `bar_age_hours` is the decision\nlag: the bar is already this old before anyone can trade on it.",
+ "format": "double",
+ "type": "number"
+}Output schema / properties / published_atAdded value: +{
+ "description": "When the newest interval in this answer was actually published (written),\nUTC. Absent at the daily grain, whose coverage comes from the manifest\nrather than the object's write time. Compare with `bar_age_hours` to see\nthe publication lag.",
+ "nullable": true,
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "bar",
- "source",
- "as_of",
- "scope",
- "visible_count",
- "eligible_count",
- "matched_count",
- "row_count",
- "truncated",
- "stat",
- "rows",
- "notes"
-]New value: +[
+ "bar",
+ "source",
+ "as_of",
+ "bar_age_hours",
+ "scope",
+ "visible_count",
+ "eligible_count",
+ "matched_count",
+ "row_count",
+ "truncated",
+ "stat",
+ "rows",
+ "notes"
+]query_series3 fields changedOutput schema / properties / bar_age_hoursAdded value: +{
+ "format": "double",
+ "type": "number"
+}Output schema / properties / published_atAdded value: +{
+ "nullable": true,
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "bar",
- "source",
- "as_of",
- "scope",
- "window_days",
- "visible_count",
- "eligible_count",
- "matched_count",
- "row_count",
- "truncated",
- "rows",
- "notes"
-]New value: +[
+ "bar",
+ "source",
+ "as_of",
+ "bar_age_hours",
+ "scope",
+ "window_days",
+ "visible_count",
+ "eligible_count",
+ "matched_count",
+ "row_count",
+ "truncated",
+ "rows",
+ "notes"
+]screen_universe3 fields changedOutput schema / properties / bar_age_hoursAdded value: +{
+ "format": "double",
+ "type": "number"
+}Output schema / properties / published_atAdded value: +{
+ "nullable": true,
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "bar",
- "source",
- "as_of",
- "scope",
- "visible_count",
- "eligible_count",
- "matched_count",
- "row_count",
- "truncated",
- "rows",
- "notes"
-]New value: +[
+ "bar",
+ "source",
+ "as_of",
+ "bar_age_hours",
+ "scope",
+ "visible_count",
+ "eligible_count",
+ "matched_count",
+ "row_count",
+ "truncated",
+ "rows",
+ "notes"
+]Read-only Hyperliquid analytics: orderflow, liquidation levels, whale positioning, funding.
Hyperliquid MCP — read-only market data from Hyperliquid's public info API.
Hyperliquid - 2 tools for perpetuals, options, and position data
Hyperliquid liquidation levels, whale positions, liquidations, cohorts and funding. Free.
Add one secure layer between your agents and this server.