QUOTEZ

Overview Schema Source Related Servers Score Discussions Admin

Get bars in a date range

get_bars_range

Read-only

Retrieve OHLCV bars for a symbol and timeframe over a specified UTC interval, ordered oldest first. Use inclusive start and exclusive end bounds to tile ranges without overlapping or missing bars.

Instructions

Return the OHLCV bars whose open time falls in [start, end), oldest first.

Both bounds must carry a UTC offset, for example 2026-06-01T08:00:00Z. start is inclusive and end is exclusive, so consecutive ranges tile without repeating a bar. The number of bars the range spans is capped by the same limit that applies to get_bars, so a wide window at a fine timeframe returns a tool error asking for a coarser one rather than a truncated answer. Unlike get_bars, an end that reaches into the interval currently forming can return that bar, because the bounds are yours; stop end at a closed interval if that matters. On the replay source the prices are generated, not recorded from any market.

Input Schema

TableJSON Schema

Name	Required	Description
`end`	Yes	Exclusive, ISO 8601, UTC.
`start`	Yes	Inclusive, ISO 8601, UTC.
`symbol`	Yes	Instrument name exactly as list_symbols spells it.
`timeframe`	Yes

Output Schema

TableJSON Schema

Name	Required	Description
`bars`	Yes	The bars, oldest first.
`count`	Yes	Number of bars returned.
`source`	Yes	Data source that produced these bars.
`symbol`	Yes	Symbol these bars belong to.
`synthetic`	Yes	True when the prices are generated, not observed.
`timeframe`	Yes	Timeframe of each bar.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 19, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description goes well beyond the readOnlyHint annotation, explaining the inclusive/exclusive bounds, UTC offset requirement, tiling behavior, error on exceeding limits, the nuance with forming bars, and the synthetic nature of replay data. This gives the agent a full behavioral model.

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 description is front-loaded with the core purpose, and every subsequent sentence adds essential behavioral or usage detail. It is concise given the complexity, with no redundant wording.

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 description covers not only the basic operation but also edge cases like limit-caused errors, the difference from get_bars, data source caveat, and formatting requirements. Given the output schema exists, return values need no explanation, and the description is fully sufficient for an agent to invoke the tool 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?

The schema already covers 75% of parameters with descriptions, but the description adds critical semantics for start/end (inclusive/exclusive, UTC offset, example format) and clarifies the meaning of range-related behavior beyond the schema. Timeframe is only an enum, but the values are self-explanatory.

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 clearly states the tool returns OHLCV bars within a half-open date range, ordered oldest first. The title 'Get bars in a date range' plus the explicit interval notation [start, end) distinguishes it from its sibling get_bars.

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 references get_bars multiple times, noting the same limit applies and highlighting a key difference regarding forming bars. This provides clear comparative context, though it does not include a direct 'use this when' statement or explicit when-not-to-use guidance.

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

Install Server