Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@IBKR MCP get my current positions"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Interactive Brokers via IB Gateway on Windows. Runs in Docker and connects to IB Gateway on the host through host.docker.internal.
Live account (port 4001): read positions, quotes, option chains, day-trade status
Paper account (port 4002): same reads plus place/cancel stock and option orders
Related MCP server: ib-async-mcp
Configure IB Gateway API (see SETUP_GUIDE.md)
Install Python deps for local dev:
pip install -e ".[dev]"Install Cursor launchers:
.\scripts\Install-IbkrMcpLaunchers.ps1Add ibkr-live and/or ibkr-paper to Claude Desktop MCP config (Store app path below)
Restart Claude Desktop, start IB Gateway, then use the MCP tools in chat
Claude config (Microsoft Store): C:\Users\rodri\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json
set IBKR_HOST=127.0.0.1
set IBKR_PORT=4002
set IBKR_TRADING_ENABLED=true
python -m ibkr_mcp.serverOpen the repo in a dev container (.devcontainer/devcontainer.json). The container uses host.docker.internal to reach IB Gateway on Windows.
Tool | Live | Paper |
| yes | yes |
| yes | yes |
| yes | yes |
| yes | yes |
| yes | yes |
| yes | yes |
| yes | yes |
| no | yes |
| no | yes |
| no | yes |
| yes | yes |
pytestCancel an open order. Paper account only.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose behavioral traits like whether cancellation is immediate, what happens if the order is already executed, or if confirmation is returned. The impact on other orders or account state is unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences, no redundancy). However, it sacrifices clarity for brevity, omitting essential details. It is appropriately sized for a simple tool but could include more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description should at least mention the return value or outcome of cancellation. It fails to specify what the agent should expect upon success or failure, leaving the tool incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the only parameter (order_id). The description does not explain the meaning or format of 'order_id' beyond the schema's type 'integer'. No details on how to obtain the order ID or validation constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cancel an open order') and identifies the target resource (open orders). It is distinguishable from sibling tools because no other tool cancels orders, but the description lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a constraint ('Paper account only') but offers no guidance on when to use this tool versus alternatives, such as handling orders that are already filled or partially filled. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get account summary values (buying power, net liquidation, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It does not confirm that it is a read-only operation, mention authentication requirements, or describe behavior when account_id is null. The description assumes a read operation but lacks explicit transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the key purpose. It mentions examples, which adds value without unnecessary words. Slightly under-specified but not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, no output schema), the description provides minimal but acceptable context. It lists example return fields, which helps, but lacks a comprehensive list or structure of the summary values. For a read operation with no output schema, additional detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'account_id' has no description in the schema (0% coverage). The tool description adds no additional meaning—it does not explain what 'null' means (e.g., defaults to current account) or provide context about valid account IDs. The schema alone is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves account summary values, listing specific examples like buying power and net liquidation. It distinguishes itself from sibling tools like 'ibkr_get_positions' and 'ibkr_get_quote' by focusing on account-level aggregates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention exclusions or conditions (e.g., only works for the current user if account_id is null). The presence of sibling tools suggests alternatives, but no comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get day-trade balance and PDT-related account tags.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility but only states what the tool gets, not behavioral traits like read-only nature, authentication needs, or behavior with a null account_id. It lacks essential context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loading the key action and resource. No extra words or redundancies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is somewhat lacking. It does not explain the return format or what 'PDT-related account tags' entails, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter (account_id) with zero description coverage, and the tool description adds no meaning about the parameter's purpose, default behavior, or effect on results. The agent gets no help understanding the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'day-trade balance and PDT-related account tags,' which is a specific verb and resource that distinguishes it from sibling tools like ibkr_get_account_summary or ibkr_get_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing day-trade or PDT status but provides no guidance on when to use this tool versus alternatives or any prerequisites. No exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical OHLCV bars for a stock.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| duration | No | 1 D | |
| bar_size | No | 5 mins | |
| what_to_show | No | TRADES | |
| use_rth | No | ||
| exchange | No | SMART | |
| currency | No | USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it retrieves historical OHLCV bars but does not disclose any behavioral traits such as data limits, time zone handling, response format, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. But the tool requires more context for effective usage. Conciseness alone does not compensate for missing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description is severely incomplete. Lacks return value details, parameter constraints, and usage scenarios. Agent cannot effectively invoke the tool without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with 7 parameters. Description adds no meaning beyond parameter names. Does not explain default values (e.g., duration '1 D', bar_size '5 mins'), valid formats, or how parameters affect the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets historical OHLCV bars for a stock. It uses a specific verb-resource pair (get historical bars) and differentiates from siblings like ibkr_get_quote (current price) and ibkr_get_option_chain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not mention scenarios (e.g., backtesting, analysis) or exclusions (e.g., use ibkr_get_quote for real-time data, ibkr_get_option_chain for options).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List open orders.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description does not disclose whether this operation is read-only, what data is returned, or any side effects (e.g., does it affect order state?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise but could benefit from slight elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, annotations, or parameter details, the description is too minimal. It does not clarify what constitutes an 'open order' or how this differs from positions, limiting completeness for an agent unfamiliar with IBKR context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies. The description adds no parameter details, but none are needed. It adequately states what the tool does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List open orders' essentially restates the tool name, providing minimal added value. It is clear but lacks specificity or distinguishing details from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like ibkr_cancel_order or ibkr_get_positions. The agent is left to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get option chain expirations and strikes for an underlying symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| exchange | No | SMART | |
| currency | No | USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., read-only, required permissions, rate limits). The name implies a read operation, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and efficient. However, it is too brief for a tool with 3 parameters and no output schema, missing important details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the return format, pagination, or any behavioral aspects, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only mentions 'underlying symbol' for the required 'symbol' parameter, adding minimal value. No explanation for 'exchange' or 'currency' is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves option chain expirations and strikes for an underlying symbol, using specific verb and resource. It distinguishes from sibling tools like ibkr_get_quote (quote data) and ibkr_place_option_order (order placement).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, or any prerequisites. The description lacks context on typical usage scenarios, such as before placing an option order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current portfolio positions.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Get' (implying read-only) but does not disclose potential behavioral traits like authentication requirements, rate limits, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and efficient, though it could benefit from a bit more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 0% schema coverage, the description is too minimal. It lacks details on return format, pagination, error handling, or what constitutes a 'position'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any meaning to the single parameter 'account_id'. The parameter name is self-explanatory, but the description should clarify its optionality and behavior when null.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('current portfolio positions'), which distinguishes it from sibling tools like ibkr_get_account_summary or ibkr_get_open_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a market data snapshot. For options, pass expiry (YYYYMMDD), strike, and right.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| sec_type | No | STK | |
| exchange | No | SMART | |
| currency | No | USD | |
| expiry | No | ||
| strike | No | ||
| right | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must disclose behavioral traits. It states 'Get a market data snapshot' implying a read operation, but does not mention latency, rate limits, authentication requirements, error behavior, or what constitutes a snapshot. The lack of detail leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences, both adding value: the first defines the core action, the second provides critical option parameter guidance. No unnecessary words. However, it could be more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain return values. It does not describe what the snapshot includes (e.g., bid, ask, last price). Also lacks prerequisites, error handling, or usage context for a 7-parameter tool. The description is too sparse for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate for all 7 parameters. It only addresses three option-related parameters (expiry, strike, right) with format hints, but ignores symbol, sec_type, exchange, and currency. This is insufficient to fully clarify parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get a market data snapshot', which clearly indicates the tool retrieves current market data. The addition of option parameter requirements provides specificity. However, it does not explicitly differentiate from sibling tools like ibkr_get_historical_bars or ibkr_get_option_chain, but the snapshot nature implies a distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as ibkr_get_historical_bars for historical data or ibkr_get_option_chain for option chains. The description merely notes option parameters but lacks context on tool selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check IB Gateway connection and account mode.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the purpose but does not disclose behavioral traits such as read-only status, failure behavior, or authentication needs. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero waste, directly stating the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, but the description omits return value information (e.g., status or boolean). Without output schema, the description should clarify what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description cannot add parameter meaning. According to guidelines, 0 parameters gives a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check IB Gateway connection and account mode' uses specific verbs and resources, clearly distinguishing it from sibling tools like ibkr_cancel_order or ibkr_get_account_summary, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Usage as a preliminary health check is implied but not stated, lacking context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place a single-leg option order. Paper account only.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| expiry | Yes | ||
| strike | Yes | ||
| right | Yes | ||
| action | Yes | ||
| quantity | Yes | ||
| order_type | No | MKT | |
| limit_price | No | ||
| exchange | No | SMART | |
| currency | No | USD | |
| account_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It only mentions 'paper account only,' omitting details like order lifecycle, confirmation, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, but could include more critical details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks essential context for a complex trading tool, such as output information, order type behavior, and parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds no information about any of the 11 parameters. With 0% schema description coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it places a single-leg option order, distinguishing it from the sibling ibkr_place_stock_order. Includes the constraint 'paper account only'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly restricts usage to paper accounts, but does not provide guidance on when to use this tool versus other order tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place a stock order. Paper account only.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| action | Yes | ||
| quantity | Yes | ||
| order_type | No | MKT | |
| limit_price | No | ||
| exchange | No | SMART | |
| currency | No | USD | |
| account_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Place a stock order. Paper account only.' It does not disclose important behavioral traits such as whether the order is immediately submitted, what the response contains, error handling, authentication requirements, or potential side effects. For a mutative tool like placing orders, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences. The first sentence states the core purpose, and the second adds a critical constraint. It is front-loaded and contains no filler. However, it could be slightly expanded to include parameter hints without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is incomplete. It does not explain how to use the parameters, what the tool returns, or how to interpret results. It lacks context for selecting this tool over siblings and does not cover important aspects like order lifecycle or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The tool description provides zero information about the 8 parameters (symbol, action, quantity, etc.). It does not explain the meaning of action (BUY/SELL), order type (MKT/LMT), limit price, or other fields. The description adds no value beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Place a stock order' which is a specific verb and resource. The name 'ibkr_place_stock_order' and description distinguish it from sibling tools like 'ibkr_place_option_order' (for options) and 'ibkr_cancel_order' (for cancellations). However, it does not explicitly differentiate from these siblings in the description text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Paper account only', which provides a clear constraint on when to use this tool (paper trading environment). However, it does not provide guidance on when to use this tool versus alternatives like 'ibkr_place_option_order' or 'ibkr_cancel_order'. No explicit when-to-use or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0ibkr_cancel_orderibkr_get_account_summaryibkr_get_daytrade_statusibkr_get_historical_barsibkr_get_open_ordersibkr_get_option_chainibkr_get_positionsibkr_get_quoteibkr_health_checkibkr_place_option_orderibkr_place_stock_orderScored across 11 tools
Each tool has a distinct and clear purpose, covering different aspects of brokerage operations such as orders, account info, market data, and positions. No two tools have overlapping functionality.
All tool names follow a consistent 'ibkr_verb_noun' pattern with lowercase and underscores, using standard verbs like get, place, cancel, and list. The naming is uniform and predictable.
With 11 tools, the server covers core brokerage operations without being overwhelming. The count is well-scoped for its purpose.
The tool set covers essential operations: account summary, positions, orders, quotes, historical data, and health check. It lacks order modification and support for multi-leg options or other asset types, but core workflows are well-represented.
Connect any MCP client to MetaTrader 4/5 to read prices, manage positions, and place trades.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
Open-source MCP server for Zerodha Kite Connect. Portfolio, market data, backtesting, alerts.
MCP server with quote and live cryptocurrency price tools, local and cloud-deployed transports.
