Loading ToolBench
Interactive Brokers MCP Server providing tools for market data, positions, contract details, options chains, scanner results, and historical price data via FastAPI with MCP integration
The server provides 14 tools with generally adequate naming and schema structure. Most tools follow verb_noun conventions (get_*, create_). Descriptions are present for all tools and many parameters, but are often generic or lack LLM-optimized guidance. Parameter schemas use proper JSON Schema with types, but descriptions vary significantly in quality and completeness. Error handling is minimal, most tools lack recovery guidance. Several tools have deeply nested optional parameters that could benefit from flattening. The limit_order tool critically lacks parameter validation guidance (no price constraints, no quantity bounds). Output schemas are documented informally but not rigorously specified in return types.
Get contract details for a given symbol.
Get and filter option chain tickers based on market data criteria.
Fetch OHLCV bars for any IB-supported contract over a date range.
Get the logs from the IBKR Gateway container.
Get the current status of the IBKR Gateway.
Get options chain for a given underlying contract.
Get positions for all accounts.
create_limit_order lacks critical parameter constraints and validation guidance. No documentation of valid price ranges, quantity bounds, or error conditions (e.g., what happens if price is negative, quantity is zero, or the account lacks buying power). LLM cannot safely use this tool without explicit constraints.
No error recovery guidance. None of the 14 tools provide actionable error messages or retry hints. When a tool fails, the LLM receives a generic error with no direction on next steps (e.g., 'Contract not found' should suggest 'Try get_scanner_results() with different parameters' or 'Call get_contract_details() with explicit exchange').
Deeply nested optional parameters reduce usability. Tools like get_contract_details and get_options_chain use nested 'options' and 'filters' objects with optional sub-fields. This forces LLMs to construct complex nested JSON. Flattening to top-level parameters (e.g., contract_expiry_date, contract_strike_price) would improve discoverability and reduce construction errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 8 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 53 | - | v1 |
Get the latest price snapshot for any IB-supported contract.
Get detailed scanner filter codes with examples and usage hints.
Get detailed scanner instrument codes with descriptions.
Get detailed scanner location codes with descriptions.
Execute scanner query with scan_code and optional filters.
Get detailed scanner scan codes with descriptions.
Get step-by-step workflow for using scanner effectively.
Get tickers for a list of contract IDs.
Missing output schema documentation. While individual tools hint at return structure (e.g., get_ibkr_gateway_status documents example JSON), there is no formal schema definition for return types. This forces LLMs to infer output structure, risking extraction errors and limiting downstream tool chaining confidence.
Scanner discovery tools (get_scanner_workflow, get_scanner_instrument_codes, etc.) lack explicit guidance on when to call them. Descriptions say 'Call this first', but do not specify prerequisites or the consequences of skipping the call. LLMs may invoke get_scanner_results directly without understanding available codes.
create_limit_order lacks idempotency guidance and confirmation pattern. This is a WRITE tool that modifies trading state, there is no dry_run parameter, no confirmation step, and no mention of side effects (e.g., partial fills, order rejection). Agents could accidentally place duplicate trades.