TradingView MCP attaches to the Electron debug port, not to TradingView's servers

The bridge attaches to Electron, not to TradingView's servers

Everything this project does happens inside a desktop app you have already started. The communication channel is the Chrome DevTools Protocol, the debugging interface Google builds into every Chromium and Electron application, the same one VS Code, Slack and Discord expose. No connection goes to TradingView infrastructure, no TradingView file is modified, and no network traffic is intercepted. That framing matters more than the tool description does, because it explains the blast radius: a mistake here damages a local UI session rather than an account.

Reaching the protocol takes one deliberate step. The debug port is disabled by default and you enable it yourself with a standard Chromium flag, `--remote-debugging-port=9222`. Nothing runs until you launch TradingView that way, by hand or through one of the bundled launch scripts. The project says all data processing happens locally and that no market data is transmitted, stored or redistributed by the tool, so a chart read stays on your machine.

Pinning the Desktop version is the price of an undocumented API

The tool calls itself out on this point, and it is the first thing to accept before adopting it. It accesses undocumented internal TradingView APIs through the Electron debug interface, and those internals can change or break without notice in any TradingView update. The project's own advice is to pin your TradingView Desktop version when stability matters to you.

That constraint has a knock-on effect. The README lists, among the things the tool cannot do, working at all if TradingView changes its internal Electron structure. A pinned Desktop build plus an unversioned npm project with no published releases is a combination that can break on either side of the link, and neither side tells you in advance when it happened.

The disclaimers point the same way. The project states it is not affiliated with, endorsed by, or associated with TradingView Inc., and it requires a valid TradingView subscription while explicitly not bypassing any paywall or access control.

Launching the Desktop app in debug mode is a manual step

Installation ends with the node packages, not with a running bridge. The documented path is three commands, and the third leaves TradingView closed:

git clone https://github.com/tradesdontlie/tradingview-mcp.git
cd tradingview-mcp
npm install

TradingView Desktop then has to be running with the debug port open on 9222. A shell script is shipped per platform, so macOS runs `./scripts/launch_tv_debug_mac.sh`, Linux runs `./scripts/launch_tv_debug_linux.sh`, and Windows runs the batch file `scripts\launch_tv_debug.bat`. Any platform can also be launched by hand with the Chromium flag appended to the binary path:

/path/to/TradingView --remote-debugging-port=9222

An MCP tool named tv_launch covers the same ground from inside an assistant session and auto-detects the install, which removes the need to remember which script belongs to which operating system. The prerequisite list is otherwise thin: Node.js 18 or newer, the Desktop app, a paid subscription for real-time data, and macOS, Windows or Linux.

MCP configuration is one JSON block pointing at src/server.js

The server is a plain node process, so wiring it into Claude Code means adding one entry to an MCP config. The documented location is ~/.claude/.mcp.json for a user-wide setup or a project .mcp.json for a single repository:

{
  "mcpServers": {
    "tradingview": {
      "command": "node",
      "args": ["/path/to/tradingview-mcp/src/server.js"]
    }
  }
}

The path is the only part you have to substitute, and the package exports match that layout: the main entry and the dot export both resolve to ./src/server.js, with a separate ./core export for src/core/index.js. package.json declares the module as ESM and pins two runtime dependencies, the Model Context Protocol SDK at ^1.12.1 and chrome-remote-interface at ^0.33.2, with eslint as the only development dependency.

Verification is a single tool call rather than a log file to read. The instruction is to ask Claude to use tv_health_check to verify TradingView is connected, which returns the state of the bridge before you trust anything it reports.

Every MCP tool also exists as a tv CLI command

The same surface is available without an assistant, which is what makes the project usable from a shell script or a cron job. Each MCP tool has a matching `tv` subcommand, all output is JSON, and the result is pipe-friendly with jq. The CLI is exposed through the package bin field, so a global install is optional:

npm link
node src/cli/index.js <command>

The quick examples cover the common paths:

tv status
tv quote
tv symbol AAPL
tv ohlcv --summary
tv screenshot -r chart
tv pine compile
tv pane layout 2x2
tv pane symbol 1 ES1!
tv stream quote | jq '.close'

The last one is the interesting case. The chart can be streamed as JSONL from the locally running instance for local monitoring scripts, and tv status is the one to run first, since it checks the connection. Screenshot and pane commands take arguments rather than acting on the whole app, so a script can capture one region and address one pane of a grid.

Chart work is reading and drawing, never order placement

The tool list is deliberately narrow about finance and wide about interface. It writes, injects, compiles and debugs Pine Script; changes symbols and timeframes and zooms to dates; reads indicator values, price levels and annotations; draws trend lines, horizontal lines, rectangles and text; creates, lists and deletes price alerts; steps through historical bars in replay mode; captures screenshots; and builds multi-pane grids such as 2x2 or 3x1 with a different symbol per pane. Pine Script has by far the widest surface, with get, set, compile, analyze, check, save, new, open, list, errors and console subcommands.

What it will not do is the part worth reading twice. It does not execute real trades, since the interaction is chart-only, and it does not connect to TradingView servers or APIs, store or redistribute market data, work without a valid subscription and installed Desktop app, or bypass a paywall. Those are listed as explicit non-goals rather than left unmentioned.

The project frames itself as an interface layer for research into how agents handle ambiguous financial UI state, with open questions kept in RESEARCH.md. The tree also carries agents/, skills/, CLAUDE.md, SECURITY.md and SETUP_GUIDE.md, which suggests the audience is developers studying the workflow rather than traders looking for a signal.

No published releases, and metadata reports no licence identifier

Distribution is the quiet weak point. The repository has no GitHub releases at all, so there is no version to pin on the bridge side, while package.json still reads 1.0.0. Upgrading therefore means pulling whatever the default branch contains, which sits uncomfortably next to a tool that depends on a pinned TradingView Desktop build. The last push to the main branch was on 2026-10-21, so the code is current rather than abandoned, but nothing in the repository records which commit you tested.

Licensing is equally unclear from the metadata. A LICENSE file exists in the repository root, yet the repository reports no recognised licence identifier, so the terms in that file are the only place to look. For a tool you run against a paid desktop application, that is worth reading before you redistribute or vendor it.

Testing is documented through package.json rather than prose. The test script runs node --test over e2e and Pine analysis tests, with separate targets for unit, CLI, and end-to-end runs, and an e2e suite that needs the desktop app and its debug port to be up.

Editorial conclusion

This is a personal workflow tool for someone who already pays for TradingView and wants an assistant inside their own desktop session, not a data API and not a trading system. Skip it if you need a supported interface, an official endpoint, or a path that survives the next TradingView release, because the bridge is built on undocumented Electron internals. Before trusting it, launch the Desktop app with the debug port yourself, run tv_health_check, and pin your TradingView version, then check the LICENSE file in the repository root since the repository metadata reports no recognised licence identifier.

Frequently asked questions

Official sources

1. Issues
2. README
3. tradesdontlie/tradingview-mcp on GitHub