How do I use ibkr-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ibkr-mcp-server Show me my current portfolio" 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-server

by ArjunDivecha

Overview Schema Related Servers Score Discussions

Python

Local

IBKR MCP Server

A professional Model Context Protocol (MCP) server for Interactive Brokers API integration, designed for use with Claude Desktop and Claude Code.

Python 3.10+ License: MIT

Features

✅ Multi-Account Support - Switch between multiple IBKR accounts
✅ Short Selling Analysis - Shortable shares, borrow rates, margin requirements
✅ Real-time Market Data - Live quotes, historical data, options chains
✅ Portfolio Management - Positions, P&L, account summaries
✅ Trading Operations - Place, modify, cancel orders (with safety checks)
✅ Auto-Reconnection - Handles TWS/Gateway restarts gracefully
✅ Production Ready - Proper error handling, logging, and monitoring

Related MCP server: IBKR-MCP-Server

Quick Start

Prerequisites

Python 3.10 or higher
Interactive Brokers account with TWS or IB Gateway
Claude Desktop or Claude Code

Installation

Clone the repository:

git clone https://github.com/yourusername/ibkr-mcp-server.git
cd ibkr-mcp-server

Run the setup script:

# macOS/Linux
chmod +x scripts/setup.sh
./scripts/setup.sh

# Windows
scripts\setup.bat

Configure your settings:

cp .env.example .env
# Edit .env with your IBKR settings

Start TWS/IB Gateway and enable API connections
Test the server:
```
python -m ibkr_mcp_server.main --test
```

Claude Integration

Claude Desktop: Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "ibkr": {
      "command": "python",
      "args": ["-m", "ibkr_mcp_server.main"],
      "cwd": "/path/to/ibkr-mcp-server"
    }
  }
}

Claude Code:

claude mcp add ibkr 'python -m ibkr_mcp_server.main' --cwd /path/to/ibkr-mcp-server

Usage Examples

Basic Operations

# Get portfolio across all accounts
"Show me my current portfolio"

# Switch accounts
"Switch to account DU7654321"

# Market data
"Get real-time quotes for AAPL, TSLA, MSFT"

Short Selling Analysis

# Complete short selling analysis
"Analyze short selling for GME, AMC, BBBY - show availability, borrow costs, and margin requirements"

# Check specific account
"Check shortable shares for TSLA in my paper trading account"

Trading Operations

# Place orders (paper trading recommended)
"Place a limit order to buy 100 shares of AAPL at $150"

# Check margin requirements
"What are the margin requirements for shorting 200 shares of TSLA?"

Available Tools

Tool	Description
`get_portfolio`	Current portfolio positions and P&L
`get_account_summary`	Account balances and key metrics
`switch_account`	Switch between IBKR accounts
`check_shortable_shares`	Short selling availability
`get_margin_requirements`	Margin requirements for securities
`get_borrow_rates`	Stock borrow rates (short selling costs)
`short_selling_analysis`	Complete short selling analysis
`get_market_data`	Real-time market quotes
`get_historical_data`	Historical price data
`place_order`	Place trading orders (with safety checks)
`get_connection_status`	Check IBKR connection status

Configuration

Environment Variables

# IBKR Connection
IBKR_HOST=127.0.0.1
IBKR_PORT=7497  # 7497=TWS Paper, 7496=TWS Live, 4001=Gateway
IBKR_CLIENT_ID=1
IBKR_IS_PAPER=true

# Logging
LOG_LEVEL=INFO

# Safety
ENABLE_LIVE_TRADING=false  # Set to true for live trading
MAX_ORDER_SIZE=1000  # Maximum order size

TWS/Gateway Setup

Start TWS or IB Gateway
Go to Configuration → API → Settings
Enable "ActiveX and Socket Clients"
Set socket port (7497 for paper, 7496 for live)
Add 127.0.0.1 to "Trusted IPs"
Check "Download open orders on connection"

Development

Setup Development Environment

pip install -e ".[dev]"
pre-commit install

Running Tests

pytest tests/ -v

Code Quality

black ibkr_mcp_server/
isort ibkr_mcp_server/
mypy ibkr_mcp_server/

Deployment

Auto-start on Boot (macOS)

python scripts/install_service.py --platform macos

Auto-start on Boot (Linux)

python scripts/install_service.py --platform linux

Docker Deployment

docker build -t ibkr-mcp-server .
docker run -d --name ibkr-mcp -p 8080:8080 ibkr-mcp-server

Documentation

Safety & Disclaimers

⚠️ Important Safety Notes:

Always test with paper trading first
Verify all data in TWS before making trading decisions
This software is for educational purposes
Use at your own risk
No warranty provided

Contributing

Fork the repository
Create a feature branch
Make your changes
Add tests
Submit a pull request

License

MIT License - see LICENSE file for details.

Support

Available Tools

8 tools

check_shortable_sharesB

Check short selling availability for securities

