ib-gateway-mcp

Implied volatility calculator

calculate_implied_volatility

Read-only

Derive an option's implied volatility from its price and underlying price, returning greeks for what-if pricing and scenario analysis.

Instructions

Compute an option's implied volatility from a given option price, with IBKR's model.

`contract` must be one option (sec_type OPT or FOP with symbol, expiry, strike and
right, or its con_id; futures options also need their exchange, e.g. CME). Returns
`implied_vol` as a decimal (0.25 = 25%) and the greeks at that volatility (delta,
gamma, vega, theta, dividend present value). Useful for what-if pricing: pass a
hypothetical option or underlying price. Nothing is stored or streamed.

Errors: invalid_request when the contract is not an option or no volatility fits the
prices (e.g. an option price below intrinsic value); not_found or ambiguous_contract
when the option cannot be resolved (get_option_chain lists expiries and strikes);
request_timeout when IBKR does not answer within 4 seconds; ib_api_error if IBKR
refuses (it may want market data permissions for the option and its underlying).

Input Schema

TableJSON Schema

Name	Required	Description
`contract`	Yes	The instrument. A con_id alone is unambiguous; otherwise give symbol and sec_type, plus expiry, strike and right for options.
`option_price`	Yes	Option price per share (not multiplied by 100), e.g. 5.20.
`underlying_price`	Yes	Underlying price to assume, e.g. the stock's current price.

Output Schema

TableJSON Schema

Name	Required	Description
`greeks`	Yes	IBKR's full model output at that volatility: delta, gamma, vega, theta...
`contract`	Yes	The option the calculation ran for.
`implied_vol`	Yes	Implied volatility, annualized, as a decimal (0.25 = 25%).
`option_price`	Yes	Option price the volatility was implied from.
`underlying_price`	Yes	Underlying price the calculation assumed.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 23, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With readOnlyHint and openWorldHint already present, the description adds meaningful behavioral details: it promises 'nothing is stored or streamed,' describes the return format (decimal implied_vol plus greeks), and enumerates error scenarios including a 4-second timeout and potential market-data permission issues. This goes well beyond the annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with the one-line purpose first, followed by constraints, return behavior, usage context, and a compact error list. Every sentence carries information; the error list is internally organized with error-name to cause, so no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter calculation tool with an output schema, this description is unusually complete: it specifies exact contract requirements, return format, usage scenario, non-persistence, timeout, and permission-related failures. The only minor omission is assumptions of the IBKR model, but that is a named model rather than a behavioral gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents all three parameters (100% coverage), so the baseline is 3. The description enriches the contract parameter significantly by requiring sec_type OPT or FOP and adding that futures options need an exchange (e.g. CME), and it clarifies the meaning of option_price as per-share. This extra guidance justifies a score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('Compute') and resource ('option's implied volatility'), clarifies the input ('from a given option price'), and notes the IBKR model. It is clear and not tautological, but it does not explicitly contrast with the sibling calculate_option_price, so differentiation is left to the reader.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit context: it is 'useful for what-if pricing' and requires the contract to be a single option, with futures options needing an exchange. It also points to get_option_chain when an option cannot be resolved, but does not explicitly state when to prefer calculate_option_price, so some inference remains.

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

Deploy Server