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

Far exceeds the readOnlyHint annotation: discloses the solver (Newton-Raphson with bisection fallback), why bisection is used (flat vega in deep ITM/OTM or short-dated), the pre-check against no-arbitrage bounds, and the deliberate refusal path (converged=false + error) instead of returning a garbage number. That refusal and the identifiable=false ambiguity case are exactly the traits an agent needs before trusting output.

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?

Front-loads the core solve, then the numerical method, then the guardrail, then the return contract. It is dense but each sentence carries distinct information; the only mild bloat is re-explaining the identifiable/converged interaction in two places.

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?

No output schema exists, so the description carries the return contract itself and does so fully: field-by-field enumeration of impliedVolatilityPct, iterations, method, converged, identifiable, warning, priceAtSolution, plus the semantics of the ambiguous and failed cases. Nothing needed to interpret a result correctly is missing.

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 all six parameters (including the risk-free rate default) are already documented in the schema, making 3 the correct baseline. The description reinforces targetPriceUsd as the observed price and names the supporting inputs (spot/strike/rate) but adds no format or unit guidance beyond 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 and resource: solves for the volatility that makes Black-Scholes reproduce an observed option price. It also explicitly distinguishes the direction of the calculation ('the volatility, not the reverse'), which separates it from the Black-Scholes pricing sibling without opening 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?

Gives a concrete trigger ('what IV does this option price imply?' or a market price with a desire for volatility) and a negative condition (not the reverse). It stops short of naming the inverse tool to route to, leaving the agent to infer run_black_scholes for the reverse case.

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