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

Annotations already cover read-only, non-destructive and closed-world, yet the description adds substantive behavior the agent could not infer: split-only adjustment, dividends and spin-offs excluded, oldest-first ordering, per-row column order, and a ~5-year ceiling. That adjustment disclosure is the single most decision-relevant fact for price data and it is stated plainly.

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?

Three dense but well-ordered sentences: what is returned, how it is adjusted, how it is formatted, then when to use it. Nothing is padded, though the bare `fields` mention arrives before the reader knows it describes the response rather than an input.

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?

With no output schema, the description correctly takes on return-shape duty (column order, one row per bar, oldest first) and states the data's analytical nature. It stops short of covering failure behavior (unrecognized symbol, ticker vs company name ambiguity) and the 1,260-vs-1,300 session gap.

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%, so the baseline is 3; the description earns above that by clarifying that 'sessions' means trading days (~1,260 per five years), which the schema only calls 'sessions'. Minor imprecision: it cites ~1,260 while the schema permits 1,300, and the 'fields' reference reads like a parameter but is really the response envelope.

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?

Names a specific resource (daily bars) and enumerates the exact fields returned (date, open, high, low, close, volume), plus the horizon and adjustment basis. This is far more specific than a generic 'get price data' and lets an agent separate it from siblings like get_dividends or get_figure_history without opening a schema.

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?

Explicitly states the use case ('when the user needs price data for a chart or a calculation'), which is a clear positive signal. It also implies the boundary case — dividends and spin-offs are not subtracted — but never names an alternative tool for total-return or dividend needs, so guidance stops short of full when/when-not routing.

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