ib-gateway-mcp

Option chain quotes

get_option_quotes

Read-only

Fetch snapshot quotes and option greeks for a single expiration, selecting strikes by range or around the current underlying price.

Instructions

Snapshot quotes and greeks for a slice of one option expiration (a mini chain).

Picks the chain for `expiration`, chooses strikes either in [strike_min, strike_max]
or the `strikes_around_atm` strikes nearest the underlying's price (taken from a
snapshot of the underlying), and returns for each option (both rights unless `right`
is set): bid/ask/last with sizes, volume, close, and IBKR's model greeks (implied_vol,
delta, gamma, vega, theta, und_price). Legs are sorted by strike, calls before puts.
`limit` caps the legs (strike and right pairs): default 20, max 40; `total` and
`truncated` say how many were selected (a range keeps the lowest strikes, ATM the
nearest). Strikes the chain lists but this expiration lacks are reported in
`skipped`, as are legs IBKR would not quote.

Market data: one snapshot per leg, using the connection's market data type (see
`market_data_type`; switch with set_market_data_type). Live quotes for US equity and
index options need IBKR's OPRA subscription for API use (plus the underlying's
exchange data; futures options need the futures exchange's data); without it, try
delayed data. Snapshots take a few seconds and up to about 11. For expiries and
strikes without quotes use get_option_chain; to stream one option use subscribe_quotes.

Errors: not_found (unknown underlying, expiration or strikes not listed, or no
underlying price: then pass strike_min/strike_max); invalid_request (bad arguments,
or several trading classes: pass trading_class); ib_api_error when no leg could be
quoted (the message names the subscription needed); subscription_limit when IBKR's
market-data lines are used up.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Maximum number of items to return. Omit for the tool's default; larger values are capped. The result's truncated flag says whether more were available.
`right`	No	C for calls, P for puts; omit for both.
`exchange`	No	Exchange of the chain; default SMART, or the only exchange listed (futures options, e.g. CME).
`expiration`	Yes	Expiration date as YYYYMMDD, e.g. 20261218 (from get_option_chain).
`strike_max`	No	Highest strike to include; selects strikes by range.
`strike_min`	No	Lowest strike to include; selects strikes by range.
`underlying`	Yes	The instrument the options are on: a stock (symbol, sec_type STK), an index (sec_type IND with its exchange, e.g. SPX on CBOE) or a future (sec_type FUT with exchange and contract month), or its con_id.
`trading_class`	No	Trading class when several list the expiration, e.g. SPXW (PM-settled weeklies) vs SPX. Default: the class named like the underlying.
`strikes_around_atm`	No	Number of strikes nearest the underlying's current price (default 5). Not together with strike_min/strike_max.

Output Schema

TableJSON Schema

Name	Required	Description
`legs`	Yes	One quote per option, by strike then right (C, P).
`total`	Yes	Legs (strike and right pairs) selected before the limit.
`skipped`	No	Selected legs without a quote: strike not listed for the expiry, or no data.
`exchange`	Yes	Exchange of the chain the legs were taken from.
`truncated`	No	True when the result was cut to the limit.
`expiration`	Yes	Expiration date, YYYYMMDD.
`multiplier`	No	Contract multiplier, e.g. 100.
`underlying`	Yes	The instrument the options are on.
`trading_class`	Yes	Trading class of the legs, e.g. SPX or SPXW.
`market_data_type`	No	Market data type this connection requests (see set_market_data_type).
`underlying_price`	No	Price the at-the-money strikes were chosen around (mid, else last or close).
`underlying_quote`	No	Snapshot of the underlying, taken to find the at-the-money strikes; null when strike_min/strike_max chose the strikes (each leg's greeks.und_price has it).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 23, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, and the description aligns with that. It adds substantial behavioral context beyond the annotations: results are sorted by strike with calls before puts, limit defaults to 20 with max 40, skipped strikes/legs are reported, snapshots take a few seconds, and live quotes require specific IBKR data subscriptions. No contradiction with annotations exists.

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 dense but well organized: main behavior first, then selection and output details, then market-data caveats and error mapping. Every paragraph earns its place, and the most decision-relevant information is front-loaded.

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 tool with 9 parameters, an output schema, and market-data dependencies, the description covers all essential context: return fields, selection semantics, truncation behavior, subscription requirements, latency expectations, error conditions, and sibling alternatives. Nothing an agent needs to invoke this correctly is missing.

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

Parameters5/5

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

Even with 100% schema coverage, the description adds meaning beyond the schema: it explains the range-vs-ATM selection tradeoff, that both rights are returned unless right is set, that limit caps leg pairs, and that a range keeps the lowest strikes while ATM keeps the nearest. This connects the parameters into a coherent selection model the schema alone does not convey.

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 ('Snapshot quotes and greeks') and a specific resource ('a slice of one option expiration (a mini chain)'), clearly distinguishing this from the broader get_option_chain and streaming subscribe_quotes siblings. It also specifies the two strike-selection modes, so an agent knows exactly what the tool returns and how to scope it.

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

Usage Guidelines5/5

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

The description gives explicit routing guidance: use get_option_chain for expiries/strikes without quotes and subscribe_quotes for streaming a single option. It also notes the market_data_type dependency and when to pass trading_class. This tells the agent both when to use this tool and when to pick an alternative.

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

Deploy Server