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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds one genuine behavioral fact — it will not infer trade direction (no bullish/bearish classification) — which is useful context. But it says nothing about bounding mechanics, ranking behavior, or result pagination.

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?

A single sentence with no filler, so it is structurally tight. But brevity here comes at the cost of substance, and 'bounded' is front-loaded jargon that does not orient the reader.

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?

An output schema exists so return values need not be described, which helps. However, for a 7-parameter, 0%-coverage tool, the description leaves the filtering, sorting, and pagination contract entirely undocumented, which is inadequate.

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 0%, so the schema names parameters without explaining them, and the description does not compensate. Seven parameters (top_n, sort_by enum, min_volume, min_open_interest, max_expiries, start_index) receive no meaning, units, or interaction notes beyond the vague word 'bounded'.

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 verb 'rank' and resource 'option activity' are identifiable, and 'multi-expiry' gives scope. However, 'bounded' is undefined and nothing distinguishes it from siblings like option_positioning_summary or option_surface_summary, which also summarize options data.

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?

There is no statement of when to use this tool versus the seven sibling option tools, nor any prerequisites such as valid symbol format or market-hours assumptions. Usage must be inferred entirely from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint, so the safety profile is covered elsewhere. The description adds only the word 'filtered' and 'contract-level', giving no insight into result size, pagination, live vs delayed data, or what the filters actually gate.

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 single sentence is front-loaded and free of waste, which is good. However, for an 8-parameter, 0%-documented tool it is under-specified rather than truly concise, so it cannot earn a top score.

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?

An output schema exists, so return values need not be explained, but the description fails on the input side: eight parameters with no schema descriptions receive zero compensating explanation. For a contract-level chain endpoint this leaves the definition materially incomplete.

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 0% across 8 parameters, and the description does not mention a single one of them. Core filters like min_strike/max_strike, min_volume, min_open_interest, option_type and limit_per_side are entirely undocumented, so an agent must guess their semantics and units.

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 ('Return'), resource ('contract-level option chain') and scope ('one expiration'), which distinguishes it from option_expirations (list of expirations) and the summary tools. It stops short of naming an explicit sibling alternative, so it is clear but not fully differentiated.

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?

No when-to-use guidance is given beyond the implied prerequisite of 'one expiration'. It never states how this differs from option_greeks, option_surface_summary, or the other siblings, leaving the agent to infer selection criteria from names alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, covering the safety profile. The description adds nothing beyond them — no date range, sorting order, coverage limits, or latency characteristics for what is a market-data lookup.

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?

A single front-loaded sentence with zero wasted words and no redundancy. It is efficient, though almost to the point of under-specification for a data-returning tool.

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 format need not be explained, and annotations cover safety, so the remaining burden is light. Still, for a market-data tool with three sibling summaries, the description omits any hint of data freshness, exchange coverage, or how results relate to the other option tools.

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 coverage is 0% and the single 'symbol' property carries no description, so the description is the only signal, and it only says the dates are 'for a symbol'. It confirms the parameter's role but adds no format or expected-value guidance.

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 (Return) and resource (available option expiration dates) scoped to a symbol. An agent can distinguish it from option_chain or option_greeks, though the description never explicitly names those siblings.

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?

No when-to-use or when-not-to-use guidance, and no mention of alternatives among the seven option_* siblings. Usage is only inferable from the tool name and shallow domain knowledge.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond those annotations by specifying the Black-Scholes-Merton model and that prices are theoretical, which is important for interpreting results. It does not cover auth, rate limits, or pagination, but the output schema exists to cover return structure.

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 definition is a single front-loaded sentence with no filler or redundant clauses. It is appropriately concise for a one-line description, though its brevity for a 10-parameter computation tool leaves it structurally thin.

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 output schema and annotations cover return values and safety behavior, but the description is not complete enough for an agent to invoke a 10-parameter tool with 0% schema description coverage. It names only the general calculation model and expiry scope, leaving required and optional parameters largely undocumented.

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 0% across 10 parameters, so the description must compensate and does not. It mentions only 'expiry' obliquely and provides no meaning for required inputs like symbol and risk_free_rate, nor for optional parameters such as spot_override, dividend_yield, option_type, strike filters, open-interest filtering, or limit_per_side.

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 resource: 'Return Black-Scholes-Merton theoretical prices and greeks for one expiry.' It distinguishes the output type from generic option-chain siblings, though it does not explicitly name an alternative tool. Clear enough for an agent to know it computes per-expiry theoretical values.

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?

There is no explicit when-to-use guidance, no when-not-to-use conditions, and no named alternatives. The phrase 'for one expiry' implies the tool is expiry-scoped, but the agent is left to infer this from context rather than from stated guidelines.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds what aggregates are produced (volume, OI, IV, concentration), but says nothing about how concentration is computed, aggregation windows, or data freshness.

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?

