Price history

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds useful context by stating the output is entirely numeric and uninterpreted, and by listing the computed summary fields. This goes beyond the annotations without contradicting them.

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 entire description is one compact sentence that front-loads the core resource (OHLCV candles), includes the important computed fields, and closes with a differentiating constraint ('no interpretation'). Every part adds value and there is no filler.

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 a 7-parameter tool with 86% schema coverage, rich annotations, and an output schema, the description does not need to spell out every field or return structure. It successfully frames what the tool returns and its limitations, leaving only minor gaps like explicit sibling differentiation.

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 description coverage is high at 86%, so the schema already documents most parameters well. The description adds meaning by connecting 'optional standard technical indicators' to include_indicators and clarifying the output is chart-ready, but it does not need to compensate much for undocumented parameters.

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 identifies the tool as returning OHLCV candles with computed summary statistics and optional technical indicators. It distinguishes this from analytical or interpretation tools by explicitly stating 'chart-ready, no interpretation', and from related siblings like get_quote which presumably provides current price data.

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 implies usage through the phrase 'chart-ready, no interpretation', suggesting it should be used when raw price history is wanted rather than interpreted analysis. However, it does not explicitly name alternative siblings or state when not to use them, so usage guidance remains implicit rather than explicit.

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