The ibkr-mcp server exposes an Interactive Brokers account (or an offline simulator) as a set of LLM-callable tools for account monitoring, market data, and risk-controlled order entry.
Check server status (get_status): View the active backend (mock or live IB), connection state, trading enablement, account ID, and current risk limits.
View account summary (get_account_summary): Retrieve net liquidation value, cash balance, buying power, and P&L.
View open positions (get_positions): List all holdings with quantity, average cost, market value, and unrealized P&L.
Get market quotes (get_quote): Fetch a real-time bid/ask/last/mid price snapshot for any stock symbol.
View open orders (get_open_orders): See all working (unfilled) orders currently resting at the venue.
View trade blotter (get_trades): Review all executions and fills for the current session.
Preview an order (preview_order): Step 1 of the trading flow — validate a proposed BUY/SELL order (market or limit) against pre-trade risk limits without submitting it. Returns an estimated notional, risk decision (approved/rejected with reasons), and a single-use confirmation_token if approved.
Place an order (place_order): Step 2 of the trading flow — submit a previously previewed order using its confirmation_token. The order is re-validated against risk limits at execution time before submission.
Cancel an order (cancel_order): Cancel a working order by its order ID.
Robust risk management: All orders are subject to configurable pre-trade checks, including per-order quantity/notional caps, position notional caps, short-selling restrictions, optional symbol whitelists, and daily order count limits.
Flexible backend: Runs with an offline market simulator by default (zero setup required) or connects to a live IBKR paper/live account.
Click on "Install 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 preview a buy order for 10 shares of AAPL"
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.
A Model Context Protocol server that exposes an Interactive Brokers account — account data, market data, and order entry — as a set of tools an LLM agent (Claude Desktop, Claude Code, any MCP client) can call. It pairs that with a pre-trade risk engine and a two-step confirm-before-trade flow so an autonomous model can't fat-finger a live account.
The whole thing runs offline out of the box against a built-in market
simulator, so it's reviewable with zero setup — no TWS, no IB Gateway, no
network, not even the mcp package for the demo and tests.
python examples/demo_cli.py # full preview -> place -> blocked-order flow, offline
python tests/test_risk.py # 7 risk-engine tests
python tests/test_session.py # 6 session/safety-flow tests=== 5. Preview BUY 50 NVDA (risk check) ===
{
"symbol": "NVDA", "action": "BUY", "quantity": 50, "order_type": "MKT",
"reference_price": 167.95, "estimated_notional": 8397.5,
"risk": { "approved": true, "reasons": [] },
"trading_enabled": true,
"confirmation_token": "d2bfa616602b",
"token_expires_in_seconds": 120,
"next_step": "Call place_order('d2bfa616602b') to submit."
}
=== 6. Place order via confirmation token ===
{
"order_id": "1000", "symbol": "NVDA", "action": "BUY", "quantity": 50,
"status": "FILLED", "filled_quantity": 50, "avg_fill_price": 167.36,
"message": "Filled."
}
=== 9. Preview BUY 400 TSLA -- expect REJECT (over notional cap) ===
{
"symbol": "TSLA", "action": "BUY", "quantity": 400,
"estimated_notional": 99748.0,
"risk": {
"approved": false,
"reasons": [
"Order notional $99,748 exceeds per-order cap $20,000.",
"Resulting position notional $99,748 exceeds position cap $60,000."
]
},
"confirmation_token": null,
"next_step": "Order REJECTED by risk checks; not placeable."
}
=== 10. place_order with a bogus token -> guarded ===
{ "blocked": "Unknown or already-used confirmation token. Call preview_order first." }On the backends. The live
ib_asyncbackend (broker/ibkr.py) is fully implemented; the server simply defaults to the offline simulator so the project is reviewable with zero setup. Pointing it at a real IBKR paper account is a two-env-var change (IBKR_BACKEND=ib,IBKR_TRADING_ENABLED=true) — see Against a real (paper) IBKR account.
Letting an LLM place trades is the interesting, dangerous part. Three decisions carry the design:
The agent never touches the broker SDK directly. Tools talk to a
TradingSession, which talks to a Broker interface. Two implementations sit
behind that interface — a live ib_async backend and an in-memory simulator —
so the agent-facing contract is identical whether you're on a paper account or
running offline.
Trading is a two-step handshake, not one tool call. The model must
preview_order(...) first; that returns the live quote, the estimated
notional, a risk decision, and — only if risk passes and trading is enabled —
a single-use confirmation_token. Only place_order(token) submits. The order
is re-validated against the risk limits at execution time, because price
and position may have moved since the preview.
Safe by default. With no configuration you get the mock backend with
trading disabled (read-only). Going live is an explicit, multi-flag opt-in.
Related MCP server: IBKR TWS MCP Server
MCP client (Claude)
│ stdio / JSON-RPC
▼
┌──────────────────┐ tool docstrings = the agent's contract
│ server.py │ get_status · get_account_summary · get_positions
│ (FastMCP tools) │ get_quote · get_open_orders · get_trades
└────────┬─────────┘ preview_order ──► place_order · cancel_order
▼
┌──────────────────┐ two-step order flow, single-use confirmation tokens,
│ session.py │ execution-time re-validation
└────┬───────────┬─┘
▼ ▼
┌─────────┐ ┌──────────────────┐
│ risk.py │ │ broker/ (Broker) │
│ pre- │ │ ├─ mock.py ◄── offline simulator (default)
│ trade │ │ └─ ibkr.py ◄── live ib_async → TWS / IB Gateway
│ checks │ └──────────────────┘
└─────────┘Everything except server.py (FastMCP) and broker/ibkr.py (ib_async) is pure
standard library, which is why the simulator and tests need no dependencies.
Tool | Purpose |
| Backend, connection, trading on/off, active risk limits |
| Net liquidation, cash, buying power, P&L |
| Open positions with cost basis and unrealized P&L |
| Bid / ask / last / mid snapshot |
| Working (unfilled) orders |
| Execution blotter |
| Step 1 — risk-check an order, return a confirmation token |
| Step 2 — submit a previewed, re-validated order |
| Cancel a working order |
risk.py)Enforced before any order is accepted, and again at execution time:
per-order quantity cap
per-order notional cap
resulting position notional cap
short-selling switch (off by default)
optional symbol whitelist
daily order count cap
All are configurable via environment variables (see .env.example).
python examples/demo_cli.py
python tests/test_risk.py && python tests/test_session.pypip install "mcp[cli]"
python -m ibkr_mcp.server # serves over stdioRegister it with an MCP client using examples/claude_desktop_config.example.json.
pip install ib_async
Launch TWS or IB Gateway with the API enabled, logged into a paper
account (account id starts with DU).
Set the environment and run:
export IBKR_BACKEND=ib
export IBKR_TRADING_ENABLED=true
export IBKR_PORT=7497 # paper TWS
export IBKR_ACCOUNT_ID=DUxxxxxxx
python -m ibkr_mcp.serverSafety: keep
IBKR_TRADING_ENABLED=falsefor read-only analysis. Point at a paper account before ever enabling trades. The risk caps are the backstop, not the first line of defense — the read-only default is.
ibkr_mcp/
models.py dataclasses: Quote, Position, Order, Trade, AccountSummary
config.py env-driven Settings + RiskLimits (safe defaults)
risk.py pure pre-trade risk engine
session.py two-step order flow, token store, re-validation
server.py FastMCP tool layer (the agent contract)
broker/
base.py abstract Broker interface
mock.py offline market simulator
ibkr.py live ib_async backend
examples/ offline demo + MCP client config
tests/ risk + session/safety-flow testsMIT
Cancel a working order by its order_id (from get_open_orders).
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It does not mention idempotency, error conditions, side effects, or return behavior, leaving gaps for an AI agent.
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, well-structured sentence that front-loads the action and parameter, with no unnecessary words.
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 parameter and no output schema, the description covers the core purpose and parameter source but omits common behavioral details like response confirmation or error handling, making it minimally adequate.
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 description adds value to the schema by indicating the order_id is obtained from get_open_orders, which is not present in the schema definition (0% coverage). This provenance helps the agent correctly use 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's action: 'Cancel a working order'. It specifies the required parameter (order_id) and its source (from get_open_orders), differentiating it from sibling tools like place_order or 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 implies usage context by referencing get_open_orders as the source of the order_id, but does not explicitly state when to use this tool over alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return account net liquidation, cash, buying power and P&L.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like read-only, authentication needs, or rate limits. It only describes the returned data, omitting any behavioral context such as destructiveness or safety.
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, efficient sentence that conveys the essential purpose without any redundant or extraneous content. It is perfectly concise.
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, the description adequately lists the key return values. However, it does not specify units, whether values are current or historical, or provide examples. It is sufficient for a simple retrieval tool.
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 zero parameters, so the baseline is 4. The description adds no parameter information, which is acceptable since no parameters exist.
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 (Return) and specifies the exact resources: net liquidation, cash, buying power, and P&L. This distinguishes it from siblings like get_positions (individual positions) and get_status (general status).
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 vs. alternatives. It merely lists outputs, leaving the agent to infer context. No explicit when/when-not statements or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return working (unfilled) orders currently resting at the venue.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states the return value but does not mention authentication needs, rate limits, data freshness, or whether the tool may be empty. The minimal description leaves significant behavioral gaps.
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 unnecessary words. It is perfectly concise and front-loads the purpose.
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 no parameters and an output schema exists, the description adequately states the tool's function. It could mention that it returns all open orders without filtering, but it is still complete for its simplicity.
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?
There are zero parameters, so the schema covers everything. Baseline is 4 as per guidelines. The description adds no parameter info, which is acceptable.
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 uses a specific verb 'Return' and identifies the resource 'working (unfilled) orders currently resting at the venue'. It is clear, unambiguous, and distinguishes from sibling tools like get_trades or 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?
No guidance is provided on when to use this tool versus alternatives (e.g., get_trades for filled orders or get_positions for holdings). The description does not mention when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all open positions with quantity, average cost, market price, market value and unrealized P&L.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states it returns data but does not comment on read-only nature, authentication needs, rate limits, or any side effects. Minimal 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the main action ('Return all open positions') and includes essential details efficiently. No unnecessary words.
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 zero parameters and an existing output schema, the description adequately covers what the tool does. It could mention if any state changes occur, but for a read-only reporting tool, it is complete enough.
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 tool has zero parameters and schema coverage is 100%. The description adds value by enumerating the output fields, which is helpful beyond the empty input schema. Baseline for 0 params is 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 clearly states it returns open positions with specific fields (quantity, average cost, market price, market value, unrealized P&L). It effectively distinguishes from sibling tools like get_open_orders and get_trades.
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 it is for retrieving positions, but does not explicitly state when to use it versus alternatives or provide any when-not-to-use guidance. Usage is implied by the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a current bid/ask/last/mid snapshot for a stock symbol (e.g. AAPL).
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'current' snapshot without details on data freshness, rate limits, or permission requirements.
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 with 16 words, front-loaded with the action and key output. No unnecessary repetition or fluff.
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?
No output schema, and description fails to specify return structure (e.g., object fields). Lacks guidance on incomplete symbols or error handling.
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?
Only one parameter (symbol) with no schema description (0% coverage). The description provides an example (e.g. AAPL) but adds minimal semantic meaning beyond the parameter name.
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 returns a current bid/ask/last/mid snapshot for a stock symbol, with an example (AAPL). This distinguishes it well from siblings like get_positions or get_account_summary.
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 usage context or alternatives are mentioned. The description does not specify when to use this versus other data tools (e.g., get_status).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return server status: backend (mock/ib), connection, whether trading is enabled, the account id, and the active risk limits. Call this first to understand what the account can and cannot do.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies read-only behavior but doesn't explicitly state safety or side effects. Adds context about purpose (understand account capabilities) but could disclose more like 'does not modify state.' Still adequate for a simple status tool.
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?
Two concise sentences: first describes what's returned, second advises when to call. Zero wasted words, information is front-loaded and directly useful.
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 tool with no parameters and no output schema, the description sufficiently lists returned fields and gives usage guidance. Could be improved by specifying return format or typical values, but current level is adequate for its simplicity.
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 is 4. Description adds no parameter semantics as none are needed. Schema coverage is 100% (empty), so no gaps.
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 the tool returns server status with specific fields (backend, connection, trading enabled, account id, risk limits). Uses strong verb 'Return' and distinct resource 'server status', distinguishing it from sibling tools like get_account_summary or 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?
Explicitly advises 'Call this first to understand what the account can and cannot do.' Provides clear context for when to use the tool, making it a starting point before other operations. No alternatives needed given its unique role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the executions/fills for this session (the trade blotter).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the basic function, omitting whether the operation is read-only, requires authentication, or has rate limits. No additional behavioral context is provided.
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 unnecessary words. It is front-loaded with the key information and is perfectly concise.
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 no parameters and an output schema exists, the description is largely complete. It could be improved by clarifying what 'this session' refers to, but overall it adequately describes the tool's function.
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 tool has zero parameters, so schema coverage is effectively 100%. The description adds context beyond the empty schema by explaining the output (executions/fills for the session), warranting a score above the baseline of 3.
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 returns executions/fills for the current session (trade blotter). It distinguishes from sibling tools like get_positions, get_open_orders, and get_quote by specifying exactly what data is returned.
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. It does not mention conditions, prerequisites, 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.
STEP 2 of 2 for trading. Submit the order previously approved by
preview_order, identified by its confirmation_token. The order is
re-validated against risk limits at this moment before submission. Tokens are
single-use and expire. Returns the resulting order with its fill status.
| Name | Required | Description | Default |
|---|---|---|---|
| confirmation_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses submission, re-validation, token constraints, and return value. No annotations present, so description carries full burden; minor lack of failure scenario details.
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?
Three concise sentences, front-loaded with purpose, no redundancy.
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 one-parameter tool with no output schema, all necessary context is provided: usage flow, parameter meaning, behavior, and return value.
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?
Only parameter is confirmation_token; description explains it's from preview_order, single-use, expires. Schema has no descriptions, so description fully compensates.
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's step 2 of 2 for trading, submitting a pre-approved order from preview_order. Distinguishes from siblings like preview_order and cancel_order.
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 positions as step 2 after preview_order, mentions token expiry and risk re-validation. However, does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
STEP 1 of 2 for trading. Validate a proposed order against the risk limits
WITHOUT sending it. Returns the live quote, estimated notional, the risk
decision (approved + reasons), and -- only if approved AND trading is enabled
-- a one-time confirmation_token. Show the user the risk decision and cost,
then call place_order with that token.
action: BUY or SELL. order_type: MKT or LMT (limit_price required for LMT).
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| symbol | Yes | ||
| quantity | Yes | ||
| order_type | No | MKT | |
| limit_price | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior: it does not send the order, returns a one-time confirmation token under conditions, and provides risk decision.
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?
Two sentences plus a parameter note, highly front-loaded with essential purpose and flow. No redundant or extra sentences.
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?
Explains the tool's role in a two-step process, what it returns, and key conditions. Minor gap: no mention of error handling or what happens if trading is disabled.
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?
Adds meaning for action (BUY/SELL) and order_type (MKT/LMT with limit_price required for LMT). Symbol and quantity are not further explained. With 0% schema coverage, partial compensation.
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 is 'STEP 1 of 2 for trading' and validates a proposed order without sending it. It distinguishes from place_order and specifies the return values.
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 instructs to call place_order after with the token, and notes requirements for order types. Lacks explicit 'when not to use' but sibling tools and context provide clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct function: account summary, positions, orders, quotes, trades, status, and a two-step order placement. No overlap in purpose.
All tool names follow a consistent verb_noun pattern (e.g., cancel_order, get_account_summary, place_order) using underscores.
9 tools is well-scoped for an IBKR trading server, covering account info, order management, quoting, and trade history without being excessive.
Core workflows are covered: quoting, order preview/placement/cancellation, account summary, positions, open orders, and trade blotter. Missing perhaps order modification, but that can be handled via cancel+reorder.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI agents to bank accounts, transactions, balances, and investments.
Build, backtest, and deploy quantitative trading strategies from your AI agent.
Connect AI agents to financial institution origination, analytics, and compliance workflows.
Connects AI agents to live, verified financial data from 18,000+ institutions — ready to reason from
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kris-Wang05/ibkr-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
