ib-gateway-mcp

Market rules

get_market_rule

Read-only

Retrieve IBKR price increments (tick ladder) for given market rule IDs to round limit prices correctly. Get IDs from contract details and map to valid exchanges.

Instructions

Return the price increments (tick ladder) of IBKR market rules.

A contract's valid price steps can depend on the price level and exchange: each rule
lists rows of (low_edge, increment), meaning prices from low_edge up to the next row's
low_edge move in steps of increment. Get the ids from get_contract_details; its
market_rule_ids line up with valid_exchanges. Use it to round limit prices correctly.

IBKR answers each rule within a second or not at all: ids it did not answer (probably
unknown) are listed in `missing_ids`; if none was answered the call fails with
not_found.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`market_rule_ids`	Yes	Market rule ids from get_contract_details (market_rule_ids), e.g. [26, 239]. At most 20.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`rules`	Yes
`missing_ids`	No	Ids IBKR did not answer within 1 second (probably unknown ids).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description goes well beyond annotations by disclosing that IBKR may omit some IDs (missing_ids), that unanswered rules are probably unknown, and that the call fails with not_found if none are answered. It also explains the semantics of the returned tick ladder, which is valuable behavioral context.

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 organized into three logically separated paragraphs: purpose, data format, and behavioral caveats. While slightly longer than strictly necessary, each sentence carries distinct information and the key purpose 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?

Given the output schema exists and annotations cover read-only safety, the description fully addresses what an agent needs: the meaning of the tick ladder, how to source IDs, when to use it, and the specific failure modes (missing_ids, not_found). Nothing essential is omitted.

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?

Although the schema already describes market_rule_ids and its source, the description strengthens semantics by noting the relationship between market_rule_ids and valid_exchanges from get_contract_details. This adds useful context beyond a generic integer array, warranting above-baseline scoring.

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 'Return the price increments (tick ladder) of IBKR market rules,' a specific verb and resource. It further explains the structure of the data (low_edge, increment) and explicitly ties it to get_contract_details, distinguishing it from sibling tools.

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 explicitly states to get IDs from get_contract_details and says 'Use it to round limit prices correctly.' This gives clear when-to-use guidance and names the source tool, leaving no ambiguity about the workflow or the purpose.

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

Deploy Server