Build a Local IBKR + AI Chart App: The MCP and Connector Pattern

The Three Local Pieces

The pattern has three parts, all on the user's machine. First, a host app that renders the chart — MyLinedChart uses a native shell around a web view, but the principle is a local UI, not a hosted page. Second, a connector: a local process (for example bound to 127.0.0.1) that bridges the app to the user's own IBKR session via TWS, Gateway, or an API layer. Third, an MCP server that exposes the chart to AI agents.

The reason all three are local is the same rule that started this: market data flows IBKR to the user's machine, never through your servers, so nothing here is redistribution.

• Host app: a local chart UI (native shell + web view works well).
• Connector: a local bridge (e.g. 127.0.0.1) to the user's IBKR session.
• MCP server: exposes the chart to AI agents.

Why the Connector Is Local

The connector is what makes the whole thing compliant. It runs on the user's machine and speaks to the IBKR session that user is already authenticated to, under their own market-data subscriptions. There is one connector per user session — no central server pooling data across accounts.

That means your install flow asks for the user's own IBKR login and connects to their own data. There is no central feed to point at, by design; that absence is the compliance feature, not a gap.

• One connector per user's own IBKR session.
• No central, multi-tenant data feed.
• The user's own login and subscriptions do the work.

The MCP Write Channel — the Differentiator

Since you cannot build a cloud data business here, the differentiation is what the local app lets an AI do. Expose the chart through MCP: read tools (chart context, candles, drawings, indicators, a screenshot) plus a write tool that proposes changes — drawings, indicator configuration, and view changes — every one confirmation-gated and tagged separately from the user's own work.

The hard line to hold: the write channel is chart-only. There is no trade or order field anywhere in it. Account and order access stays read-only; the AI operates the chart, never the money. That safety model is what makes an agent-native trading tool defensible. See /mcp and Let Your AI Operate Your Chart, Safely — What Changed and What Didn't.

• Read tools + one confirmation-gated write tool.
• Write scope: drawings, indicators, view — never orders.
• Account and orders read-only; AI changes tagged and reversible.

Where This Leaves You

The payoff of the pattern: you ship a real, compliant, agent-native tool with zero licensing spend, and your moat is the local + AI layer rather than a data feed anyone with capital could license. It is a genuinely different shape of product from a hosted charting site.

For the compliance reasoning behind every choice here, start with How to Legally Display IBKR Market Data Without Becoming a Data Vendor and Why Your IBKR Trading App Should Be Local, Not Cloud. If you would rather adopt this than build it, /mcp and workflow consulting are the shortcuts.

Why bind the connector to 127.0.0.1?

So it is reachable only from the user's own machine — the app and local AI clients talk to it, but it is not exposed as a network service. It bridges to the user's own IBKR session locally.

Does the MCP write channel let AI place trades?

No. The write channel is chart-only — drawings, indicators, and view changes, all confirmation-gated. There is no trade or order field; account and orders stay read-only.

Do I have to use a native shell?

No — the principle is a local host, not a specific stack. MyLinedChart uses a native shell around a web view, but any local host that keeps data off your servers satisfies the compliance requirement.