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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description adds the non-obvious operational constraints: past windows only and a 600-bar cap. It also explains that values are computed and deterministic rather than visually approximated, which sets expectations about precision, though it says nothing about what happens on out-of-range requests.

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?

One extremely dense sentence that front-loads the headline purpose, but it is padded with parentheticals and an enumerated return-field list ('open, close, high, low, range, change, volume, session'). The aside 'theirs — they may be used as levels the trader gave' is ambiguous and costs more than it earns.

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?

There is no output schema, so the description must convey the return shape, and it does: bars (count, first/last, last candle), indicators, trader levels/zones, the envelope and its gate, and the window fact sheet. Combined with the coverage limits and past-only constraint, an agent has enough to call it correctly; only error/empty-result behavior is unaddressed.

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 tf, from, to, market and indicators are already documented; the description only restates that a single market/timeframe/window is in play. It adds conceptual framing of what indicators and 'the trader's own marked levels and zones' mean, but no format or syntax detail beyond the schema. Baseline 3 applies.

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 opening clause names a concrete verb and resource ('what the deck's chart would show') plus the scoping dimensions (one market, timeframe, window) and the output form (ONE JSON object computed in code). It contrasts itself with a pixel-reading approach, so an agent can tell it apart from chart_image without inspecting either 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?

'Use it instead of reading pixels: every number is measured, not read' explicitly routes the agent away from the image-based alternative, and 'Past windows only; at most 600 bars' states hard applicability limits. It stops short of naming the sibling tool outright or stating what to use for live/forward data, so it's clear context rather than a complete when/when-not guide.

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