Skip to main content
Glama
aiordanescu

ib-gateway-mcp

by aiordanescu

Qualify contract

qualify_contract
Read-only

Resolve an ambiguous contract spec into a single IBKR contract with its con_id, confirming the intended instrument before quoting or ordering.

Instructions

Resolve a contract spec to exactly one IBKR contract and return it with its con_id.

Use it to check a spec before quoting or ordering, or to turn a symbol into a con_id;
later calls can then pass just the con_id. The returned `description` is the long name
(e.g. APPLE INC) to confirm it is the intended instrument.

If several contracts match (e.g. a stock listed on two exchanges, or an option spec
without trading class), the call fails with ambiguous_contract and the message lists
up to 20 candidates with their con_ids: retry with the right con_id or more fields
(primary_exchange, currency, trading_class...). An unknown spec fails with not_found;
a combo (BAG) with invalid_request (qualify each leg by con_id instead).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contractYesThe instrument. A con_id alone is unambiguous; otherwise give symbol and sec_type, plus expiry, strike and right for options.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rightNo
con_idYesIBKR contract id (None if not yet qualified).
strikeNo
symbolYes
currencyNo
exchangeNo
sec_typeYes
combo_legsNo
multiplierNo
descriptionNo
local_symbolNo
trading_classNo
primary_exchangeNo
last_trade_date_or_contract_monthNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses specific failure modes (ambiguous_contract with up to 20 candidates, not_found, invalid_request for combos) and explains the returned `description` field. This gives the agent a precise model of tool behavior.

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 compact and front-loaded with the core purpose, then covers failure modes in two short paragraphs. No wasted words or redundant detail.

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

Completeness4/5

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

Combined with the rich schema and output schema, the description covers the main use case, return value, and error recovery steps. It doesn't explicitly mention alternatives like search_symbols, but the scope is well-defined and practically complete.

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 is already rich (100% coverage via ContractSpec and field descriptions). The tool description adds targeted guidance about con_id being unambiguous and what to provide for options, which complements rather than repeats the schema.

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 states a specific verb ('Resolve') and resource ('contract spec to exactly one IBKR contract') and explains the output (con_id). It clearly differentiates from siblings like get_contract_details and search_symbols by focusing on resolution to a single contract.

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?

Explicitly says to use it before quoting/ordering and to turn a symbol into a con_id, and states not to use it for BAG combos (qualify legs by con_id instead). It doesn't name alternative siblings such as search_symbols, but the context is clear and actionable.

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