ParametersJSON Schema

Name	Required	Description	Default
`symbols`	Yes	Comma-separated list of symbols
`account`	No	Account ID (optional, uses current account if not specified)

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden. It describes the function as a check but does not disclose whether it is read-only, requires authorization, handles errors, or what rate limits apply. For a check operation, it should at least imply it is non-destructive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is concise and front-loaded. It contains no redundant information and is easy for an AI agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description provides the core purpose but lacks details on the return value format. The agent might need to know whether the response is a list of available symbols or a boolean per symbol. Adding a brief note on output would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides detailed descriptions for both parameters (symbols as comma-separated list, account as optional with default). Since schema coverage is 100%, the description does not add additional meaning beyond what is already in the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Check short selling availability for securities' clearly specifies the action (check) and the resource (short selling availability for securities). It distinguishes the tool from its sibling 'short_selling_analysis', which likely involves deeper analysis rather than a simple availability check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 such as 'short_selling_analysis'. It does not state prerequisites, typical use cases, or situations where this tool should be avoided.

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

get_accountsB

Get available IBKR accounts and current account

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are present, and the description only implies a read operation ('Get'). It does not disclose any behavioral traits such as auth requirements or side effects, but the operation is inherently non-destructive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that directly states the tool's purpose with no unnecessary words. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the tool is simple with no parameters or output schema, the description lacks information about the return format or relationship to sibling tools. Given the sibling list, additional context about when to use this vs. 'get_account_summary' would be beneficial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema coverage is 100%. Baseline score of 4 applies since no parameter information is needed from the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resources 'available IBKR accounts' and 'current account'. It is sufficient for understanding the tool's purpose, though it does not explicitly differentiate from siblings like '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.

Usage Guidelines2/5

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. For example, it does not clarify the difference between 'get_accounts' and 'get_account_summary' or mention any prerequisites.

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

get_account_summaryB

Get account balances and key metrics from IBKR

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Account ID (optional, uses current account if not specified)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must fully convey behavioral traits. It only states a read operation ('Get') but omits details like authentication needs, error behavior, or rate limits, leaving the agent underinformed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

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 adequate but does not specify the return format or what 'key metrics' includes. Some gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the parameter description is clear in the schema. The tool description adds no new parameter-level meaning, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves account balances and key metrics, and it is distinct from sibling tools like get_portfolio (positions) or get_margin_requirements (specific metrics). However, 'key metrics' is slightly vague, preventing a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 such as get_accounts or get_portfolio. The agent receives no context for decision-making.

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

get_connection_statusB

Check IBKR TWS/Gateway connection status and account information

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only says 'Check', implying read-only, but no details on side effects, authentication, or response behavior. Fails to add value beyond the obvious.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no wasted words. Front-loaded with the action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no output schema, the description is adequate for a simple status check. However, it omits what exactly the output contains (e.g., boolean, string, or nested object) and does not leverage context from siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has zero parameters, so schema coverage is 100%. Description adds meaning by stating the tool checks connection status and account info, which is appropriate. Baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'Check' and resource 'IBKR TWS/Gateway connection status and account information'. It distinguishes from siblings like get_accounts and get_account_summary by focusing on status, but could be more explicit about the difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 alternatives like get_accounts or get_account_summary. No exclusions or prerequisites provided.

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

get_margin_requirementsC

Get margin requirements for securities

ParametersJSON Schema

Name	Required	Description	Default
`symbols`	Yes	Comma-separated list of symbols
`account`	No	Account ID (optional, uses current account if not specified)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, so the description must disclose behavioral traits. It does not mention that the operation is read-only, what happens with invalid symbols, or any rate limits. The minimal description lacks behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It is efficient, though slightly more detail could be added without sacrificing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description could explain the return structure. However, for a simple query tool, the purpose is somewhat self-explanatory. Still, completeness is adequate but could be improved (e.g., noting it returns an object per symbol).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage, describing both parameters ('symbols' and 'account'). The description adds no extra meaning beyond what the schema provides, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get margin requirements for securities' clearly states the verb (Get) and resource (margin requirements for securities). It distinguishes the tool from siblings like check_shortable_shares or get_account_summary by focusing on margin requirements, though it does not explicitly differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. There is no mention of prerequisites, context of use, or exclusions. The agent must infer usage from the purpose alone.

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

get_portfolioC

Retrieve current portfolio positions and P&L from IBKR

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Account ID (optional, uses current account if not specified)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, so the description must fully disclose behaviors. It only states a read operation ('Retrieve'), but does not mention data freshness, authorization needs, or potential latency, leaving agents uninformed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no redundant information. It is front-loaded and efficient, though it could be slightly more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional param, no output schema), the description is minimal. It lacks details on return format, data scope, or use cases, leaving agents with incomplete context for invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single parameter already described. The description adds no extra semantic value beyond the schema, which is adequate but not improved.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Retrieve' and the resource 'current portfolio positions and P&L from IBKR'. It is specific and distinguishes the tool's purpose from sibling tools like get_accounts or check_shortable_shares, though not explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 is provided. The description implies it is for portfolio viewing, but does not clarify scenarios where other tools like get_account_summary might be more appropriate.

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