A single tight sentence with the resource and metric list front-loaded and no filler. It is efficient, though extremely terse given the tool's five parameters.

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?

An output schema exists, so return values need not be explained. However, with 0% parameter coverage across five inputs and ambiguous overlap with sibling summary tools, the definition leaves real gaps an agent would need filled to invoke it correctly.

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 0% across 5 parameters, so top_n, min_strike, max_strike, symbol, and expiry carry no documented meaning anywhere. The description names output metrics but never explains any input parameter, failing to compensate for the coverage gap.

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 (Summarize) and the exact metrics computed (volume, open interest, IV, concentration) scoped to one expiration. This distinguishes it reasonably well from option_chain and option_greeks, though it does not explicitly differentiate from the similarly-named option_surface_summary and option_activity_summary siblings.

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 'for one expiration' implies a scope, but there is no statement of when to choose this over option_activity_summary, option_surface_summary, or option_chain. No prerequisites or exclusions are provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, covering the safety profile. The description adds one genuinely useful behavioral constraint — the output is unsigned and deliberately makes no dealer-direction claim — but says nothing about data source requirements, latency, or failure modes.

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?

A single front-loaded sentence with no filler; the scope qualifier arrives before any elaboration. Nothing in it is redundant.

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?

Output schema exists, so return values need not be described, but with 10 configuration parameters at 0% schema coverage and 3 required inputs, the description leaves far too much for the agent to guess about symbol/expiry formats and how the optional pricing knobs behave.

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 0% across 10 parameters, and the description explains none of them. Only a faint hint exists that open interest matters (via 'OI-weighted'), leaving symbol format, expiry format, risk_free_rate, strike bounds, spot_override, dividend_yield and contract_multiplier entirely undocumented in both schema and prose.

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 ('Map') and resource ('OI-weighted gamma concentration') with a meaningful scope qualifier ('unsigned', 'without inferring dealer direction') that separates it from directional-analysis siblings like option_positioning_summary. It is jargon-dense but an agent can tell what it produces.

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?

No indication of when to choose this over option_greeks, option_positioning_summary, or option_surface_summary, and no preconditions stated. The 'without inferring dealer direction' clause implies a boundary but never names an alternative or a selecting condition.

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

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

Annotations already establish readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds the meaningful context that this is a BSM-model stress computation (a model output, not observed market data), which matters. It does not explain output scope (top_n rows, sort_by behavior) or how spot_override/days_forward interact.

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?

A single front-loaded sentence with no filler, which is good. However, for a 15-parameter model tool with no other documentation anywhere, one sentence is under-specified rather than genuinely concise.

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?

An output schema exists, so return-format explanation is not owed. But with 15 parameters, 0% schema coverage, and no usage guidance, the description leaves an agent unable to determine which parameters are required, what units spot_change_pct or iv_change_points use, or when to choose this over option_greeks or option_risk_map.

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 0% across 15 parameters. The description names the three stress dimensions, which loosely maps to spot_change_pct, iv_change_points, and days_forward, but leaves the remaining twelve parameters (top_n, sort_by, strike bounds, option_type, min_open_interest, contract_multiplier, dividend_yield, spot_override, etc.) undocumented in both schema and description.

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 ('stress'), resource ('one option expiry'), the dimensions varied (spot, IV, time), and the pricing model (Black-Scholes-Merton). This distinguishes it from chain/greeks/surface siblings, though it never names an alternative explicitly.

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?

There is no when-to-use guidance, no prerequisites, and no pointer to a sibling. An agent must infer that this is for scenario/stress analysis rather than live chain inspection. The description gives no exclusions despite seven related option tools being available.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior, so safety and idempotency are covered. The description adds the scope constraint of 12 expirations, which is useful operational context. But it omits what 'positioning' summary actually contains and any data-source or rate-limit behavior.

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 compact sentence with no filler; the scope constraint is front-loaded. It is appropriately sized, though the brevity comes at the cost of leaving parameters undocumented.

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?

An output schema exists, so return values need not be explained. However, with 4 parameters at 0% schema description coverage and no sibling differentiation, the description is too thin for an agent to invoke the tool correctly without guessing at parameter meanings.

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 0%, so the description must compensate for four undocumented parameters (symbol, top_n, start_index, max_expiries). It mentions only the expiry window, leaving top_n, start_index, and max_expiries entirely unexplained. This is a significant gap given zero schema documentation.

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 verb (Summarize) and resource (option positioning) with a scope constraint (up to 12 consecutive expirations). However, it does not distinguish itself from siblings like option_positioning_summary, whose name suggests overlapping purpose. The agent must guess how this differs from the more specific-sounding sibling.

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?

No guidance on when to use this versus option_positioning_summary, option_chain, or option_expirations. The only contextual clue is the scope, but there is no explicit when-to-use or when-not-to-use statement, leaving selection entirely to inference.

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