Hyperliquid Market Data — OHLCV, Funding Rates & Positioning (Tessera)

describe_dataset

Get the full data dictionary for one dataset: prose plus every column's type, nullability and plain-English meaning. Use before read_dataset to choose columns.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`asset`	Yes	Dataset name, e.g. `gold_ohlcv_1m`.

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Dataset name / asset key, e.g. `gold_ohlcv_1m`.
`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	Granularity + partitioning, e.g. "1-minute bars, partitioned per (coin, month)".
`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. Dates show when Glama detected each change.

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.4/5.0

Behavior3/5

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

With no annotations, the description carries the burden—and it largely succeeds: it makes clear the output is a data dictionary with both prose and schema-level detail, and positions the tool inside a read-oriented flow. It doesn't go into output volume, cost, or side effects, but for a read-only introspection tool, the practical hazard (returning a large definition) is implied by content. The lack of an explicit "read-only, no side effects" statement is a minor gap, not a contradiction.

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, front-loaded with the main verb phrase "Get the full data dictionary for one dataset," then the payload detail, then the placement instruction. Every clause earns its place, no redundancy with the schema.

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

Completeness4/5

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

Given the output schema exists and the tool is simple (one param, read-only nature implied), the description is nearly complete. It doesn't explicitly state that output is large, but that is evident from "full data dictionary." A fully complete definition would add that the tool guarantees column-order fidelity or returns empty results for unknown dataset names, but neither is essential to call it correctly.

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% (the single parameter asset is described as a dataset name with a concrete example), so the schema already does the heavy lifting. The description adds useful context that the parameter values correspond to the dataset catalog entries listed by list_datasets, and by naming the resource it clarifies what values are valid. That is meaningful additive meaning above the schema.

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 has a specific verb-resources pairs with: "Get the full data dictionary for one dataset (a dictionary describes: the prose and every column's type, nullability and meaning this also notes its contents purpose. The sole distinguishing dimension of what it returns doesn't apply); it clearly names the resource scope too, a definite indicator of iteration accessible through fine content.

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 states an explicit precondition and where to use it: "Use before read_dataset to choose columns." It gives one alternative action and its condition, which is exactly what usage guidance should do — the tool is placed within a workflow and contrasted with its sibling.

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

All Hyperliquid Market Data — OHLCV, Funding Rates & Positioning (Tessera) tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation5/5

Each tool serves a clearly distinct role in the data access workflow: discovering datasets, understanding schema, listing partitions, reading sample rows, and downloading full partitions. There is no meaningful overlap, and any potential overlap between read_dataset and get_download_url is explicitly disambiguated by row-cap versus full-bulk access.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: describe_dataset, list_datasets, list_partitions, read_dataset, get_download_url. The pattern is predictable and makes the purpose of each tool immediately understandable.

Tool Count5/5

Five tools is a well-scoped size for a market data access server. Each tool covers a necessary step in the user journey without redundancy or unnecessary surface area.

Completeness5/5

The tool set forms a complete workflow: discover available datasets, understand their schema, inspect available partitions, read bounded samples, and download full partitions for bulk access. There are no obvious gaps or dead ends for the stated market data purpose.

Resources

Need Help?