Hyperliquid Market Data — OHLCV, Funding Rates & Positioning (Tessera)
Server Details
Hyperliquid perp market data for LLMs: OHLCV, funding, open interest, positioning & forecasts.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.3/5 across 6 of 6 tools scored.
Each tool serves a distinct purpose: dataset discovery (list_datasets), metadata (describe_dataset), partition listing (list_partitions), small-row reading (read_dataset), bulk download (get_download_url), and cross-sectional ranking (query_cross_section). No overlapping functionality.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., list_datasets, read_dataset). The naming is predictable and clear.
With 6 tools, the server covers the essential operations for market data access without being too sparse or overwhelming. Each tool adds distinct value.
The tool surface covers discovery, metadata, partition navigation, row-level and bulk data access, and a specialized cross-sectional query. Minor gaps exist (e.g., no direct date-range filtering or multi-coin time series query), but core workflows are supported.
Available Tools
6 toolsdescribe_datasetAInspect
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_positioning_funding_factors_1d`. |
Output 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`. |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output contents in detail (prose, every column's type, nullability, meaning). No annotations exist, so description carries full burden; it is sufficient for a read-only metadata operation, though could mention access requirements.
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, no wasted words. First sentence states purpose, second gives usage advice. Exceptionally concise and structured.
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?
With one parameter and an output schema, the description fully equips an agent to invoke the tool correctly. Provides usage context and output content summary.
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 concise description of the 'asset' parameter. The description does not add further semantics beyond what the schema already provides, meeting baseline expectations.
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 verb 'Get' and resource 'full data dictionary for one dataset', listing specific content (prose, column types, nullability, meaning). Distinguishes from siblings like list_datasets or 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?
Explicitly advises to use before read_dataset to choose columns. No exclusion criteria or alternative tools mentioned, but the guidance is clear and contextually appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_download_urlAInspect
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 | Yes | ||
| asset | Yes | ||
| month | Yes | Partition month, `YYYY-MM`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | Presigned Tigris URL for the full parquet partition. |
| expires_at | Yes | RFC3339 expiry. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions 'short-lived' but omits crucial details like URL expiration, authentication requirements, error behavior for missing partitions, or rate limits.
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 purpose, immediately followed by usage guideline, no unnecessary words.
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?
Covers core purpose and usage guidance but lacks detail on error scenarios, URL format, and lifespan beyond 'short-lived'; output schema exists but is not described.
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 description coverage is only 33% (month only). Description adds that asset, coin, month define a partition but does not clarify allowed values or formats for asset and coin.
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 it returns a short-lived presigned URL for downloading a specific partition, and distinguishes it from read_dataset for bulk access beyond its row cap.
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 'Use for bulk access beyond read_dataset's row cap,' providing clear when-to-use guidance and implicitly naming an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_datasetsAInspect
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 | |||
Output Schema
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the purpose but does not detail behavioral aspects like return format or side effects. Since the tool is a simple listing with no parameters and likely no side effects, the minimal description is adequate but could be improved.
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 a single sentence with no extraneous words. It effectively communicates the tool's purpose and usage hint in a compact form.
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 no parameters and an output schema, the description is sufficient for a discovery tool. It states what it does and that it should be called first, covering the essential context for an agent.
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?
There are no parameters (schema coverage 100%), and the description adds value by specifying what the output includes (summaries and plan). Baseline for zero parameters is 4, and the description meets that.
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 'available Tessera Analytics gold datasets with summaries and the plan (free/pro) each requires.' It also says 'Call first to discover what's available,' which distinguishes it from sibling tools that operate on specific 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 provides explicit context by saying 'Call first,' implying this should be invoked before other dataset-specific tools. It lacks explicit when-not-to-use or alternative conditions, but the guidance is clear for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_partitionsAInspect
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`). |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: default summary mode, pagination via limit/offset, filtering by coin/month, and access constraints ('the caller’s plan can read'). It could add a note about read-only nature, but is already transparent.
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, each earning its place: first states purpose, second explains default behavior and alternative mode, third lists filters. No redundancy or fluff.
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 100% schema coverage and an existing output schema, the description provides all necessary context: two usage modes, filtering, pagination, and intended use case. No gaps.
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?
All 6 parameters have schema descriptions (100% coverage), but the description adds context beyond the schema by explaining the summary default, pagination mechanics, and the purpose of filters in plain language.
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 'List a dataset’s (coin, month) partitions' with specific verb and resource, and distinguishes from sibling tools like read_dataset by noting its use for choosing valid partitions.
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 use case 'Use to choose a valid coin/month for read_dataset' and explains the default summary mode versus full enumeration, but does not explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_cross_sectionAInspect
Rank 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. |
Output Schema
| 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 |
Tool Definition Quality
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 explains the tool's behavior (ranking, single call, parameter defaults) and the fact that it replaces multiple read_dataset calls. It does not explicitly state read-only or non-destructive nature, but the context of querying implies it. A minor improvement would be to mention that it's a read operation.
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 two sentences: first sentence states the main function concisely, second sentence lists key parameters and provides the alternative. It is front-loaded and every sentence earns its place, with no fluff.
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 that the schema has full parameter descriptions, an output schema exists, and the tool is a straightforward ranking operation, the description is complete. It covers the input parameters in context and the usage scenario, leaving no significant gaps.
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?
The description adds significant meaning beyond the schema, which already has 100% coverage. It explains the context for each parameter (e.g., order_by is a numeric column, day can be 'latest', top_n defaults to 20, descending defaults to true, coins restricts to specific coins and drops those outside plan). This helps the agent understand parameter usage.
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's purpose: ranking coins in a daily cross-section dataset. It uses a specific verb ('Rank'), resource ('all coins for one day of a daily cross-section dataset'), and distinguishes from the sibling tool read_dataset by explicitly calling out the difference.
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 says when to use this tool (for ranking all coins in a single call) and when not to use it ('For a single coin's series use read_dataset'). It also contrasts with the alternative approach of fanning out read_dataset, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_datasetAInspect
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 | Yes | Coin symbol, e.g. `BTC`. | |
| 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| coin | Yes | |
| 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). |
Tool Definition Quality
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 discloses defaults, limits (max 1000), recommended columns, and the alternative for full data. This is sufficient for a read operation.
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 are front-loaded with the main purpose, each adding meaningful detail without redundancy. Could be slightly more structured but is 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 tool's complexity (6 params, no annotations, output schema present), the description covers default behavior, limits, column recommendations, and an alternative tool. It does not explain return values, but the output schema exists and the rules allow that.
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?
The input schema has 100% coverage, but the description adds value by explaining defaults, limit constraints, and prompting the use of describe_dataset for columns. This goes beyond what the schema provides.
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 verb 'Read' and the resource 'actual data rows from one (asset, coin, month) partition.' It distinguishes from siblings like get_download_url, which is for whole partitions.
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?
Provides clear context on default behavior (latest 200 rows), parameter usage (columns, limit), and mentions alternative get_download_url for whole partitions. However, it lacks explicit when-not-to-use guidance for other siblings like describe_dataset or query_cross_section.
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.
Discussions
No comments yet. Be the first to start the discussion!