TradingView MCP debug port: what it opens, when to close

You install TradingView MCP, run tv_health_check, and AI starts reading your charts, writing Pine, sweeping the morning open — it just works. The step every tutorial glosses over is actually the real gate on this tool: during install, it asks you to quit the TradingView desktop app and relaunch it with --remote-debugging-port=9222. That's the pivotal move the docs never really open up.

Nobody tells you up front: that port is Chrome DevTools Protocol's debug interface — it is not a dedicated channel for MCP. Once it's open on your machine, the things that can connect to it are not limited to the MCP server you just installed.

This piece isn't a review of the TradingView MCP project itself — its own README says what needs saying, and there's no reason for us to rewrite someone else's self-disclosure. We're doing two things only: turning the sentences the author deliberately buried inside Warning and Caution blocks into language you'll actually use to make a decision, and turning "when should the debug port be closed" into a checklist you can act on.

What --remote-debugging-port=9222 Actually Opens

TradingView Desktop is an Electron app — under the hood it's Chromium wrapped in a shell. Every debug mechanism Chromium ships with is inherited, including "Chrome DevTools Protocol" (CDP hereafter). CDP is the protocol Google designed for Chrome DevTools, letting external programs drive the browser through JSON messages: read the DOM, inject JavaScript, take screenshots, listen to network events.

By default, CDP is off. To use it, you have to pass a flag at launch telling Chromium "please listen for CDP connections on this port." The tradesdontlie README puts it plainly:

"Nothing happens without that deliberate step" — that sentence is describing something you have to actively do to turn it on. It also describes the flip side: once you've done it, the port stays open until you quit TradingView and relaunch it the normal way.

So that port isn't an MCP-specific channel. It's Chromium's standard debug interface. VS Code, Slack, Discord — every Electron app has the same mechanism baked in. They just don't enable it by default, and normally you have no reason to either.

Who Else On Your Machine Can Connect To It While It's Open

By default CDP binds to 127.0.0.1:9222, the loopback interface. That means two things.

Good news: attackers on the network can't reach the port — unless you've separately forwarded it out, or you have some other service exposing localhost to the LAN or WAN. That's the technical basis for tradesdontlie repeatedly stressing "All data stays on your machine."

But here's the catch: "local" is not a security boundary. Any process running as your user can connect to 127.0.0.1:9222 — no password, no token, no CORS protection. CDP assumes from the start that "anyone who can reach this port has the right to debug," because its original purpose was for developers to open it themselves and debug their own app.

If your threat model is "I trust everything running on this box," leaving the debug port open is fine. That is genuinely most solo developers' day-to-day reality. But it has to be something you've verified for yourself — the tool cannot guarantee it for you.

What You Can Do Through That Connection Is Much More Than "Help AI Look At Charts"

tradesdontlie's MCP server wraps CDP calls in 78 tools. Those wrappers are useful, but an external observer isn't constrained by them — CDP itself offers more than those 78 tools expose. Any program that connects to localhost:9222 can:

• Execute arbitrary JavaScript: via Runtime.evaluate — this is an official CDP method whose whole point is to evaluate any expression against the page's global object. That means it can read anything on your TradingView page: watchlists, layouts, alerts, the current symbol, the Pine Script you were half-way through editing.
• Take screenshots and recordings: your chart state, open layouts, which symbol you're looking at — quietly extractable.
• Manipulate UI state: switch symbols, switch timeframes, click buttons, close tabs — CDP has Input.dispatchMouseEvent and dispatchKeyEvent, which can simulate user input.
• Modify Pine Script source: MCP's pine_set_source underneath is just pasting a string into the editor. Any program with a CDP connection can do the same.
• Create, modify, and delete alerts: MCP exposes alert_create and alert_delete — again, wrappers on top of CDP.

The fifth point deserves its own beat. Alerts are the entry point for your signals into downstream automation — you build an alert in TradingView, the alert fires, a webhook hits your execution service, and the execution service places the order. If a program that can reach CDP can build alerts for you, it gets a shot at injecting signals into your existing execution flow. The alert it injects doesn't need to have anything to do with your strategy's logic; as long as its payload matches whatever your webhook is parsing on the other end, downstream treats it as a legitimate signal.

