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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the bar is lower, yet the description still adds real behavior: the widget also carries strategy_records, Greek units, scenarios and cost assumptions, and the agent must reuse those records rather than invent a currency or multiplier. It also discloses data provenance (SYNTH or a user-supplied chain, never live data), which reinforces openWorldHint=false. Missing only things like latency or size limits.

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?

Five short sentences, front-loaded with the deliverable, then selection guidance, then data-integrity constraints. No filler; the only slight looseness is that the 'Includes strategy_records…' sentence packs several distinct facts together.

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?

Return-shape explanation is legitimately unnecessary because an output schema exists, and provenance/safety are covered. However, for a 10-parameter tool with zero schema coverage, the description leaves the agent guessing about symbol, expiry, rate, dividend_yield and especially rights_confirmed, which reads like a required acknowledgement the agent could easily miss.

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?

With 10 parameters at 0% schema description coverage, the description must carry the parameter load, and it only partially does: it clarifies that strategies are the payoff charts (max three) and that data_source/source_* relate to a user-supplied chain versus SYNTH. Rate, expiry, symbol, dividend_yield and the non-obvious rights_confirmed flag are never explained anywhere in the definition.

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 specific verb and enumerates the concrete artifacts returned (market map, Greek ladder, strategy comparison, up to three payoff charts) plus the key differentiator: they arrive in ONE widget. That framing directly separates it from the individual plotting siblings like option_plots and option_strategy_plot without requiring the agent to open any 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?

"Prefer this tool for multi-chart reports instead of parallel individual plot calls" gives an explicit selection rule and names the alternative pattern. The inverse case (a single chart should go to a single-plot sibling) is only implied by "up to three," so it stops short of a full when/when-not pair.

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