Hyperliquid perp market data for LLMs: OHLCV, funding, open interest, positioning & forecasts.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 6 of 6 tools scored.
Each tool serves a distinct purpose: schema discovery (describe_dataset), bulk download (get_download_url), dataset listing (list_datasets), partition enumeration (list_partitions), cross-sectional ranking (query_cross_section), and row-level data access (read_dataset). No two tools overlap in functionality.
All tool names follow a consistent snake_case verb_noun pattern (e.g., describe_dataset, list_partitions, read_dataset). The verbs are appropriately descriptive and the naming is uniform across the set.
With 6 tools, the server is well-scoped for its purpose of providing market data access. The number is neither too few to be useful nor too many to manage, fitting comfortably within the optimal 3-15 range.
The tool set covers discovery, schema, reading, bulk download, and cross-sectional queries. A minor gap is the lack of a dedicated tool to retrieve a single coin's time series across multiple months without downloading entire partitions, but the existing tools still enable this workflow.
describe_datasetAInspectGet 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_positioning_funding_factors_1d`. |
| 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?
No annotations are provided, so the description carries the full burden. It accurately describes the output as a full data dictionary with prose and column details, indicating a read-only metadata operation. It does not mention any destructive behavior or limitations, but the context is sufficient for a simple metadata 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?
The description consists of two succinct sentences: the first explains purpose and output, the second provides usage guidance. Every word serves a purpose with no 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's simplicity (single parameter, output schema exists), the description covers all necessary aspects: what it does, what it returns, and when to use it. No gaps are apparent.
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 parameter description for 'asset'. The description adds value by linking the parameter to the tool's purpose (use before read_dataset) and explaining what the result contains, though it does not add new details about the parameter itself.
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 retrieves the full data dictionary for a dataset, specifying details like column type, nullability, and plain-English meaning. It distinguishes from sibling tools like read_dataset (which reads actual data) and list_datasets (which lists available datasets).
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 advises using this tool before read_dataset to choose columns, providing clear when-to-use guidance and implicitly contrasting with the alternative of directly reading data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_download_urlAInspectReturn 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_datasetsAInspectList 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_partitionsAInspectList 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.
query_cross_sectionAInspectRank all coins for one day of a daily cross-section dataset (one row per coin per day, e.g. gold_positioning_funding_factors_1d) in a single call. Pass order_by (a numeric column), day (YYYY-MM-DD or "latest"), optional top_n (default 20), descending (default true), columns, and coins. Replaces fanning out read_dataset per coin. For a single coin's series use read_dataset.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | UTC day to rank, `YYYY-MM-DD`, or `"latest"` for the newest available day. | |
| asset | Yes | Dataset name. Must be a daily coin cross-section (one row per coin per `day`), e.g. `gold_positioning_funding_factors_1d`. | |
| coins | No | Optional: restrict to these coins. Coins outside the caller's plan are dropped. Omit to rank every coin the plan allows. | |
| top_n | No | Max coins to return (clamped to 1000). Defaults to 20. | |
| columns | No | Extra columns to include per row (besides `coin`, `day`, and `order_by`). Omit to return every column. | |
| order_by | Yes | Numeric column to rank coins by, e.g. a `factor_*` column. Call `describe_dataset` to see the options. | |
| descending | No | Sort direction. Defaults to true — highest `order_by` first. |
| Name | Required | Description |
|---|---|---|
| day | Yes | The day actually ranked (resolved when `day="latest"`), `YYYY-MM-DD`. |
| note | No | Advisories: latest-day resolution, coins with no row that day (coverage varies by day), coins excluded for a null/non-numeric `order_by`, and any partitions skipped on a read error. |
| rows | Yes | One object per coin, ranked; each includes `coin`, `day`, `order_by` and any requested `columns`. |
| asset | Yes | |
| columns | Yes | Columns present in each returned row. |
| order_by | Yes | |
| coin_count | Yes | Number of coins ranked (rows returned). |
| descending | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes a read/query operation but does not explicitly state it is read-only, or mention any side effects, authorization needs, or rate limits. However, the nature of ranking implies no destructive behavior, so it is minimally 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?
Three sentences, front-loaded with the primary action. No redundant information; every sentence contributes to clarity and differentiation.
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 (7 params, output schema exists), the description covers the core use case, parameter highlights, and relationship to read_dataset. It does not explain output format but that is covered by output schema. Could mention that ranking is deterministic or pagination details, but overall sufficient.
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 descriptions. The description adds value by explicitly stating defaults for top_n (20) and descending (true) that are not listed as defaults in the schema (schema shows null). It also summarizes the role of each parameter, complementing 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 clearly states the tool ranks all coins for one day in a cross-section dataset, using a specific verb and resource. It distinguishes itself from sibling tool read_dataset by noting that this replaces fanning out multiple calls and directing users to read_dataset for single-coin series.
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 (for cross-section ranking) and when not to (for single-coin series, use read_dataset). Also implies efficiency gains over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_datasetAInspectRead 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 datasets (e.g. `gold_wallet_flow_1mo`) that have no coin dimension. | |
| asset | Yes | Dataset name, e.g. `gold_positioning_funding_factors_1d`. | |
| 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?
With no annotations, the description carries the full burden. It discloses default row count, maximum limit, and that columns should be used to avoid wide results. It implicitly conveys read-only behavior. It could mention pagination or ordering behavior but is sufficient.
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, no fluff. The main action is front-loaded. Every sentence adds value: first states purpose and default, second explains parameter usage, third points to alternative. Highly efficient.
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 but signaled), the description does not need to explain return values. It covers defaults, limits, and when to use an alternative. For a read tool with 6 parameters and high schema coverage, this is complete.
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%, baseline 3. The description adds meaning beyond schema: explains that limit defaults to 200 but can go up to 1000, that columns narrow the output, and that order defaults to latest. This helps an agent decide parameter values.
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 reads actual data rows from a specific partition identified by asset, coin, and month. It distinguishes itself from sibling tools like get_download_url (for whole partitions) and describe_dataset (for schema). The verb 'read' is specific and the resource scope is explicit.
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 explicit guidance: defaults to latest 200 rows, limit clamped to 1000, recommended to use columns to limit width, and explicitly directs to get_download_url for whole partitions. It does not leave ambiguity about when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!