short_selling_analysisA

Complete short selling analysis: availability, margin requirements, and summary

ParametersJSON Schema

Name	Required	Description	Default
`symbols`	Yes	Comma-separated list of symbols
`account`	No	Account ID (optional, uses current account if not specified)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description should disclose behavioral traits like read-only nature, permissions needed, or side effects. It only mentions analysis components but fails to state that it is a safe, non-destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that efficiently conveys the tool's purpose without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description should provide more detail about the returned data structure or any limitations. It only lists three analysis components vaguely, which may not suffice for an agent to set correct expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with descriptions for both parameters (symbols and account). The description does not add any additional meaning beyond what is already in the schema, meeting the baseline expectation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it performs a complete short selling analysis covering availability, margin requirements, and summary. This distinguishes it from sibling tools that focus on individual aspects like check_shortable_shares or get_margin_requirements.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies it is a comprehensive alternative to individual checks, but it does not explicitly state when to use this tool versus the separate tools for availability or margin.

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

switch_accountB

Switch between IBKR accounts

ParametersJSON Schema

Name	Required	Description	Default
`account_id`	Yes	Account ID to switch to

TDQS

B3/5.0

Behavior2/5

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

No annotations provided, so the description must disclose behavioral traits. It only states switching occurs but does not mention side effects, authentication requirements, or state changes (e.g., affecting subsequent requests).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short (one sentence) and front-loaded, but it sacrifices informative content. For a single-parameter tool, it is minimally adequate but not optimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description should provide more context about return values, state changes, or prerequisites. It fails to do so.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description adds no extra meaning beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Switch between IBKR accounts' clearly states a specific action on a specific resource, distinguishing it from sibling tools that read or analyze accounts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 alternatives. The description merely restates the name without providing context about prerequisites or comparison with sibling tools like get_accounts.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv0.1.0Jun 11, 2026
- First observedcheck_shortable_shares
- First observedget_account_summary
- First observedget_accounts
- First observedget_connection_status
- First observedget_margin_requirements
- First observedget_portfolio
- First observedshort_selling_analysis
- First observedswitch_account

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: check_shortable_shares vs short_selling_analysis are differentiated by scope (single check vs comprehensive analysis); get_accounts vs get_account_summary vs get_portfolio cover different account aspects; get_connection_status and switch_account are unique. No significant overlap.

Naming Consistency4/5

Tools follow a consistent snake_case naming pattern with verb_noun structure (e.g., get_account_summary, get_portfolio). One exception is short_selling_analysis which is noun_verb but still readable and fits the pattern.

Tool Count5/5

8 tools is appropriate for the domain of financial account information and short selling analysis. Not excessive, and each tool contributes a distinct function without unnecessary duplication.

Completeness3/5

The server covers account information, portfolio, margin, and short selling analysis, but lacks essential trading operations like order placement, modification, or market data retrieval. The surface is focused on analysis and account management, leaving a notable gap for execution.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
openmm-mcp A
io.github.QBT-Labs
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
Finance
1513
Helvetic Research AOAuth
io.github.KushPatil22
Research-only MCP server: turn your AI into a quant research desk — backtests, no trades.
Finance Research & Data
1
DataDoe MCPOAuth
com.datadoe
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
E-commerce & Retail CRM
212

Related MCP Servers

ib-async-mcp
Finance Cryptocurrency
atomcp-ai
A
license
B
quality
C
maintenance
MCP server for Interactive Brokers API, enabling account management, trading, market data, options, scanners, and news via natural language.
Updated 8 months ago (2025-12-25 21:20 UTC)
33
3
MIT
IBKR-MCP-Server
Finance Research & Data
xiao81
A
license
Not graded
quality
D
maintenance
MCP server for Interactive Brokers TWS API that enables AI assistants to retrieve portfolio, account information, and real-time market prices.
Updated a year ago (2025-06-13 13:55 UTC)
23
Apache 2.0
IBKR MCP Server
Finance
GaoChX
A
license
Not graded
quality
D
maintenance
An MCP server for Interactive Brokers, enabling account management, trading operations, and market data queries.
Updated 8 months ago (2025-12-25 06:52 UTC)
8
MIT
ibkr-mcp-server
Finance Research & Data
dapdevsoftware
A
license
Not graded
quality
D
maintenance
MCP server for Interactive Brokers that exposes portfolio data, market quotes, trading, and analysis to any MCP-compatible AI client, with support for EU investors and safety-gated trading.
Updated 6 months ago (2026-02-26 12:22 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ArjunDivecha/ibkr-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server