Get recent bars

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

The description discloses critical behavioral traits beyond annotations: bars are in UTC labeling the open, the newest bar is always closed (never returns forming bar), the server caps count, and on replay source prices are generated (not recorded). The readOnlyHint annotation is consistent with the read-only nature described, and no contradiction exists.

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

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

The description is concise (5 sentences) and front-loaded: first sentence states the core purpose and ordering. Every sentence adds distinct value (timezone, counting strategy, bar state, error handling, data source). No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 parameters, an output schema (present), and annotations (readOnlyHint, openWorldHint), the description covers all necessary context: purpose, parameters, error handling, alternatives, and data source behavior. The output schema likely describes return format, so no need to explain return values. Complete for a moderately complex tool.

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

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

Schema coverage is 67% (only 2 of 3 parameters have descriptions). The description adds value: clarifies that 'count' is capped by server ('ask for a coarser timeframe rather than more bars'), that 'symbol' must match list_symbols spelling, and that 'timeframe' is the interval length. The description compensates for the missing schema description on 'timeframe' by listing enum values contextually (M1, M5, etc.) and implying the left-edge labeling. However, it doesn't explain the 'timeframe' enum beyond listing intervals, so a 4 is appropriate.

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

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

The description clearly states the tool returns 'the most recent OHLCV bars for a symbol, oldest first'. It identifies the specific verb (return), resource (OHLCV bars), and ordering (oldest first), distinguishing it from siblings like get_quote (current price) and get_bars_range (range-based).

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

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

The description provides explicit guidance: when to use alternatives ('call get_quote for the current price'), when to call list_symbols first ('call list_symbols first if unsure'), how to handle timeframes ('ask for a coarser timeframe rather than more bars'), and error handling ('An unknown or unavailable symbol returns a tool error naming the symbol'). It also notes the 'count' cap and server limit.

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