ib-gateway-mcp

Option price calculator

calculate_option_price

Read-only

Compute an option's theoretical price and greeks (delta, gamma, vega, theta) for a given volatility and underlying price, using IBKR's pricing model. Ideal for scenario analysis.

Instructions

Compute an option's theoretical price and greeks at a given volatility, 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
`option_price` per share (multiply by the contract multiplier for the premium) and
the greeks (delta, gamma, vega, theta, dividend present value). Useful for
scenarios: vary volatility or underlying_price.

Errors: invalid_request when the contract is not an option, volatility looks like a
percent (above 10), or IBKR computed no price; not_found or ambiguous_contract when
the option cannot be resolved; request_timeout when IBKR does not answer within 4
seconds; ib_api_error if IBKR refuses (e.g. missing market data permissions).

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.
`volatility`	Yes	Annualized volatility as a decimal: 0.25 means 25% (not 25).
`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 price: delta, gamma, vega, theta...
`contract`	Yes	The option the calculation ran for.
`volatility`	Yes	Volatility the price assumes, as a decimal.
`option_price`	Yes	Theoretical option price, per share (unmultiplied).
`underlying_price`	Yes	Underlying price the calculation assumed.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 23, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds substantial behavioral context: the pricing model is IBKR's, the return is per share with a multiplier caveat, errors are enumerated (invalid_request, not_found, ambiguous_contract, request_timeout with a 4-second limit, ib_api_error for missing permissions). This goes well beyond what annotations provide.

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 front-loaded with the primary purpose, then moves logically through contract constraints, output format, use-case scenarios, and error handling. Every sentence adds operational value, and the error enumeration is compact rather than rambling.

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?

Given the tool's complexity and the fact that an output schema exists, the description is complete: it covers contract requirements, output units and greeks, the multiplier adjustment, intended scenario use, and all realistic failure modes. An agent has everything needed to invoke it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already fully documents contract, volatility, and underlying_price. The description mostly restates the contract requirements and the decimal-volatility convention already present in the schema, adding limited new meaning beyond the percent-above-10 error behavior.

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

Purpose5/5

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

The description names a specific verb (Compute), a precise resource (option's theoretical price and greeks), and the condition (at a given volatility, with IBKR's model). This clearly differentiates it from the inverse sibling calculate_implied_volatility, since this tool takes volatility as an input rather than solving for it.

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 states clear context for use: pricing scenarios where you vary volatility or underlying_price. It provides detailed contract constraints and error conditions, but it does not explicitly say when NOT to use this tool or direct the agent to an alternative like calculate_implied_volatility, so it stops short of full exclusion guidance.

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

Deploy Server