"It Doesn't Place Real Trades" — How To Read That Sentence

tradesdontlie's README, under "What This Tool Does Not Do": "Execute real trades (chart interaction only)". That sentence correctly describes the MCP tool itself — its wrappers really don't contain any real trading API wrappers, only replay_trade (simulated orders in replay mode).

But the sentence only speaks to the boundary of what the MCP tool wraps. It doesn't speak to:

What "Undocumented TradingView APIs" Really Means

The README's Caution block: "This tool accesses undocumented internal TradingView APIs via the Electron debug interface. These can change or break without notice in any TradingView update."

Translated into language you'll use to make decisions: TradingView has made no commitment that these interfaces will remain stable. Today pine_smart_compile works and data_get_pine_lines works — that says nothing about next week after the desktop app updates. This isn't new territory for readers of this site — it's the same species of fragility we wrote about in "Pine Script Alerts Have No Memory": you're depending on behavior the platform never wrote down, and it has no obligation to warn you before it changes.

This site's core stance has always been: whether your trading flow can depend on an interface comes down to whether the interface provider gave you a written contract you can hold up. Official APIs, publicly documented webhook specs, behavior spelled out in terms of service — when those break, you can point at the document. But for CDP-wrapper tools like tradesdontlie, there's nothing to point at — TradingView has never written down that it will maintain any of these internal interfaces.

So: research, strategy writing, Pine practice, morning-open scans — MCP is great for all of these, because the cost of a break is just "can't do this today." Before you connect it to anything that moves money, ask once: when this link breaks, whose money is affected? If the answer is "mine," it doesn't belong in the critical path.

When To Close The Port: A Checklist You Can Act On

This isn't a "if you use MCP you must" sermon. It's "should the debug port be open right now" broken into concrete conditions you can check today.

• Close it when you're done. After a session of AI-assisted chart analysis, quit TradingView and relaunch it normally (without --remote-debugging-port). "Leave it always open" costs more than you think, and buys you nothing extra — AI isn't going to open your charts on its own at 3 a.m.
• Don't add the debug-mode TradingView to your login items. If you set the launcher script with --remote-debugging-port=9222 to run at boot, every startup opens an unauthenticated CDP port on your machine.
• Only open it on machines you trust. Don't open it on shared computers, company-issued devices, or machines where you've installed anything of unknown provenance. "Local" is not a security boundary in those settings.
• While the port is open, don't browse untrusted sites in the same browser profile. Browser CORS behavior toward localhost isn't fully consistent — don't assume the browser will block a fetch to localhost:9222 without testing.
• If there's a webhook execution end downstream, pin the alert payload. The webhook end should at minimum verify a secret field inside the alert message (strategy ID, signature, shared key) — don't just trust "a signal came in, so place the trade." That way, even if someone creates an alert through CDP, the execution end rejects it.
• Order-placement permission downstream is configured separately. AI holding a CDP connection is one thing; the execution end holding your exchange API keys is another — the two permission boundaries have to be managed apart. See the API key permissions checklist for non-custodial trading bots; that one covers permissions on the exchange side and complements the AI-side thinking here.
• Don't say "it's just local" before you've done a threat model. "Local" is a network boundary, not a process boundary. That npm package you installed yesterday shares the same "local" as your CDP connection.

The Honest Section: AI Stays On The Generation And Analysis Side, Execution Rights Live Elsewhere

We can't guarantee that "debug port open + an MCP server running" will never lead to an incident — we haven't red-teamed it and this article isn't going to. All this piece can do is lay out what the author has already self-disclosed, so you can see the full picture before deciding.

But standing on this site's consistent position, we can say one thing: "AI generating a strategy" and "the strategy placing orders" are two different problems, and you shouldn't solve both over the same connection. Bridges like MCP make it convenient for AI to talk to your charts. When you get ready to let a strategy actually place real trades, that same connection shouldn't be the pipe. There should be a clean boundary in between: a non-custodial execution service, your own API keys, dry-run first, risk controls hard-coded on your side. That way, if the whole MCP/CDP stack has an incident down the road, the blast radius stops at the alert — everything past the alert is on infrastructure you built and control.

Frequently Asked Questions