Tessera Analytics - Hyperliquid Market Intelligence

Screen universe

screen_universe

Read-only

Screen the whole market on ONE completed interval with several conditions ANDed together. Pick bar (1d, the default, or 1h for completed hours; the anonymous trial 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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "conditions": "<conditions>"
    },
    "name": "screen_universe"
  }
}

Input Schema

Name	Required	Description
`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`.

Output Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 5, 2026

addedOutput schema / properties / bar_age_hours

Added value: +{
+  "format": "double",
+  "type": "number"
+}

addedOutput schema / properties / published_at

Added value: +{
+  "nullable": true,
+  "type": "string"
+}

changedOutput schema / required

Previous 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"
+]

Changed2 schema fields changedOct 27, 2026

changedInput schema / properties / max_results / description

Previous value: -"How many markets to return, 1..50. Defaults to 25."New value: +"How many markets to return, 1..100 (values outside are clamped to the\nnearest bound and the response says so). Defaults to 25."

changedInput schema / properties / min_usd_volume_7d_avg / description

Previous value: -"Drop markets below this average daily traded notional over the window."New value: +"Drop markets whose average **daily** traded notional over the trailing\nwindow is below this value, in USD/day at either bar — a floor chosen at\n`1d` means the same thing at `1h`."

Changed4 schema fields changedOct 14, 2026

addedInput schema / $defs / ConditionArg / properties / column / default
```
Added value: +null
```

changedInput schema / $defs / ConditionArg / properties / column / description

Previous value: -"The field to test, from `list_fields`."New value: +"The field to test, from `list_fields`. Accepted under either name —\n`field`, which is what every other argument on this surface calls it, or\nits original `column`. Validated as present rather than required by the\nschema, so a condition that names no field is rejected by name below\ninstead of by a deserializer message no caller can act on."

addedInput schema / $defs / ConditionArg / properties / column / nullable
```
Added value: +true
```

changedInput schema / $defs / ConditionArg / required

Previous value: -[
-  "column",
-  "op",
-  "value"
-]New value: +[
+  "op",
+  "value"
+]

Changed2 schema fields changedOct 8, 2026

changedInput schema / properties / bar / description

Previous value: -"`1d` (the default) for completed UTC days, `1h` for the most recent\ncompleted UTC hour."New value: +"`1d` (the default) for completed UTC days, `1h` for completed UTC hours.\nAn interval, at either grain, is stamped by the instant it **closes** —\nan hourly `…T09:00:00Z` is the hour that ended at 09:00."

changedInput schema / properties / day / description

Previous value: -"The day or hour to screen: `YYYY-MM-DD` or `latest` at `bar: 1d`, a\ncompleted `YYYY-MM-DDTHH:00:00Z` or `latest` at `bar: 1h`."New value: +"The day or hour to screen: `YYYY-MM-DD` or `latest` at `bar: 1d`, a\ncompleted `YYYY-MM-DDTHH:00:00Z` (the hour that *ended* there) or\n`latest` at `bar: 1h`."

Changed9 schema fields changedOct 2, 2026

addedInput schema / properties / bar

Added value: +{
+  "default": null,
+  "description": "`1d` (the default) for completed UTC days, `1h` for the most recent\ncompleted UTC hour.",
+  "nullable": true,
+  "type": "string"
+}

changedInput schema / properties / day / description

Previous value: -"The day to screen, `YYYY-MM-DD` or `latest`."New value: +"The day or hour to screen: `YYYY-MM-DD` or `latest` at `bar: 1d`, a\ncompleted `YYYY-MM-DDTHH:00:00Z` or `latest` at `bar: 1h`."

changedInput schema / properties / order_by / description

Previous value: -"The field to rank the matches by. Defaults to the day's traded notional."New value: +"The field to rank the matches by. Defaults to the interval's traded\nnotional."

addedOutput schema / properties / bar

Added value: +{
+  "description": "The grain this answer was computed at: `1d` or `1h`.",
+  "type": "string"
+}

removedOutput schema / properties / coin_count

Removed value: -{
-  "description": "The number of markets in your visible slice on that day — the\ndenominator the percentage conditions and the floor were measured\nagainst.",
-  "format": "int64",
-  "type": "integer"
-}

addedOutput schema / properties / eligible_count

Added value: +{
+  "description": "Markets left after your explicit market filter and any\ntraded-notional floor — the population the percentage conditions were\nmeasured against.",
+  "format": "int64",
+  "type": "integer"
+}

changedOutput schema / properties / matched_count / description

Previous value: -"How many markets met every condition."New value: +"Markets that met every condition."

addedOutput schema / properties / visible_count

Added value: +{
+  "description": "Markets in your plan's slice with a row on this interval, before any\nfilter you passed.",
+  "format": "int64",
+  "type": "integer"
+}

changedOutput schema / required

Previous value: -[
-  "source",
-  "as_of",
-  "scope",
-  "coin_count",
-  "matched_count",
-  "row_count",
-  "truncated",
-  "rows",
-  "notes"
-]New value: +[
+  "bar",
+  "source",
+  "as_of",
+  "scope",
+  "visible_count",
+  "eligible_count",
+  "matched_count",
+  "row_count",
+  "truncated",
+  "rows",
+  "notes"
+]

AddedSep 15, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With readOnlyHint already declaring the safety profile, the description adds real semantics: deciles are computed after the liquidity floor so they reflect the eligible population, and a market that doesn't report a field never satisfies a condition on it (null/absence handling). It does not cover result ordering limits or rate/scope caveats beyond what the schema states.

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

Conciseness5/5

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

Four dense sentences, front-loaded with the operation and interval constraint, then operators, then decile/floor interaction, then the null-field rule. No filler and no repetition of schema text beyond what carries semantic weight.

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

Completeness5/5

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

For a 10-parameter screening tool with an output schema and full schema descriptions, the description covers the non-obvious parts: interval definition, operator set, decile population, and missing-field behavior. The remaining details (max_results clamping, ordering defaults) are already handled in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description still adds cross-parameter meaning the schema doesn't state on its own — that the USD/day liquidity floor is applied before top_pct/bottom_pct and is bar-invariant. Bar values and the 1d default are restated from the schema rather than extending it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('screen the whole market') and pins the scope to 'ONE completed interval' with conditions ANDed, which separates it from multi-interval or series-style queries. It never names a sibling (e.g. query_cross_section) to route against, so differentiation is implied 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete usage contexts ('top-decile funding with bottom-decile open-interest change', 'open interest rising faster than volume') and clarifies which bar to pick, including the anonymous-trial restriction to 1d. Missing explicit when-not guidance or a named alternative for multi-interval or single-market lookups.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Tessera Analytics - Hyperliquid Market Intelligence tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?