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
Most tools have clearly distinct roles: metadata discovery, live snapshots, cross-sectional ranking, time series, screening, and coverage summaries. Minor overlap exists between query_cross_section and screen_universe, and funding_divergence overlaps somewhat with ranking functionality, but the descriptions carve out distinct use cases.
The majority of tools follow a clear verb_noun pattern: list_datasets, list_fields, describe_dataset, query_series, query_cross_section, screen_universe, get_universe. Two tools deviate — funding_divergence and live_market — but they are still readable and don't create confusion.
Nine tools is a well-scoped size for a market-data analytics server. Each tool covers a meaningful slice: metadata, live data, cross-section, series, screening, universe coverage, and specialized divergence analysis, with no obvious redundant or filler tools.
The server covers live market data, daily cross-sections, time series, screening, funding divergence, and dataset metadata well. The main gap is that list_datasets advertises downloadable datasets but no tool actually performs a download; also there is no explicit OHLCV-specific endpoint, though query_series likely covers it.
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. metric=rate compares mean daily funding; metric=cum_funding_spread compares funding accumulated over the window. Returns the most diverged in each direction. Markets with no funding reading are excluded from both lists. Descriptive only.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 daily funding minus the benchmark's; `cum_funding_spread` ranks funding accumulated over the window, high minus low, minus the benchmark's. | |
| 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 |
|---|---|---|
| as_of | Yes | |
| notes | Yes | |
| scope | Yes | |
| metric | Yes | |
| source | Yes | |
| benchmark | Yes | |
| truncated | Yes | |
| coin_count | Yes | How many markets had a funding reading in the window; markets without one are excluded from both lists and from this count. |
| 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. |
| 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 takes on the behavioral disclosure burden and does so well. It states it is "Descriptive only," explains that markets with no funding reading are excluded from both lists, and notes that it returns the most diverged in each direction, which goes beyond the schema.
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?
Four short sentences, each earn its place: the core ranking purpose, the two metric definitions, the output behavior, and the exclusion rule. The most important information is front-loaded and no words are 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?
For a moderately complex tool with 6 optional parameters and an output schema, the description is nearly complete. It covers purpose, metric alternatives, benchmark default, return shape, and the no-funding exclusion. It only lacks explicit guidance on when to choose a sibling tool, which is minor given the clarity of the rest.
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 adds some interpretive context around the metric and benchmark concepts, but it largely restates what the schema already documents rather than introducing new parameter semantics.
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." It also clarifies the two metric modes and that it returns diverged markets in both directions, making the tool's purpose unmistakable even without relying on the name.
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 behavior is clear enough that an agent can infer when to use this tool, and "Descriptive only" signals it is a read-only analysis. However, it never explicitly contrasts this tool with siblings like query_series, screen_universe, or live_market, nor states when an alternative would be preferable.
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 day, how many markets are in the universe for a scope, how much history sits behind them, and how densely it is populated. A compact SUMMARY by default — pass top_n (1..50) only if you need the per-market day counts.
| Name | Required | Description | Default |
|---|---|---|---|
| day | No | The day to describe, `YYYY-MM-DD` or `latest`. | |
| 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 |
|---|---|---|
| as_of | Yes | The day the per-population counts describe. |
| coins | No | Per-market detail, only when requested. Markets are listed by name. |
| notes | Yes | |
| scope | Yes | |
| source | Yes | |
| min_day | Yes | The oldest day the counts below cover: the published range start, or the caller's history floor when the plan clips it (the response says so in `notes`). |
| day_count | Yes | Distinct days in the range. |
| row_count | Yes | Rows in scope over the whole range. |
| truncated | Yes | True when more markets exist than the detail list returned. |
| months_covered | Yes | |
| coin_count_hip3 | Yes | Markets with a deployer prefix on the described day. |
| coin_count_total | Yes | Distinct markets in scope over the whole range. |
| max_complete_day | Yes | The newest complete day — the day `latest` resolves to. |
| coin_count_crypto | Yes | Markets without a deployer prefix on the described day, whatever scope was asked for. |
| rows_per_market_day | Yes | `row_count` divided by (days × markets) — how densely the range is populated. Below 1.0 means some markets are missing some days. |
| coverage_from_manifest | Yes | True when the day range came from the published coverage manifest, false when it had to be read from the data itself. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It discloses that the default output is a compact SUMMARY and that top_n (1..50) returns per-market day counts, which is useful. However, it doesn't mention error handling, invalid inputs, rate limits, or authentication requirements, and it's vague about what 'history behind them' and 'densely populated' mean in output terms.
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 redundancy. The core purpose is front-loaded ('coverage picture'), the default behavior is stated, and the optional parameter is introduced clearly. Every word earns its place.
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 are covered structurally. The description is sufficient for an agent to understand what the tool does and how to get the summary or per-market detail. Minor gaps like examples or typical use cases would elevate it further, but it's adequate given the schema coverage.
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 adds a little value by explaining top_n's purpose ('per-market day counts') and its valid range (1..50), which the schema also states but in a more terse way. Day and scope are not elaborated beyond the schema, so the description doesn't materially enhance understanding of those parameters.
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 the tool provides a coverage picture: last complete day, market count, history depth, and density. It uses a specific verb ('get' implied) and resource ('universe'), and the output type (SUMMARY vs per-market detail) is explicit. It doesn't name sibling tools but the purpose is unambiguous and distinct enough.
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?
No guidance on when to use this tool versus siblings like describe_dataset, list_datasets, or query_series. The description mentions default behavior and the optional top_n, but doesn't state conditions for selecting this tool over others or when not to use it. This is a significant 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 and whether it can be missing. 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 full behavioral burden. It discloses that the tool is open with no key needed, that fields can be missing, and that ranking conditions behave relative to visible markets. This is meaningful context beyond a simple listing, though it does not describe the output shape or explicitly state read-only behavior.
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 three sentences long and front-loads the core purpose before adding usage instructions and a caveat. Every sentence adds value, with no redundant wording or repetition of schema information.
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 metadata tool with an output schema, the description is complete: it states what the tool returns, when to call it, that no authentication is needed, and an important behavioral nuance about ranking conditions. No critical information is missing for an agent to use it 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?
The tool has zero parameters Input Schema, and schema coverage is 100%, so there are no unknown parameters to document. The description appropriately notes that no key is needed, which complements the empty schema. Baseline for zero-parameter tools is 4, and nothing is missing.
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 the tool's purpose: listing every field that query tools accept, along with meaning, unit, and missingness. It explicitly names sibling query tools (query_cross_section, screen_universe, query_series) that this tool is a prerequisite for, distinguishing it from data-querying tools.
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 explicitly instructs the agent to call this tool before specific sibling tools, which is strong when-to-use guidance. It also adds a practical usage condition: percentile, z-score, and top_pct/bottom_pct conditions require a wide market slice to rank properly.
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, 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 daily tools answer completed days 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?
No annotations are provided, so the description carries the full burden. It discloses the read-only nature (snapshot taken straight from the venue's public API), the freshness behavior (stamped with moment it was read), and the market cap (25). It does not address edge behavior like rate limits or error handling, and it stops short of explicitly saying 'read-only', but for a benign read tool the disclosure is solidly above minimal.
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, zero waste. The scope and field list are front-loaded, and the usage routing is appended as a clean tail. Every clause earns its place.
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 are covered elsewhere. The description complements it by naming the data source, the freshness stamping, the field set, and the market limit. For a single-parameter snapshot tool, nothing an agent needs to call it correctly 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% for the single 'coins' parameter, so the baseline is 3. The description reinforces the 1..25 bound ('for up to 25 markets') that the schema also states, but adds no distinct semantic beyond what the schema already documents.
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 specific action ('What is happening right now') with a concrete resource (live market snapshot) and enumerates exact fields returned (mark price, hourly funding, open interest, 24-hour notional, premium). The 'up to 25 markets' scope and the explicit contrast with daily tools distinguish it from siblings without opening any schema.
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 explicit selection guidance: 'Use this for "now" questions; the daily tools answer completed days only.' This states both when to use and when not to, pointing to the alternative category. No inference is required of the agent.
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 day: pick columns, an order_by field and top_n. Answers 'top markets by funding / open interest / returns on the latest day' and 'what percentile is BTC on open interest'. day defaults to the last complete day; scope defaults to crypto (HIP-3 markets track an underlying that closes, so their flow is not comparable); stat=percentile|zscore ranks within your visible markets; window_days recomputes the trailing-window fields; min_usd_volume_7d_avg keeps dust out of the ranking. Field names come from list_fields — never guess them, they are snake_case compound names; for a cut ('top decile by X') use screen_universe.
| Name | Required | Description | Default |
|---|---|---|---|
| day | No | The day to rank, `YYYY-MM-DD`, or `latest` (the default: the most recent complete day). | |
| 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 day's return. | |
| order_by | No | The field to rank by. Need not appear in `columns`. Defaults to the day'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 |
|---|---|---|
| rows | Yes | |
| stat | Yes | The ranking treatment actually applied: `raw`, `percentile` or `zscore`. |
| as_of | Yes | The UTC day the answer describes. |
| notes | Yes | |
| scope | Yes | The market population the ranking ran over. |
| source | Yes | `tessera_daily` — the answer is from completed days, not the live market. |
| row_count | Yes | How many markets are in `rows`. |
| truncated | Yes | True when `ranked_count` exceeds `row_count`. |
| coin_count | Yes | The number of markets in your visible slice on that day — the denominator every statistic and floor below is measured against. |
| ranked_count | Yes | How many markets had a value for the ranked field and passed the floor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses defaults (day, scope, stat, window_days, top_n), the rationale for scope exclusion, that percentile ranks within visible markets, and that window_days recomputes trailing fields with the response stating the window used. It also warns against guessing field names and points to list_fields. It doesn't explicitly label the operation as read-only, but the query semantics make that obvious; no destructive behavior is implied. This is strong transparency, though not exhaustive on potential errors or rate limits.
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 moderately long but dense with useful information. It front-loads the core purpose in the first sentence, then systematically covers defaults and special cases. Every sentence adds value, and the pointer to screen_universe is a crisp differentiator. It could arguably be tightened, but for a 10-parameter tool the length is justified.
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 tool of this complexity, the description covers the essential behavioral aspects: what it does, defaults, scope rationale, ranking semantics, window recomputation, volume filtering, and the critical rule about field names. The output schema covers the return structure, so the description needn't repeat that. It also positions the tool against screen_universe. Nothing critical is missing for an agent to use it 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?
The schema already documents all 10 parameters with 100% coverage, so the baseline is 3. The description adds meaningful context beyond the schema: it explains how 'day' defaults to the last complete day, why 'scope' matters for comparability, that 'stat' ranks within visible markets, and that 'min_usd_volume_7d_avg' filters dust. It also clarifies that column names must come from list_fields. This enriches the schema's descriptions, justifying a 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?
The description opens with a specific verb and resource: 'Rank the whole market on ONE completed day'. It then gives concrete example queries ('top markets by funding / open interest / returns on the latest day' and 'what percentile is BTC on open interest') that unambiguously distinguish it from siblings. It also explicitly names screen_universe as the alternative for percentile cuts, making the tool's niche unmistakable.
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 states exactly when to use this tool (single-day cross-sectional ranking) and when not to ('for a cut... use screen_universe'). It explains scope defaults and why hip3 markets are excluded ('their flow is not comparable'), and notes that percentile/zscore rank within visible markets. This is explicit guidance with a named alternative, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The daily series for one market or a few (max 10): one row per market per day over a trailing window, oldest first. Answers 'is this move backed by real flow' and 'how has positioning built up'. ending_day defaults to the last complete day. The whole answer is capped, so markets times window_days must stay inside the row cap; the response states the window it used.
| Name | Required | Description | Default |
|---|---|---|---|
| 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`. `day` and `coin` are always included. | |
| ending_day | No | The last day to include, `YYYY-MM-DD` or `latest`. | |
| window_days | No | Length of the trailing window in days, 1..365. Defaults to 7. |
| Name | Required | Description |
|---|---|---|
| rows | Yes | |
| as_of | Yes | The last day in the series. |
| notes | Yes | |
| scope | Yes | |
| source | Yes | |
| row_count | Yes | |
| truncated | Yes | |
| coin_count | Yes | The markets the series covers. |
| window_days | Yes | The window the trailing fields were computed over. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It covers ordering ('oldest first'), the default for ending_day ('defaults to the last complete day'), and the row cap behavior ('markets times window_days must stay inside the row cap; the response states the window it used'). This is transparent about limits and defaults, though it does not describe the return schema or error handling – but the output schema likely covers return structure.
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 compact (three sentences) and front-loaded with the core purpose and constraints. Every sentence contributes either the scope, the use-case context, or the cap/default behavior. No filler or 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 tool has 5 parameters and an output schema, the description covers the essential operational aspects: what the data looks like, the ordering, defaults, and the cap. It references list_fields for columns, which ties to sibling tools. It lacks explicit 'when not to use' guidance, but that is minor given the clarity of purpose and the presence of siblings that naturally differentiate.
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 each parameter already has a description. The description adds value by explaining the relationship between coins and window_days via the row cap, and by noting that ending_day defaults to the last complete day (which the schema only implies via default null). It also points to list_fields for column choices, giving context beyond the schema. This is a solid enhancement beyond the structured definitions.
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: 'The daily series for one market or a few (max 10): one row per market per day over a trailing window, oldest first.' It clearly distinguishes from cross-sectional or live tools by emphasizing time-series structure and the max-10 constraint. The purpose is unambiguous and immediately scopes the 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?
The description provides usage context by stating the questions it answers ('is this move backed by real flow' and 'how has positioning built up'), which implies when an agent would want it. It also mentions the row cap constraint, which helps the agent plan queries. It does not explicitly name alternatives or exclusions, but the guidance is clear enough for most use cases.
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 day with several conditions ANDed together. Conditions use op >, <, >=, <=, between, top_pct or bottom_pct; top_pct/bottom_pct are deciles of the markets you can see. 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 |
|---|---|---|---|
| day | No | The day to screen, `YYYY-MM-DD` or `latest`. | |
| 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 day'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 |
|---|---|---|
| rows | Yes | |
| as_of | Yes | |
| notes | Yes | |
| scope | Yes | |
| source | Yes | |
| row_count | Yes | |
| truncated | Yes | |
| coin_count | Yes | The number of markets in your visible slice on that day — the denominator the percentage conditions and the floor were measured against. |
| matched_count | Yes | How many markets met every condition. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that conditions are ANDed, that top_pct/bottom_pct are deciles of the visible market, and that missing fields cause conditions to fail. It does not mention pagination, rate limits, or the exact return shape, but the output schema exists and the description covers the key behavioral trait of missing-field handling. This is solid 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 compact and front-loaded: it states the core function in the first sentence, then lists supported operators, gives concrete example queries, and ends with a critical edge-case rule. Every sentence earns its place, and the structure is easy to scan.
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 tool's complexity (9 parameters, nested condition objects, multiple operators) and the presence of an output schema, the description is largely complete. It explains the AND semantics, the decile behavior, and the missing-field rule. It could mention the default day ('latest') or the default ordering, but those are already in the schema. The description covers the non-obvious behavioral aspects well.
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 all 9 parameters thoroughly. The description adds context about the AND semantics and the decile interpretation of top_pct/bottom_pct, which complements the schema. However, it doesn't add much beyond what the schema already provides for individual parameters, so a 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 the tool's purpose: screening the whole market on one completed day with multiple conditions ANDed together. It names the specific resource (market data) and the action (screen), and distinguishes it from siblings like query_cross_section by emphasizing the 'whole market' and 'ONE completed day' scope. The examples of supported conditions and the note about missing fields add further clarity.
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 explains when to use this tool: to answer multi-condition market-wide screening questions on a completed day, with examples like 'top-decile funding with bottom-decile open-interest change'. It doesn't explicitly name alternatives or say when not to use it, but the context signals and sibling names (e.g., query_cross_section, live_market) imply the distinction. The note that a market not reporting a field never satisfies a condition is a useful usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hyperliquid - 2 tools for perpetuals, options, and position data
Real-time & historical Hyperliquid/Lighter: L4/L2/L3, fills, funding, OI, liquidations, candles
Live prices, perps, prediction markets and a paper trading desk over one MCP.
Live Hyperliquid perps analytics for agents: funding, OI, whale prints, leaderboard, wallet risk.
Add one secure layer between your agents and this server.
