ib-gateway-mcp

Quote snapshots

get_quotes

Read-only

Fetch one-time market data snapshots for up to 25 contracts: bid, ask, last, volume, OHLC, options Greeks, and halted/delayed status. Resolves contracts by symbol or con_id and reports per-contract errors.

Instructions

Get a one-time quote for up to 25 contracts: bid, ask, last, sizes, OHLC, volume.

Each quote also has `halted`, `market_data_type` (live, frozen, delayed or
delayed_frozen), `bbo_exchange` (expand it with get_smart_components) and, for
options, IBKR model greeks and implied volatility. Snapshots take up to about 11
seconds for quiet contracts. A contract with an open quote stream (subscribe_quotes)
is answered from the stream at no extra cost. Generic ticks (shortable shares,
fundamental ratios...) are not available as snapshots; use subscribe_quotes.

Contracts that fail are listed in `errors` (unknown or ambiguous contract, no market
data permission) while the others still get quotes; if all fail, the call fails.
Needs market data permissions for each exchange. Without them IBKR answers with
error 354, 10089 or 10168: call set_market_data_type with 'delayed' for free
15-20 minute delayed data (10089 with delayed already selected: IBKR has no delayed
data for that instrument on this login). Null prices mean IBKR sent no value.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`contracts`	Yes	1 to 25 instruments. A con_id alone is unambiguous; otherwise symbol and sec_type, plus expiry, strike and right for options.
`regulatory_snapshot`	No	Request a regulatory (NBBO) snapshot. COSTS MONEY: IBKR bills about USD 0.01 per request for US stocks and ETFs without a live subscription. Refused (configuration_error) unless the server's operator allowed it. Leave false unless the user asked for it.

Output Schema

TableJSON Schema

Name	Required	Description
`errors`	No	Contracts that got no quote, and why.
`quotes`	Yes
`notices`	No	Things to know about the data (fees, missing data).
`regulatory_snapshots`	No	How many fee-bearing regulatory snapshots were requested.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint. The description adds substantial behavior: latency (~11 seconds), that open streams are reused at no cost, that missing permissions produce specific error codes (354, 10089, 10168), that null prices mean IBKR sent no value, and that partial failures still return quotes for valid contracts. No contradiction with annotations.

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

Conciseness4/5

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

The description is long but each sentence contributes essential information: purpose, data fields, latency, stream reuse, exclusions, error handling, permissions, and null semantics. It is front-loaded with the primary action and then layers context. While not minimal, it avoids redundancy and is well-paragraphed, making it scannable.

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 two parameters, a rich contract schema, and an output schema, the description covers all critical operational details: error codes and recovery, permission requirements, latency expectations, stream integration, and data availability limits. It also references related tools (get_smart_components, subscribe_quotes, set_market_data_type) to guide the agent. Nothing essential is missing for correct invocation.

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%: both parameters (contracts and regulatory_snapshot) are fully documented with constraints and cost warnings. The description adds little beyond the schema—it repeats the 25-contract cap and the cost of regulatory_snapshot, which are already in the schema. It does mention return fields (halted, market_data_type) but those are output, not parameters. Baseline 3 is appropriate since the schema carries the semantics.

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 opens with a clear verb+resource: 'Get a one-time quote for up to 25 contracts' and enumerates the exact data fields (bid, ask, last, sizes, OHLC, volume). It also distinguishes itself from subscribe_quotes by stating what snapshots do not include (generic ticks) and how they differ from streams, so an agent can tell them apart without inspecting schemas.

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?

Explicit guidance is provided: when to use subscribe_quotes instead ('Generic ticks ... are not available as snapshots; use subscribe_quotes'), how to expand bbo_exchange with get_smart_components, and the requirement for market data permissions with fallback instructions (set_market_data_type with 'delayed'). It also explains error behavior when contracts fail, so the agent knows how to handle partial failures.

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

Deploy Server