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

Annotations already carry read-only, idempotent, open-world safety signals, and the description adds real behavioral detail beyond them: ordering (oldest first), the split-adjustment policy, and the fact that today's partial bar is included when available. The remaining gap is whether prices are dividend-adjusted or what happens on non-trading days, which is a modest omission at this annotation richness.

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, front-loaded with what is returned and in what order, followed by the limit constraint. No filler or redundant phrasing.

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 an output schema present, return-field documentation is not the description's burden, and both parameters are documented by the schema. What the description supplies (ordering, adjustment, inclusion of the current bar, size rationale) is enough for correct invocation; only edge-case behavior like handling of missing sessions is left unstated.

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%, so both parameters are already documented with range 1..500 and default 120. The description restates those numbers and only adds the rationale 'to keep the answer small', which is a marginal semantic gain over the schema.

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?

States a specific verb+resource combo: daily OHLCV bars for a single named ticker, explicitly oldest-first and split-adjusted. That cleanly separates it from siblings like get_ticker_overview or get_data_coverage, though it never names an alternative to prove the distinction.

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?

Usage is implied by the data shape (historical daily series for one symbol), and the parenthetical about keeping the answer small hints at a cost/size tradeoff. There is no explicit when-to-use vs when-not guidance or pointer to a sibling for intraday, multi-symbol, or coverage queries.

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