get_history

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It reveals that the tool returns historical end-of-day data and defaults to stock/shares, but does not mention timezone handling, date inclusivity, pagination behavior, API limits, or what happens when optional date parameters are omitted.

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?

Two short sentences with no filler. The core purpose is stated first and the meaningful default behavior is front-loaded. Every word contributes to understanding.

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?

For a tool with seven parameters and no output schema or annotations, the description conveys the primary purpose and defaults but leaves gaps about return structure, date inclusivity, handling of missing optional parameters, and differentiation from similar historical/candle tools. It is adequate but not rich enough to fully guide an agent without additional 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 100%, and each parameter already has a description and defaults. The description adds the context that data is end-of-day and defaults to stock/shares, but does not clarify parameter relationships such as whether from/till are required for meaningful results or how limit interacts with the date range.

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 states a clear action and resource: retrieving historical end-of-day trading data for a security over a date range. It mentions the default stock/shares context, which helps distinguish it from broader market data tools, though it does not explicitly name a sibling it differs from.

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 gives only a minimal hint that it defaults to stock/shares, but provides no guidance on when to use this tool versus the many siblings such as get_history_date_range, get_historical_candles, or get_market_data. No exclusions or alternative conditions are stated.

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