Hyperliquid perp market data for LLMs: OHLCV, funding, open interest, positioning & forecasts.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Dataset name, e.g. `gold_ohlcv_1m`. |
| 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. |
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.
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.
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.
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.
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.
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.
Return a short-lived presigned URL to download the full parquet for one (asset, coin, month) partition. Use for bulk access beyond read_dataset's row cap.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | Coin symbol, e.g. `BTC`. Omit for market-wide datasets that have no coin dimension. | |
| asset | Yes | ||
| month | Yes | Partition month, `YYYY-MM`. |
| Name | Required | Description |
|---|---|---|
| url | Yes | Presigned Tigris URL for the full parquet partition. |
| expires_at | Yes | RFC3339 expiry. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description adds behavioral context: 'short-lived presigned URL' indicates temporal and access properties. It doesn't detail error handling or authentication, but the core behavior is clear.
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 concise sentences: first defines purpose and output, second gives usage guidance. No wasted words, information is front-loaded.
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?
Tool is simple with 3 params and output schema; description covers purpose, usage context, and parameter grouping. Lacks details like expiration duration or error cases, but sufficient for a URL retrieval tool.
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?
Description groups parameters (asset, coin, month) into a partition concept, adding meaning beyond schema. It also notes that coin can be omitted for market-wide datasets, providing practical guidance.
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?
Description clearly states the specific verb (return) and resource (short-lived presigned URL for a partition), and distinguishes from siblings like read_dataset by specifying its use case for bulk access.
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?
Explicitly states when to use this tool ('Use for bulk access beyond read_dataset's row cap'), providing clear context and an alternative tool. No exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the available Tessera Analytics gold datasets with summaries and the plan (free/pro) each requires. Call first to discover what's available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| datasets | Yes | |
| your_tier | Yes | The caller's own plan (`free` or `pro`). Datasets whose `tier` is `pro` while this is `free` are visible for discovery but require an upgrade to read. |
| generated_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behaviors. It correctly describes a read-only listing with summaries and plan, but lacks details on data freshness, access restrictions, or rate limits. Adequate for a simple listing 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?
Two concise sentences, front-loaded with action and output description. No redundant words, every sentence serves a purpose.
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?
Adequate for a simple discovery tool with output schema. Describes purpose, output, and entry-point nature. Minor gap: no mention of authentication or data source.
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?
No parameters (0 params, 100% schema coverage). Description adds value by specifying output content (summaries, plan), which helps the agent understand what will be returned beyond 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?
Clearly states it lists available Tessera Analytics gold datasets with summaries and plan requirements. Verb 'List' and specific resource distinguish it from siblings like describe_dataset or get_download_url.
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?
Explicitly says 'Call first to discover what's available', establishing it as the entry point. Does not specify when not to use or compare to alternatives, but the instruction implies priority.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a dataset's (coin, month) partitions the caller's plan can read. Defaults to a compact SUMMARY (coin/month counts, month range, totals) — pass summary=false to enumerate (paginated via limit/offset). Filter with coin and/or month. Use to choose a valid coin/month for read_dataset.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | Optional: only partitions for this coin, e.g. `BTC`. | |
| asset | Yes | Dataset name, e.g. `gold_funding_1h`. | |
| limit | No | Full mode only (`summary=false`): max partitions to return (clamped to 1000). Defaults to 200. | |
| month | No | Optional: only partitions for this month, `YYYY-MM`. | |
| offset | No | Full mode only (`summary=false`): partitions to skip, for pagination. Defaults to 0; pass the previous response's `next_offset` for the next page. | |
| summary | No | Return compact coverage stats (coin/month counts, range, totals) instead of every `(coin, month)` row. Defaults to **true** — the full cross-product is hundreds of rows for some datasets. Set `false` to enumerate (paginated via `limit`/`offset`). |
| Name | Required | Description |
|---|---|---|
| note | No | Set when the dataset exists but requires a plan the caller doesn't have. |
| asset | Yes | |
| summary | No | Present in summary mode (the default): compact coverage stats. |
| your_tier | Yes | |
| partitions | Yes | Present in full mode (`summary=false`): this page of partitions. Empty in summary mode. |
| next_offset | No | Full mode only: pass as `offset` to fetch the next page, or null when the listing is exhausted. |
| generated_at | Yes | |
| total_matching | Yes | Full mode only: total partitions matching the filter, before pagination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully carries the behavioral burden. It discloses that partitions depend on the caller's plan, defaults to summary mode due to potentially large results, and explains pagination via limit/offset. It does not mention error conditions or rate limits, but covers the essential behavior well.
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, each serving a distinct purpose: first states the core function, second details the output modes, third explains filtering and usage. No unnecessary words 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 presence of an output schema (not shown), the description adequately covers return values (summary stats vs. partition list) and pagination. It explains the two modes and filtering. It is slightly incomplete in not addressing edge cases like empty results or errors, but overall comprehensive.
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 baseline is 3. The description adds significant value beyond the schema by explaining the default behavior of summary (true), why summary is the default (hundreds of rows), and that limit/offset only apply in full mode. It clarifies the intent of coin and month filters.
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 lists (coin, month) partitions of a dataset that the caller's plan can read. It provides two modes (summary and enumeration) and explicitly mentions its use case: 'Use to choose a valid coin/month for read_dataset.' This differentiates it from sibling tools like list_datasets and read_dataset.
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 clear context on when to use the tool, including filtering by coin/month and the two output modes. It states the primary use case ('choose a valid coin/month for read_dataset'). However, it does not explicitly mention when not to use it or compare with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read actual data rows from one (asset, coin, month) partition. Defaults to the latest 200 rows. Pass columns to limit width and limit (max 1000) to limit rows — a partition can be tens of thousands of rows. For a whole partition use get_download_url.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | Coin symbol, e.g. `BTC`. Omit for market-wide (coinless) datasets that have no coin dimension — none are currently published. | |
| asset | Yes | Dataset name, e.g. `gold_ohlcv_1m`. | |
| limit | No | Max rows to return (clamped to 1000). Defaults to the latest 200. | |
| month | Yes | Partition month, `YYYY-MM`. | |
| order | No | Which end of the partition to read. `latest` (default) returns the most recent rows — usually what you want for a "what's the current…" question. | |
| columns | No | Columns to return. Strongly recommended — omitting returns every column, which is wide for some datasets. Use `describe_dataset` to see columns. |
| Name | Required | Description |
|---|---|---|
| coin | No | Coin symbol; absent for market-wide datasets. |
| note | No | Guidance when the result was capped, or other advisories. |
| rows | Yes | One JSON object per row. |
| asset | Yes | |
| month | Yes | |
| columns | Yes | The columns actually returned, in order. |
| row_count | Yes | |
| truncated | Yes | True when `total_rows_in_partition` exceeds the rows returned. |
| total_rows_in_partition | Yes | Total rows in the partition (before the row cap / limit). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the disclosure burden. It adds real behavioral context: default of latest 200 rows, a 1000-row cap, and the scale warning that a partition can be tens of thousands of rows. It stops short of describing empty-result or error behavior, but the output schema covers the return shape.
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 sentences, front-loaded with the core verb+resource, then defaults and bounds, then the sibling route. Every sentence earns its place; no filler or repetition of the schema.
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 read tool with two required params, 100% schema coverage, and an output schema, the description covers everything an agent needs to invoke correctly: what it reads, defaults, bounds, and when to switch to get_download_url. Return values are already covered by the output schema.
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. The description adds value above baseline by explaining why limit matters (partition scale), the default row count, and that omitting columns returns a wide result — reinforcing the columns and limit parameters with rationale.
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 verb and resource: 'Read actual data rows from one (asset, coin, month) partition.' This clearly differentiates it from siblings — describe_dataset (metadata), list_datasets/list_partitions (enumeration), and get_download_url (whole-file download), which is explicitly named.
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?
Contains an explicit routing rule: 'For a whole partition use get_download_url.' It also provides invocation guidance — 'Pass columns to limit width and limit (max 1000) to limit rows — a partition can be tens of thousands of rows' — so an agent knows how to size requests correctly.
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. Dates show when Glama detected each change.
No tool schema history has been recorded yet.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Crypto perps data for AI agents: funding rates, open interest, liquidations, order book, CVD.
Live crypto market signals for AI agents: perp liquidations, funding, OI positioning, yield, FX.
Hyperliquid - 2 tools for perpetuals, options, and position data
Real-time & historical Hyperliquid/Lighter: L4/L2/L3, fills, funding, OI, liquidations, candles
Add one secure layer between your agents and this server.
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.
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.
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.
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.
