Skip to main content
Glama

get_ohlcv

Read-onlyIdempotent

Daily OHLCV (open, high, low, close, volume) history for one crypto asset over the requested lookback (1-3650 days, default 30). More than 1,000 daily bars come back as weekly bars instead (interval says which; daily_bars says how many days were rolled up). Use it when the user asks for price history, chart data, or wants to reason about past price movement rather than the current spot. Supply quote_token and market_data_venue together to select an exact market, or provider for an external source; omit these overrides to select a Mangrove market.

[Access: pay 0.01 USDC via x402 (PAYMENT-SIGNATURE header) OR authenticate with an API key. An x402-capable client will auto-pay; API-key clients pay nothing per call.]

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "symbol": "<symbol>"
    },
    "name": "get_ohlcv"
  }
}

Input Schema

NameRequiredDescriptionDefault
symbolYesAsset symbol, e.g. BTC or ETH.
providerNoOptional upstream override; omitted uses the existing server default.
quote_tokenNoQuote currency of the requested market.
lookback_daysNoNumber of days of history to request.
market_data_venueNoExact venue of the requested market.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered; the description's real additions are the 1,000-bar roll-up to weekly bars, the 1-3650 day bound, and the x402 payment vs API-key auth model. Those are meaningful, but return payload structure beyond the interval/daily_bars fields is left implicit.

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?

Front-loaded with what the tool returns and the aggregation caveat, then usage, then access. Dense and mostly waste-free, though the bracketed payment/access paragraph is lengthy relative to the core capability.

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?

With no output schema, the description still names the fields that explain the weekly-rollup behavior (interval, daily_bars) and covers access cost, lookback bounds, and market selection — everything an agent needs to call this correctly.

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 baseline is 3, but the description adds genuine meaning: the 1-3650 range and 30 default for lookback_days, the coupling constraint that quote_token and market_data_venue must be supplied together, and the default Mangrove market when overrides are omitted.

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 and resource ('Daily OHLCV history for one crypto asset') plus the default lookback, and explicitly contrasts itself with current-spot data, which is the key boundary against siblings like get_market_data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear use conditions ('price history, chart data, or reasoning about past price movement rather than the current spot') and rules for the market-selection overrides (quote_token + market_data_venue together, or provider; omit for a Mangrove market). It stops short of naming the specific sibling tool to use for spot/live quotes.

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.