Tessera Analytics - Hyperliquid Market Intelligence

describe_dataset

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`asset`	Yes	Dataset name, as returned by `list_datasets`.

Output Schema

TableJSON Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 15, 2026

addedInput schema / description

Added value: +"Which dataset's dictionary to return."

changedInput schema / properties / asset / description

Previous value: -"Dataset name, e.g. `gold_ohlcv_1m`."New value: +"Dataset name, as returned by `list_datasets`."

changedInput schema / title

Previous value: -"AssetArg"New value: +"DatasetArg"

changedOutput schema / properties / cadence / description

Previous value: -"Granularity + partitioning, e.g. \"1-minute bars, partitioned per (coin, month)\"."New value: +"How frequently the data is sampled, e.g. \"1-minute bars\"."

changedOutput schema / properties / name / description

Previous value: -"Dataset name / asset key, e.g. `gold_ohlcv_1m`."New value: +"Dataset name, exactly as `list_datasets` reports it."

Changed1 schema field changedSep 3, 2026

changedInput schema / properties / asset / description

Previous value: -"Dataset name, e.g. `gold_positioning_funding_factors_1d`."New value: +"Dataset name, e.g. `gold_ohlcv_1m`."

Changed3 schema fields changedJul 10, 2026

addedOutput schema / $defs / ColumnGroup / properties / window

Added value: +{
+  "default": null,
+  "description": "Temporal window of this group's fields relative to the timestamp label:\none of `point_in_time`, `backward`, `forward`, `contemporaneous`,\n`static`. Null when the dataset-level `temporal.convention` covers them.",
+  "nullable": true,
+  "type": "string"
+}

addedOutput schema / $defs / Temporal

Added value: +{
+  "description": "The dataset's temporal contract — what the timestamp column marks and the\nlook-ahead-safety rules for joining. Mirror of the resolver's `temporal`\nblock (`semantic/__init__.py`).",
+  "properties": {
+    "convention": {
+      "description": "One-paragraph plain-English join / look-ahead contract.",
+      "type": "string"
+    },
+    "grain": {
+      "description": "Observation width, e.g. `1m`, `1h`, `1d`, `1mo`.",
+      "type": "string"
+    },
+    "label": {
+      "description": "What the label marks: one of `interval_start`, `interval_end`,\n`snapshot`, `forecast_target`.",
+      "type": "string"
+    },
+    "timestamp_field": {
+      "description": "Which column carries the label, e.g. `time`, `day`, `month_start`.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "grain",
+    "timestamp_field",
+    "label",
+    "convention"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / temporal

Added value: +{
+  "$ref": "#/$defs/Temporal",
+  "default": {
+    "convention": "",
+    "grain": "",
+    "label": "",
+    "timestamp_field": ""
+  },
+  "description": "Machine-readable timestamp/interval contract: what the label marks and\nhow to join without leaking the future. Defaulted so snapshots predating\nthe field still deserialize."
+}

Changed4 schema fields changedJul 7, 2026

addedOutput schema / properties / direct_answer

Added value: +{
+  "default": "",
+  "description": "40-60 word keyword-first lead answer — the definitional \"what is this\"\nblurb, and the strongest AI-citation extraction target. Defaulted for\nforward/backward compatibility with snapshots predating the field.",
+  "type": "string"
+}

addedOutput schema / properties / keywords

Added value: +{
+  "default": [],
+  "description": "Per-dataset discovery keywords (schema.org keywords on the web).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / seo_title

Added value: +{
+  "default": "",
+  "description": "Keyword-first SEO title tag (web `<title>`). Defaulted so older snapshots\nwithout the field still deserialize.",
+  "type": "string"
+}

addedOutput schema / properties / use_case

Added value: +{
+  "default": "",
+  "description": "One-line \"what you'd use it for\" (buyer-intent) copy.",
+  "type": "string"
+}

First observedJul 6, 2026

TDQS

A4.5/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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?