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 show my account summary"
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.
ibkr-mcp is a read-only MCP server for Interactive Brokers IBKR Gateway or TWS. It connects to an already running socket API session and exposes account, contract, execution, and historical-data queries to MCP clients over stdio.
The server does not implement any order-entry operations. There are no tools for placing, modifying, or cancelling orders.
Tool | Purpose |
| Confirm connectivity and return IBKR server time. |
| List managed accounts visible to the current login. |
| Fetch account summary values such as cash, buying power, and margin. |
| List open positions across accessible accounts. |
| List currently open orders visible to the session. |
| Fetch execution reports with optional account, symbol, side, and time filters. |
| Search contracts by ticker or company name. |
| Resolve a partial contract definition into concrete IBKR contract details. |
| Fetch read-only historical bars for a contract. |
Related MCP server: IBKR MCP Server
Every registered MCP tool is read-only.
The server never calls IBKR APIs for order placement, modification, or cancellation.
A local process lock prevents duplicate ibkr-mcp instances from starting against the same IBKR_HOST / IBKR_PORT / IBKR_CLIENT_ID combination.
You should still enable IBKR's own Read-Only API setting if you want Gateway- or TWS-level enforcement as a second guardrail.
Node.js and npm
A running IBKR Gateway or TWS session
Socket API access enabled in that IBKR session
In IBKR Gateway or TWS:
Open the API settings page.
Enable ActiveX and Socket Clients.
Set the socket port to the value you want this server to use.
Enable Read-Only API if you want IBKR to enforce read-only access too.
Allow 127.0.0.1 or your MCP host in trusted IPs if your IBKR configuration requires it.
The server default is IBKR_PORT=4002, which matches the common IBKR Gateway paper-trading setup. If your session uses a different port, set IBKR_PORT explicitly.
npm install
npm run buildUseful development commands:
npm run dev
npm run typecheckIBKR_HOST=127.0.0.1 \
IBKR_PORT=4002 \
IBKR_CLIENT_ID=19191 \
npm startIBKR_CLIENT_ID must be unique for the API client session you want to open. Run exactly one ibkr-mcp process per IBKR_HOST / IBKR_PORT / IBKR_CLIENT_ID.
If your MCP client launches this server for you, do not also leave a separate npm start process running against the same target. The server will fail fast if another instance already holds the same lock.
Variable | Default | Description |
|
| Hostname of the IBKR Gateway or TWS socket API endpoint. |
|
| Socket API port. |
|
| API client ID used when connecting to IBKR. |
|
| Request timeout for IBKR API calls. |
|
| Default account group for |
| conservative defaults | Optional comma-separated override for summary fields. |
Default account summary tags:
AccountType,NetLiquidation,TotalCashValue,SettledCash,BuyingPower,AvailableFunds,ExcessLiquidity,GrossPositionValue,InitMarginReq,MaintMarginReq,DayTradesRemainingPoint your MCP client at the built server entrypoint:
{
"mcpServers": {
"ibkr": {
"command": "node",
"args": ["/absolute/path/to/ibkr-mcp/dist/index.js"],
"env": {
"IBKR_HOST": "127.0.0.1",
"IBKR_PORT": "4002",
"IBKR_CLIENT_ID": "19191"
}
}
}
}This project uses stdio transport. That means each MCP client normally starts its own server process. If you need multiple clients to share one IBKR session, move to a shared daemon or network transport rather than launching separate stdio instances.
ibkr_executions accepts either time in raw IB format (YYYYMMDD HH:mm:ss) or since in RFC3339 form, but not both.
ibkr_search_contracts is useful for discovery; ibkr_contract_details is the better follow-up when you need a specific contract definition for downstream calls.
For stock and option lookups, the server infers SMART as the default exchange when appropriate. For cash pairs, it infers IDEALPRO.
Historical data, executions, and some contract lookups still depend on the permissions attached to the logged-in IBKR user.
Connection failures usually mean the IBKR session is not running, the socket API is disabled, the port is wrong, or the client ID is already in use.
Duplicate-process errors mean another ibkr-mcp process is already running with the same host, port, and client ID combination.
Empty or incomplete market-data responses often point to IBKR permissions, exchange entitlements, or an underspecified contract.
This server does not launch IBKR Gateway or TWS. It only connects to an existing API endpoint.
List managed IBKR accounts visible to the current Gateway login.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a meaningful scope detail: only accounts visible to the current Gateway login are returned. It does not describe return format or edge cases, but for a simple read-only list this is adequate.
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?
A single focused sentence that front-loads the action and resource with no unnecessary words. Every part earns its place.
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 zero-parameter read-only tool, the description provides enough context to know what the tool does and the scope of its result. It does not specify whether the return contains account IDs, names, or metadata, but given the lack of input parameters and output schema, this is a minor gap.
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 the input schema is empty, so there are no parameter semantics for the description to add. The scope qualifier usefully explains why no account filter parameter is needed.
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 a specific verb ('List') and resource ('managed IBKR accounts') with an explicit scope ('visible to the current Gateway login'). This makes it distinct from siblings like ibkr_account_summary, which summarizes rather than lists.
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 gives no guidance on when to use this tool versus siblings such as ibkr_account_summary or ibkr_positions. The scope qualifier is useful context, but there is no when/when-not or alternative selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return account summary values such as net liquidation, cash, buying power, and margin.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Comma-separated IBKR account summary tags. Defaults to a conservative set of portfolio and margin metrics. | AccountType,NetLiquidation,TotalCashValue,SettledCash,BuyingPower,AvailableFunds,ExcessLiquidity,GrossPositionValue,InitMarginReq,MaintMarginReq,DayTradesRemaining |
| group | No | Account group to query. Use "All" for all linked accounts or a configured advisor group. | All |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful detail about the specific summary metrics returned, but does not disclose behavioral nuances like how group aggregation works or how tags affect the response.
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 concrete examples. Every word earns its place and there is no redundant framing or filler.
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 read-only tool with two optional, well-documented parameters, the description plus annotations cover the essential calling context. Although there is no output schema, the listed examples and default tags give a clear sense of the return content.
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 100% and both tags and group have descriptive defaults, so the schema carries the parameter documentation burden. The description's examples align with tags but add little beyond what the schema already states.
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-resource pairing: 'Return account summary values', and clearly names the kind of data (net liquidation, cash, buying power, margin). This distinguishes it from sibling tools like ibkr_positions or ibkr_open_orders without ambiguity.
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?
There is no guidance on when to use this tool versus alternatives such as ibkr_accounts or ibkr_positions. The description states what it returns, but not when it should be preferred or when another tool is more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve an IBKR contract definition and return matching contract details.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of contract detail rows to return. | |
| contract | Yes | A partial IBKR contract definition. For stocks, symbol plus SMART/USD is usually enough. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds some context by framing the operation as resolving a partial definition into full details, but it does not disclose behaviors such as multiple matches being possible, how limit applies, or what happens when no contract matches.
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 with no filler. It front-loads the core action and resource. However, it is so terse that it misses opportunities to add routing or behavioral context that could have been included without bloating the description.
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?
There is no output schema, and the contract object has many nested fields with sparse per-field descriptions. The description does not explain what 'contract details' will be returned, how matching works, or how the limit parameter interacts with multiple results. For a tool with this complexity, the description is under-specified.
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 100% for the top-level parameters: 'limit' and 'contract' both have descriptions. The tool description itself adds little beyond the schema, but the schema's contract parameter description already explains the partial-definition semantics and gives a concrete example for stocks, so the baseline of 3 applies.
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 a clear verb ('Resolve') and resource ('IBKR contract definition') and indicates the tool returns matching contract details. It is understandable on its own, but it does not explicitly distinguish itself from the sibling ibkr_search_contracts, which also deals with contracts.
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 gives no guidance on when to use this tool versus alternatives like ibkr_search_contracts. The only usage hint ('For stocks, symbol plus SMART/USD is usually enough') lives inside the schema's contract parameter description, not in the tool description, and it addresses input construction rather than tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return execution reports using optional filters such as account, symbol, side, or time.
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | Filter by execution side. | |
| time | No | Raw IBKR execution filter time in "YYYYMMDD HH:mm:ss" format, interpreted by Gateway in its login timezone. | |
| since | No | RFC3339 timestamp. Converted to IBKR execution filter time using the local machine timezone. | |
| symbol | No | Filter by underlying symbol. | |
| secType | No | Filter by IBKR security type. | |
| acctCode | No | Filter by IBKR account code. | |
| clientId | No | Filter by API client ID. | |
| exchange | No | Filter by exchange. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already convey that the tool is read-only and non-destructive, so the description adds little behavioral context beyond that. It does not disclose default behavior when no filters are supplied, output size, pagination, or any 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?
The description is a single front-loaded sentence that states the action, resource, and key capability without any filler. Every word contributes to understanding the tool's 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?
The combination of the description, 100% schema coverage, and read-only annotations is minimally sufficient for an agent to invoke the tool with optional filters. However, the description does not explain the return format, no-filter behavior, or potential constraints, and there is no output schema to fill that gap.
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 100%, so all eight parameters are already documented in the input schema. The description only gestures at filters such as account, symbol, side, or time, adding no format, enum, or timezone details beyond what the schema provides.
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 identifies the resource as 'execution reports' and the action as 'Return', making the tool's purpose immediately understandable. This distinguishes it from sibling tools like ibkr_positions, ibkr_open_orders, and ibkr_historical_bars.
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 about when to use this tool versus its siblings, nor does it mention any exclusions or prerequisites. The only usage hint is the list of optional filters, which is implicit rather than explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch read-only historical bars for a contract from IBKR Gateway.
| Name | Required | Description | Default |
|---|---|---|---|
| useRTH | No | If true, restrict bars to regular trading hours. | |
| barSize | No | Historical bar size. | 5 mins |
| contract | Yes | A specific IBKR contract. For reliable results, include symbol, secType, exchange, and currency. | |
| formatDate | No | 1 for string timestamps, 2 for Unix epoch timestamps. | |
| whatToShow | No | IBKR data source for the bars. | TRADES |
| durationStr | No | IB duration string such as "1 D", "2 W", or "1 M". | 1 D |
| endDateTime | No | Optional end datetime in IB format (YYYYMMDD HH:mm:ss) or omit for now. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly labels the operation 'read-only', which aligns with the annotations readOnlyHint=true and destructiveHint=false. It adds mild context by mentioning IBKR Gateway, but does not disclose expected output shape, timezone behavior, or potential connectivity 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?
The description is a single, front-loaded sentence with no wasted words. It conveys the core action, resource, and source in under 15 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?
The schema fully documents all seven parameters, including the nested contract object, so parameter coverage is strong. However, with no output schema, the description does not clarify the response format or any limits, leaving some contextual ambiguity for an agent invoking the 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?
Schema description coverage is 100%, with meaningful defaults and enums already documented for parameters like barSize, whatToShow, and formatDate. The tool description itself adds little parameter-level meaning beyond identifying 'contract' as the target.
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 verb 'Fetch' and the resource 'historical bars for a contract', with the source 'IBKR Gateway' adding specificity. It is easily distinguishable from all sibling tools, none of which retrieve historical bar data.
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 makes the basic use case clear: fetch historical bars for a contract. However, it provides no explicit guidance on prerequisites such as resolving a contract via search_contracts or contract_details, and no comparison to alternatives, though no sibling tool directly overlaps in purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List currently open orders visible to the Gateway session. This server does not place, modify, or cancel orders.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's 'does not place, modify, or cancel orders' is largely redundant with structured metadata. It does add the useful behavioral scope of 'visible to the Gateway session,' but otherwise does not disclose additional behavior such as output format, pagination, or account filtering.
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 two sentences long, front-loaded with the primary purpose, and contains no filler. The second sentence earns its place by reinforcing the non-mutating nature of the tool.
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 zero-parameter read-only listing tool, the description is complete enough for an agent to select and invoke it correctly. It states what will be returned conceptually (open orders), where the scope is limited (Gateway session), and what the tool will not do. No return schema is needed for this simple invocation.
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 effectively 100% with an empty object. The baseline for zero-parameter tools is 4, and the description correctly avoids inventing parameter details that do not 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 states a specific action ('List'), a clear resource ('currently open orders'), and a scope ('visible to the Gateway session'). It also explicitly distinguishes the tool from order-management actions by stating it does not place, modify, or cancel orders, which sets it apart from any potential mutation 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?
The description clearly conveys that this tool is for viewing open orders, and the explicit exclusion of place/modify/cancel gives useful when-not-to-use guidance. However, it does not name specific alternative tools for order mutation, so it falls just short of fully explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List open positions across all accessible IBKR accounts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the operation aggregates data across all accessible accounts, but it does not describe return structure, ordering, or other behavior beyond that baseline.
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 filler. It states the action, the resource, and the scope efficiently, and every word contributes meaning.
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 zero-parameter, read-only listing tool, the description is sufficient for an agent to select and invoke it: it names the resource and scope, and annotations cover side effects. A return-format description would be helpful but is not essential for this simple case.
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?
This tool has zero parameters, so there are no parameter semantics for the description to clarify. With no input schema properties, the baseline of 4 applies and the description needs to add nothing further about parameters.
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 ('List') and a specific resource ('open positions'), and scopes it to 'all accessible IBKR accounts.' This clearly distinguishes it from sibling tools like ibkr_open_orders or ibkr_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?
The description gives clear context for when to use this tool: to retrieve open positions across all accessible IBKR accounts. It does not explicitly name alternatives or exclusions, but the resource and scope make the intended use clear relative to its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search IBKR contracts by ticker or company name and return matching instrument descriptors.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of matches to return. | |
| pattern | Yes | Ticker prefix or company name fragment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false). The description adds that the tool returns matching instrument descriptors, which is useful given no output schema, but it does not disclose matching behavior, result limits beyond the schema, or descriptor fields. No contradiction with annotations.
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-ordered sentence: action verb, resource, search criteria, and return value. There is no filler or redundancy, and every word contributes useful 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?
For a low-complexity, read-only search tool with two fully documented parameters and no output schema, the description plus schema provides adequate guidance: what to search, what is returned, and that it is non-destructive. It could specify result shape or example patterns, but these are not essential for correct invocation.
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?
Input schema coverage is 100%, and the schema already documents both parameters, including default/maximum for limit. The description's mention of searching by ticker or company name closely mirrors the schema's 'Ticker prefix or company name fragment,' so it adds no meaningful semantic beyond structured data.
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 ('Search') and resource ('IBKR contracts'), and specifies both the input types (ticker or company name) and the outcome ('return matching instrument descriptors'). This clearly differentiates it from siblings like ibkr_contract_details, which would be used for a known contract's details.
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 clearly frames the use case: find IBKR contracts by ticker or company name. It does not explicitly name alternative tools or state when not to use it, but the search-focused wording is sufficient to guide an agent among the read-only sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm read-only connectivity to the configured IBKR Gateway session and return server time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds 'read-only connectivity' and 'server time,' which aligns with annotations but discloses no additional behavioral traits such as error handling, connection state semantics, or potential side effects. It does not contradict annotations.
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?
A single, front-loaded sentence with no redundant wording. Every phrase adds meaning: 'read-only connectivity,' 'configured IBKR Gateway session,' and 'return server time.' It is appropriately concise for a zero-parameter tool.
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 zero-parameter tool with no output schema, the description mostly suffices: it states the action and a concrete return value (server time). However, it could be clearer about the exact return shape or how connectivity confirmation is represented (e.g., success status, boolean, or error), so it is not fully complete.
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 baseline is 4. The description correctly focuses on behavior and return values rather than input semantics, and no parameter documentation is needed.
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 a specific action ('Confirm read-only connectivity') and a resource ('IBKR Gateway session'), plus an additional output ('return server time'). This distinguishes it from all sibling tools, which focus on accounts, positions, orders, or market data.
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 tool's purpose is self-evident as a connectivity/status check, and the sibling list makes it distinct from data-retrieval tools. However, there is no explicit guidance on when to use this tool or when to prefer an alternative, so usage is only implied.
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.
v1.0.0ibkr_account_summaryibkr_accountsibkr_contract_detailsibkr_executionsibkr_historical_barsibkr_open_ordersibkr_positionsibkr_search_contractsibkr_statusScored across 9 tools
Each tool maps to a distinct IBKR resource: accounts, positions, account summary, open orders, executions, contract search, contract details, historical bars, and gateway status. Even the two contract tools are clearly separated as discovery versus detail resolution.
All tools share a consistent lowercase ibkr_ prefix and mostly use noun-style resource names such as ibkr_positions and ibkr_account_summary. The one action-style name, ibkr_search_contracts, is a minor deviation from an otherwise predictable pattern.
Nine tools is a well-scoped size for a read-only IBKR integration. Each tool covers a distinct data need without redundant overlap or unnecessary extras.
The set covers the core read-only brokerage workflow: accounts, positions, summary, orders, executions, contract discovery, and historical bars. A real-time quote or market data snapshot tool would round it out, but this is a minor gap given the read-only orientation.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Open-source MCP server for Zerodha Kite Connect. Portfolio, market data, backtesting, alerts.
