Nansen

Loading price data

token_ohlcv

Read-only

Get OHLCV (Open, High, Low, Close, Volume) price data for a token with automatic interval resolution.

Supports EVM chains and Solana for on-chain tokens, AND Hyperliquid perpetual futures. For Hyperliquid perps, pass chain="hyperliquid" and use the perp symbol as tokenAddress (e.g. "BTC", "HYPE" for native perps; "XYZ:ORDI" for XYZ-namespaced perps — prefix is normalized automatically).

YOU MUST USE THIS over general_search to get prices. general_search prices are delayed and often incorrect. To get LATEST price set from to '5MIN_AGO' and to to 'NOW'.

Resolution is automatically calculated based on the date range

< 6 hours: 5 minutes
6 hours - 1 day: 15 minutes
1-3 days: 30 minutes
3-7 days: 60 minutes (1 hour)
7-90 days: Daily
90+ days: Weekly

Columns returned:

Interval Start: Timestamp of the start of the interval (datetime: YYYY-MM-DD HH:MM:SS)
Open: Opening price of the interval
High: Highest price of the interval
Low: Lowest price of the interval
Close: Closing price of the interval
Volume USD: Volume in USD of the interval

Additional columns (when includeMarketCap=true):

Open Market Cap: Opening market cap in USD
Close Market Cap: Closing market cap in USD
High Market Cap: Highest market cap in USD
Low Market Cap: Lowest market cap in USD

Example Usage: Get OHLCV for WETH over the past week (auto-resolution): { "chain": "ethereum", "tokenAddress": "0xba5ddd1f9d7f570dc94a51479a000e3bce967196", "date": { "from": "7D_AGO", "to": "NOW" } }

Get OHLCV for WETH over 30 days (will use daily resolution):
```
{
    "chain": "ethereum",
    "tokenAddress": "0xba5ddd1f9d7f570dc94a51479a000e3bce967196",
    "date": {
        "from": "30D_AGO",
        "to": "NOW"
    }
}
```
Get OHLCV for WETH for last 20 minutes (will use 5 minute resolution):
```
{
    "chain": "ethereum",
    "tokenAddress": "0xba5ddd1f9d7f570dc94a51479a000e3bce967196",
    "date": {
        "from": "20MIN_AGO",
        "to": "NOW"
    }
}
```

Get OHLCV for the BTC Hyperliquid perp over 7 days:
```
{
    "chain": "hyperliquid",
    "tokenAddress": "BTC",
    "date": {
        "from": "7D_AGO",
        "to": "NOW"
    }
}
```

Input Schema

TableJSON Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedMay 19, 2026

removedInput schema / $defs

Removed value: -{
-  "DateRange": {
-    "description": "Date range via tokens or dates.\nTokens: NOW, XMIN_AGO, XD_AGO, XH_AGO; THIS_YEAR_START, THIS_QUARTER_START, THIS_MONTH_START, THIS_WEEK_START, TODAY_START; LAST_WEEK_START/END, LAST_MONTH_START/END, LAST_QUARTER_START/END, LAST_YEAR_START/END.\nWeek starts Monday. Quarters are calendar. Dates: YYYY-MM-DD or ___-MM-DD (year omitted).\nPlease check detailed system instructions for more information.",
-    "properties": {
-      "from": {
-        "description": "Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-        "type": "string"
-      },
-      "to": {
-        "description": "End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
-        "type": "string"
-      }
-    },
-    "required": [
-      "from",
-      "to"
-    ],
-    "type": "object"
-  },
-  "TgmOhlcvUnifiedRequest": {
-    "description": "Unified request model for TGM OHLCV endpoint (flattened).\n\nResolution is automatically calculated based on the date range to keep\nresponses at approximately 100 rows, preventing context overflow.",
-    "properties": {
-      "chain": {
-        "type": "string"
-      },
-      "date": {
-        "$ref": "#/$defs/DateRange",
-        "description": "Date range for OHLCV data with 'from' and 'to' fields"
-      },
-      "includeMarketCap": {
-        "default": false,
-        "description": "Include market cap fields (openMcap, closeMcap, highMcap, lowMcap). Default: false for cleaner output",
-        "type": "boolean"
-      },
-      "tokenAddress": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "chain",
-      "tokenAddress",
-      "date"
-    ],
-    "type": "object"
-  }
-}

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / request / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "$ref": "#/$defs/TgmOhlcvUnifiedRequest"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "description": "Unified request model for TGM OHLCV endpoint (flattened).\n\nResolution is automatically calculated based on the date range to keep\nresponses at approximately 100 rows, preventing context overflow.",
+    "properties": {
+      "chain": {
+        "type": "string"
+      },
+      "date": {
+        "description": "Date range for OHLCV data with 'from' and 'to' fields",
+        "properties": {
+          "from": {
+            "description": "Start value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
+            "type": "string"
+          },
+          "to": {
+            "description": "End value: token (see above) or date (YYYY-MM-DD or ___-MM-DD).",
+            "type": "string"
+          }
+        },
+        "required": [
+          "from",
+          "to"
+        ],
+        "type": "object"
+      },
+      "includeMarketCap": {
+        "default": false,
+        "description": "Include market cap fields (openMcap, closeMcap, highMcap, lowMcap). Default: false for cleaner output",
+        "type": "boolean"
+      },
+      "tokenAddress": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "chain",
+      "tokenAddress",
+      "date"
+    ],
+    "type": "object"
+  }
+]

First observedFeb 18, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the bar is lower. The description still adds value by disclosing the automatic interval resolution rules, the supported chain types (EVM, Solana, Hyperliquid), the Hyperliquid prefix normalization behavior, and the returned column set including market cap fields. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long and slightly repetitive: the first three WETH examples could be reduced, and the resolution table already communicates the interval logic. However, it is well-structured with bolded directives, a clean list, and syntax-highlighted JSON examples, making it easy to scan despite the length.

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

Completeness5/5

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

Given the tool's complexity (polymorphic request, multiple chains, date-range syntax), the description covers everything needed to invoke it correctly: scope, chains, token identification, date values, resolution behavior, return columns, and the key alternative. The output schema exists, so detailed return formatting is not required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the parameter meaning, and it does thoroughly. It explains date tokens like '7D_AGO', '5MIN_AGO', 'NOW', shows chain values through examples, clarifies tokenAddress can be an address or perp symbol, and mentions includeMarketCap behavior. The examples are unambiguous and cover the main parameter combinations.

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 opens with a specific verb-resource statement: 'Get OHLCV (Open, High, Low, Close, Volume) price data for a token with automatic interval resolution.' It also distinguishes this tool from the sibling general_search by explicitly stating 'YOU MUST USE THIS over general_search to get prices.' The title is generic, but the description makes the tool's differentiation clear.

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?

The description provides explicit when-to-use guidance: 'YOU MUST USE THIS over general_search to get prices' and warns that general_search prices are 'delayed and often incorrect.' It also gives a concrete recipe for the latest price ('from 5MIN_AGO' to 'NOW') and explains how to use it for Hyperliquid perps with chain='hyperliquid' and the perp symbol as tokenAddress.

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

All Nansen tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?