Skip to main content
Glama

getTokenOHLCV

Read-onlyIdempotent

Get historical USD OHLCV candles for one token over a time range, returned as a time-series array. The price and volume are computed across every pool the token trades in on the network (a volume-weighted price, and volume summed across those pools), not a single pair. Runs on the caller's own Dev, Pro or Enterprise API key, set as the Authorization header on the connection to this server; without one it returns DP401_API_KEY_REQUIRED and sends nothing upstream, and a free key gets 403. In either case fall back to getPoolOHLCV on the token's main pool, found with getTokenPools sorted by volume. Use for 'price history of this token' or 'USD chart for this token'; for a single pair's candles use getPoolOHLCV, and for the current price use getTokenDetails. Params: network (required); token_address (required); start (required; easiest as a relative offset from now such as '-24h', so you need not know today's date; also Unix seconds, RFC3339 or yyyy-mm-dd); end (optional, same formats); interval one of '1m','5m','10m','15m','30m','1h','6h','12h','24h' (default '24h'); limit (default 10, max 1000 candles). Dev plan history is limited to the last 30 days. There is no inversed parameter on this endpoint.

Input Schema

NameRequiredDescriptionDefault
endNoOPTIONAL: End time, same formats as start (e.g. '-1h')
limitNoOPTIONAL: Number of data points to retrieve (default: 10, max: 1000)
startYesREQUIRED: Start time. A relative offset from now is simplest and needs no knowledge of today's date: '-24h' (last 24 hours), '-7d', '-90m' (units s, m, h, d). Also accepts RFC3339 (e.g. '2024-01-01T00:00:00Z'), Unix epoch seconds and YYYY-MM-DD (treated as 00:00:00 UTC).
networkYesREQUIRED: Network ID from getNetworks (e.g., 'ethereum', 'solana')
intervalNoOPTIONAL: Interval granularity (default: '24h')24h
rationaleYesREQUIRED. 1-2 sentence rationale for this call (e.g. "User asked for X; calling Y to fetch Z"). Logged for MCP improvement, never shown to end users. No PII or secrets. See the server `instructions` field for the full convention and worked examples.
token_addressYesREQUIRED: Token contract address

Output Schema

NameRequiredDescriptionDefault
ohlcvYesUSD candles for the token across all its pools, ordered by time_open ascending.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • removedOutput schema / properties / ohlcv / items / additionalProperties
      Removed value: -true
    • addedOutput schema / properties / ohlcv / items / anyOf
      Added value: +[
      +  {
      +    "additionalProperties": true,
      +    "properties": {
      +      "close": {
      +        "type": [
      +          "number",
      +          "null"
      +        ]
      +      },
      +      "high": {
      +        "type": [
      +          "number",
      +          "null"
      +        ]
      +      },
      +      "low": {
      +        "type": [
      +          "number",
      +          "null"
      +        ]
      +      },
      +      "open": {
      +        "type": [
      +          "number",
      +          "null"
      +        ]
      +      },
      +      "time_close": {
      +        "description": "ISO 8601 timestamp of bucket close (inclusive at 23:59:59 for 24h).",
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "time_open": {
      +        "description": "ISO 8601 timestamp of bucket open.",
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "volume": {
      +        "description": "Trade volume in the bucket, in pair-quote units (or USD where applicable).",
      +        "type": [
      +          "number",
      +          "null"
      +        ]
      +      }
      +    },
      +    "type": "object"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / ohlcv / items / properties
      Removed value: -{
      -  "close": {
      -    "type": "number"
      -  },
      -  "high": {
      -    "type": "number"
      -  },
      -  "low": {
      -    "type": "number"
      -  },
      -  "open": {
      -    "type": "number"
      -  },
      -  "time_close": {
      -    "description": "ISO 8601 timestamp of bucket close (inclusive at 23:59:59 for 24h).",
      -    "type": "string"
      -  },
      -  "time_open": {
      -    "description": "ISO 8601 timestamp of bucket open.",
      -    "type": "string"
      -  },
      -  "volume": {
      -    "description": "Trade volume in the bucket, in pair-quote units (or USD where applicable).",
      -    "type": "number"
      -  }
      -}
    • removedOutput schema / properties / ohlcv / items / type
      Removed value: -"object"
  2. Added

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, so safety is covered. The description adds genuine value beyond that: auth requirements (own Dev/Pro/Enterprise key in Authorization header), failure modes (DP401_API_KEY_REQUIRED sends nothing upstream, 403 on free keys), and the Dev-plan 30-day history cap. This is strong supplemental context, though it stops short of return-shape or pagination detail (which the output schema covers).

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?

Scope and aggregation are front-loaded, then alternatives, then auth failure modes, then params – a logical ordering. It is dense and a touch run-on in the auth/fallback clause, but each sentence carries actionable information with little redundancy.

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?

For a 7-param tool with an output schema, the description covers purpose, aggregation semantics, auth prerequisites, failure recovery, plan limits, and all parameter edge notes. Return values are handled by the output schema, so nothing essential is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents all params. The description adds operational meaning beyond it: relative-offset advice for start ('-24h' so you needn't know today's date), the enumerated intervals with default, limit default/max, and the notable 'no inversed parameter' caveat. This goes slightly past the schema restatement.

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?

States a specific verb+resource ('Get historical USD OHLCV candles for one token over a time range') and immediately clarifies the aggregation scope (cross-pool VWAP + summed volume, not a single pair). It explicitly differentiates from siblings by naming getPoolOHLCV for single pairs and getTokenDetails for current price.

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 triggers ('price history of this token', 'USD chart'), names the alternatives with their selecting conditions (getPoolOHLCV for a single pair, getTokenDetails for current price), and even gives a fallback path via getTokenPools sorted by volume when auth fails.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources