get_price_history

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

With no annotations provided, the description carries the full disclosure burden and mostly meets it. It reveals the return scope (return calculations, SMA20/50/200, RSI14, max drawdown, annualized volatility) and hard constraints (candles ≤ 400, intraday max 60 days). It stops short of describing response shape or error conditions, so it is strong but not exhaustive.

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?

A dense, single-paragraph description that front-loads the core purpose before diving into parameter details. Parameter names are consistently backticked and constraints are stated economically. Every sentence earns its place, though the indicator list is long by necessity rather than brevity.

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?

There is no output schema, so the description must convey the response, and it covers the data categories (OHLCV, returns, indicators). However, it never states the response shape, ordering, units, or how bars are structured, which an agent would need given the absent output schema. Constraints and data content are solid, but response format is left to inference.

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 0%, so the description must compensate, and it does for three of four parameters: it lists valid period values, valid interval values with the intraday distinction, and explains the meaning of candles with a cap. The required symbol parameter is left undocumented, but its meaning is self-evident, and the coverage gap for the tricky parameters is well addressed.

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 opens with a specific resource and action ('Historical OHLCV plus computed stats'), making the tool's function unmistakable. The enumeration of technical indicators (SMA, RSI, drawdown) further clarifies what it returns. It does not explicitly name or contrast siblings like get_stock_quote, so it lands at 4 rather than 5.

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?

There is no guidance on when to choose this tool versus the many siblings (get_stock_quote, get_top_movers, compare_stocks, etc.). No exclusions, prerequisites, or scenario-based instructions appear anywhere. The content is purely parameter-value documentation, so the agent must infer the fitting use case on its own.

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