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

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, so safety traits are covered structurally. The description adds meaningful behavioral detail beyond those annotations: it explicitly warns that days_returned/count may be less than requested due to insufficient history, describes the exact response shape (including per-bar fields), and notes the default and max days. This transparency about partial results is valuable and not inferable from annotations alone.

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 extremely efficient: a single opening sentence identifies the purpose, followed by three short bullet lines that add parameter details and return structure. Every sentence earns its place—no filler, no repetition of the title or annotations. The critical caveat (days_returned may be less) is given prominence. Structure is front-loaded and logical.

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 is a straightforward historical data retriever with an output schema, the description covers nearly everything an agent needs to call it correctly: purpose, parameter details, response shape, and the partial-data caveat. The only significant omission is usage guidance versus siblings, which is a separate dimension. The output schema covers the return types, so the description doesn't need to explain those further. Overall, it's complete for the mechanics, but missing selection context.

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 100% (both parameters are described in the schema), so the baseline is 3. The description enhances semantics beyond the schema: for the 'symbol' parameter it adds 'Also accepts a company name as a fallback when it uniquely resolves to one symbol,' which is not in the schema description. It also re-emphasizes the max days and the potential for a shorter response. This extra meaning justifies a score above baseline.

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 verb and resource: 'Daily OHLCV price history for a stock.' It's distinct from siblings like get_stock or get_indicator_history in that it focuses on historical price bars, but it doesn't explicitly name sibling alternatives or differentiate itself. For example, it doesn't say 'for technical indicators use get_indicator_history.' Thus, clarity is high but differentiation is implicit at best.

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 no guidance on when to use this tool versus the 16 siblings. It doesn't mention typical use cases, nor does it exclude variants like intraday or adjusted prices. There's no 'use this when you need historical daily bars' or 'for earnings use get_earnings_calendar.' The context signals and sibling list are present but not leveraged in the description. This is a clear gap for tool selection.

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