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

Beyond the `readOnlyHint` annotation, the description adds 'Pure math, no market lookup', which clarifies the tool performs deterministic computation without external data fetching or side effects. It also notes it uses per-leg `premium` rather than impliedVol/spot, giving insight into input behavior. This is useful context beyond the structured annotation.

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 two sentences and highly efficient. It front-loads the core output ('At-expiry P&L curve and breakevens'), lists supported structures compactly, and includes the key usage note ('Pure math, no market lookup') without any waste.

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?

The description gives a clear picture of what the tool computes ('P&L curve and breakevens') and its computational nature, which is adequate given the detailed schema for parameters. Since there is no output schema, the description could have specified the output format more explicitly, but it covers the essential context for an agent to understand and invoke the tool.

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?

The input schema already thoroughly documents the `legs` parameter with a JSON example, field requirements, and a note about using `premium`. The description only reiterates 'pass the legs as JSON' without adding further parameter-level meaning. With 100% schema coverage, baseline 3 is appropriate.

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 clearly states the tool computes 'At-expiry P&L curve and breakevens' for multi-leg options structures, listing specific structure types (vertical spread, iron condor, straddle, butterfly, calendar). This directly distinguishes it from the sibling tool `post_structure_greeks`, which focuses on Greeks. The verb+resource phrasing is specific and unambiguous.

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 phrase 'Pure math, no market lookup' provides clear context that this tool is for theoretical calculations without live market data, implying that market-data-driven tools (e.g., the many `get_*` siblings) are for real-time scenarios. It instructs 'pass the legs as JSON' which tells the agent how to invoke it, but it stops short of explicitly naming alternatives or stating exclusions.

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