Nansen

Loading price data

token_ohlcv

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. Dates show when Glama detected each change.

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

A5/5.0

Behavior5/5

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

No annotations exist, so the description carries full responsibility. It discloses automatic interval resolution rules, supported chains, perp symbol normalization, output columns, market cap behavior, and even the rationale for auto-resolution (keeping responses at ~100 rows). This is deep behavioral transparency with no contradictions.

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

Conciseness5/5

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

Although long, the description is well-structured: purpose statement, support details, usage directive, resolution table, column list, and examples. Every section earns its place for a tool with multiple chains and auto-resolution, and the front-loaded main purpose enables quick understanding.

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?

The tool is complex (multi-chain, auto-resolution, market cap fields), and the description covers all critical aspects: what it does, when to use it, how to pass parameters, what output columns to expect, and even a warning about an alternative. The output schema exists, so the documented columns are a bonus. No essential information is missing.

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% for the top-level 'request' property. The description compensates thoroughly by explaining chain, tokenAddress, date.from/to, includeMarketCap, and providing concrete date token examples ('7D_AGO', 'NOW', '5MIN_AGO'). This adds substantial meaning beyond the minimal schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get OHLCV') and resource ('price data for a token'), and clearly distinguishes from sibling `general_search` by stating it must be used over it for prices. The scope (EVM chains, Solana, Hyperliquid perps) is immediately 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?

Provides explicit when-to-use guidance: 'YOU MUST USE THIS over general_search to get prices' because `general_search` prices are 'delayed and often incorrect'. Also includes specific instructions for Hyperliquid perps and multiple examples covering different chains and date ranges, making the invocation context unmistakable.

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

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0

Disambiguation4/5

Most tools have clearly distinct purposes (address vs token vs prediction market vs transaction). Overlapping tools like token_discovery_screener and nansen_score_top_tokens, or address_counterparties and address_related_addresses, are explicitly disambiguated with detailed usage guidance. A few tools (token_flows vs token_recent_flows_summary) require careful reading but are still distinguishable.

Naming Consistency4/5

Tool names consistently use snake_case with resource prefixes (address_*, token_*, prediction_market_*). Minor deviations include general_search, growth_chain_rank, and nansen_score_top_tokens, and some names like smart_traders_and_funds_perp_trades are verbose but still follow the pattern.

Tool Count3/5

38 tools is a heavy surface, but it matches Nansen's broad domain covering address analytics, token intelligence, prediction markets, and Hyperliquid perps. The count is on the high end and may overwhelm agents, but each tool appears to serve a distinct function within a reasonably scoped analytics platform.

Completeness5/5

The tool surface is comprehensive: address lifecycle (portfolio, transactions, balances, counterparties, PnL), token analytics (price, OHLCV, indicators, flows, transfers, holders, discovery), prediction markets (lookup, orderbook, trades, top holders, PnL), and specialized features (smart money, chain rankings). No obvious dead ends or missing critical operations are apparent.

Resources

Need Help?