f1ow

Price Candles

market_candles

Read-only

OHLC(V) candle history for a coin by symbol (e.g. 'ETH', 'BTC'). 'interval' picks the candle size (1m|5m|15m|30m|1h|4h|12h|1d|1w, default 1d); 'limit' the number of candles (default 100, max 400); 'market' picks the series — 'spot' (Binance, Bybit, then CoinGecko/CoinMarketCap), 'perp' (Hyperliquid, Bybit, then Binance futures — perpetual marks), or 'auto' (default: spot preferred, perp fallback). spot/perp are hard constraints and error rather than substitute. The response labels the market, interval and source actually delivered, includes USD volume when the source carries it, and flags a still-forming last candle.

Input Schema

TableJSON Schema

Name	Required	Description
`days`	No	DEPRECATED: trailing window in days; use interval+limit instead. Ignored when interval is given.
`limit`	No	Number of candles, newest last. Default 100, max 400.
`market`	No	Which market's series: spot exchange trades, perpetual-futures marks, or auto (spot preferred, perp fallback). Default auto.
`symbol`	Yes	Coin symbol, e.g. 'ETH' or 'BTC'
`interval`	No	Candle size. Default 1d.

Output Schema

TableJSON Schema

Name	Required	Description
`coinId`	No	Identifier the answering provider queried
`market`	No	'spot' or 'perp' — which market the series describes
`source`	No	Provider that answered
`candles`	No
`interval`	No	Candle size actually delivered, e.g. '4h'
`lastCandleIsPartial`	No	True when the newest candle is still forming; exclude it from indicator math

TDQS

A4.7/5.0

Behavior5/5

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

Beyond readOnlyHint=true, the description discloses rich behavior: the source-priority hierarchy per market (Binance/Bybit → CoinGecko/CoinMarketCap for spot; Hyperliquid/Bybit → Binance futures for perp), the fact that spot/perp error rather than substitute, response labelig of the actually-delivered market/interval/source, conditional USD volume, and the still-forming last-candle flag. This far exceeds what annotations alone provide.

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?

The core purpose is front-loaded in the first sentence, and every subsequent sentence earns its place — parameter semantics, defaults, constraint behavior, response contract. Despite covering five parameters and complex market selection, the description is dense but efficiently organized with no filler.

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 (deprecated param, two enums, multi-source fallback, hard constraints) and an existing output schema, the description covers everything needed: purpose, each parameter's semantics and defaults, source selection behavior, error semantics, and response characteristics. Nothing critical is left to inference.

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. The description adds real value beyond the schema: the source hierarchy for 'market', the hard-constraint vs substitute behavior, the default of 'auto', and the deprecation note for 'days' being ignored when interval is given — all genuinely new semantic content for parameters.

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 opening sentence states a specific verb and resource: 'OHLC(V) candle history for a coin by symbol'. This unambiguously distinguishes it from siblings like market_quotes (current prices), market_overview, and ta_technicals, so an agent can select it without opening the schema.

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?

The description gives clear context on how to use the tool — defaults, the 'auto' fallback behavior, hard constraints for spot/perp, and the deprecated 'days' param — which is strong usage guidance within the tool. However, it does not explicitly name alternatives or state when-not-to-use-it (e.g., no pointer to market_quotes for current prices), so it stops short of a 5.

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

All f1ow 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

A4/5.0

Disambiguation4/5

Tools are grouped by clear prefixes and mostly target distinct resources; market_quotes vs research_token_view, market_top_movers vs market_trending, and funding_current vs market_quotes have some field or purpose overlap, but descriptions draw enough scope boundaries for an agent to choose correctly in most cases. No two tools are truly interchangeable.

Naming Consistency5/5

All 30 tool names use lowercase snake_case with a consistent domain-prefix convention such as market_, flow_, research_, sentiment_, and catalysts_, making the surface predictable. Even helpers like utc_time and risk_position_size fit the same noun-oriented pattern without style mixing.

Tool Count2/5

At 30 tools this set crosses the 'too many' threshold, and several tools reproduce data already available through broader ones such as research_token_view and market_quotes. The breadth is defensible for a crypto-research platform, but the surface feels heavy and could be consolidated.

Completeness5/5

The tool set covers the read-only crypto research workflow thoroughly: market data, candles, derivatives, funding, OI, order book, whale flows, ETF flows, on-chain metrics, news, sentiment, prediction odds, technicals, regime/positioning scans, and position sizing. It also includes health and UTC helpers that close practical workflow gaps, with no obvious dead ends.

Resources

Need Help?