get_history_prices

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

No annotations exist, so the description bears full responsibility for behavioral disclosure. It fails to mention key traits such as the data resolution (e.g., daily bars), whether it supports multiple exchanges, or any rate limits. The description only states 'long-range' without specifying the maximum range or data granularity.

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 very concise at one sentence, which is good for brevity. However, it is too short to cover necessary information, making it under-specified rather than optimally concise. It could be expanded with critical details without becoming verbose.

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 absence of annotations and output schema, the description lacks completeness. It does not describe the return format (e.g., array of price objects), frequency of data points, or any edge cases (e.g., invalid symbol). For a tool with two parameters and no output schema, more context is needed for effective use.

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?

With 0% schema description coverage, the description should explain the parameters. It does not elaborate on 'symbol' (e.g., ticker symbol format) or 'days' (what it controls, default value 365, min 1, max 3650). The schema constraints are present, but the description adds no extra meaning to help the agent use parameters correctly.

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 'Long-range historical price series for a symbol' clearly states it retrieves historical prices over an extended period. It distinguishes from sibling tools like get_price (likely current price) and get_ohlc (OHLC data) by emphasizing 'long-range'. However, it doesn't explicitly differentiate from similar tools like get_history_sentiment.

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?

No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that short-term price queries should use get_price or that get_ohlc provides Open-High-Low-Close data. A usage guideline would significantly help an agent select the appropriate tool.

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