tradingview-mcp: connecting Claude Code to TradingView Desktop over CDP

The gap tradingview-mcp fills between an LLM and a live chart

TradingView has no public API for scripted chart control, and the README is explicit that this tool does not connect to TradingView's servers or APIs. What it does instead is talk to the Electron app already running on your machine. The README frames the project as an interface layer that makes a trading application legible to an LLM agent, aimed at researchers and developers studying human-AI collaboration in financial workflows rather than at traders looking for execution.

The intended user is someone who runs Claude Code with MCP support and wants the assistant to read indicator values, change symbols and timeframes, compile Pine Script, or draw on the chart. The README lists the concrete surface: Pine Script development, chart navigation, visual analysis, drawing, alert management, replay practice, screenshots, multi-pane layouts, JSONL streaming, and a CLI. It also states the tool does not execute real trades, so anyone hoping to automate entries is looking at the wrong project.

How the CDP bridge works and what it reads

The transport is Chrome DevTools Protocol, the debugging interface built into Chromium and Electron applications. The README notes the debug port is disabled by default and must be enabled deliberately with the Chromium flag --remote-debugging-port=9222. Nothing happens until you take that step, which is the project's main safety argument: the bridge cannot reach a TradingView instance that was not started in debug mode.

On top of CDP sits an MCP server. The package exposes src/server.js as the MCP entry point and a second export at ./core, with dependencies limited to @modelcontextprotocol/sdk and chrome-remote-interface. Every MCP tool also exists as a tv CLI command with JSON output, so the same code path serves both an assistant and a shell pipeline. The README warns that the tool accesses undocumented internal TradingView APIs through the Electron debug interface, and that these can change or break in any TradingView update. That is the central architectural caveat, not a footnote: the bridge is coupled to the app's internal structure, and the README says it will not work if TradingView changes that structure.

Installing the TradingView MCP server and reaching a first health check

Prerequisites come straight from the README: TradingView Desktop with a paid subscription for real-time data, Node.js 18 or later, and Claude Code with MCP support or any terminal for the CLI. Clone and install first.

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

TradingView Desktop then has to run with CDP enabled on port 9222. The repository ships launch scripts per platform, or you can pass the flag directly.

./scripts/launch_tv_debug_mac.sh

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

Next, register the server in your Claude Code MCP config, either the user-level ~/.claude/.mcp.json or a project .mcp.json. Replace the path with your actual checkout location.

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

The README's verification step is to ask Claude to run tv_health_check. The CLI equivalent is tv status, which reports the connection state. If the debug port is not listening, that is the first thing to check, because the bridge has no other route into the app.

tv status
tv quote
tv symbol AAPL

After a successful status, tv quote returns the current price and tv symbol switches the chart. For piping, the README shows tv stream quote | jq '.close' as a way to watch price changes from a shell.

Where the bridge breaks: undocumented APIs and no unattended mode

The README's caution block is the honest limitation. Because the tool reads undocumented internal TradingView APIs, any TradingView Desktop update can change or remove them. The project's own advice is to pin the TradingView Desktop version when stability matters. That makes this a poor fit for anyone who lets the desktop app auto-update and expects the assistant to keep working.

The second boundary is scope. The README states the tool does not execute real trades, does not work without a valid subscription and an installed Desktop app, does not bypass any paywall, and does not connect to TradingView's servers. So it cannot be repurposed as a headless data feed for a server process, and it cannot run on a machine without a licensed desktop app. There is also no release history in the repository metadata to point at, and the README does not document a rollback path if an update breaks the bridge, which leaves version pinning as the practical mitigation rather than a supported downgrade procedure.

tradingview-mcp versus calling an API directly

The obvious alternative is a data API. A market data provider hands you HTTP endpoints or a websocket, returns structured responses, and does not care whether a desktop application is open. The difference in approach is fundamental: an API gives you server-side data you can store, backtest against, and query from any process, while tradingview-mcp gives you control of a specific running GUI. It can change what is displayed, read indicator tables off the chart, compile Pine Script, and take screenshots, none of which an API does.

The trade-off runs the other way too. An API has documented contracts and versioning; this bridge reads internal state that the README admits can change without notice. If your goal is historical data or order routing, an API or a broker integration is the right tool and this project is not. If your goal is to let an assistant operate the chart you are already looking at, the API has nothing to offer, because the chart is not the API.

Maintenance cost, licence status and what the repository shows

The last push to the default branch was on 2026-07-28, roughly two months before this writing, and the repository is not archived. There are no releases in the metadata, so installation is from the main branch and there is no tagged version to pin against. Upgrades therefore mean pulling new commits, and the package.json shows version 1.0.0 with a dependency range of ^1.12.1 for @modelcontextprotocol/sdk and ^0.33.2 for chrome-remote-interface, so those two libraries can move within their major versions on a fresh npm install.

The licence field reports NOASSERTION, which means the repository metadata does not resolve to a standard SPDX identifier. The LICENSE file exists at the top level, but the machine-readable field does not tell you which terms apply. Read that file before redistributing or bundling the code; nothing in the README substitutes for it, and this is a question for your own legal review rather than something the project documents.

On the operational side, the cost of ownership is mostly version discipline. Pin TradingView Desktop, keep Node.js at 18 or above, and expect that a TradingView update is the event most likely to force a code change. The test scripts in package.json include an e2e suite and unit suites for sanitization, replay, launch and chart history, which gives a contributor a way to check a fix, though the README does not describe a release process.

What the tv CLI adds beyond the MCP tools

The CLI is not a separate product. The README states every MCP tool is also a tv command, and package.json maps the tv binary to src/cli/index.js. That matters for two reasons. First, you can debug the bridge without an LLM in the loop: run tv status or tv quote in a terminal and see raw JSON. Second, it makes the bridge scriptable, since the output is designed for piping with jq.

The command families listed in the README cover connection and state (status, launch, state, symbol, timeframe, type, info, search), market reads (quote, ohlcv, values), chart data (lines, labels, tables, boxes, strategy, trades, equity, depth, indicator), Pine Script (get, set, compile, analyze, check, save, new, open, list, errors, console), drawing, alerts, watchlists, indicators, panes and streaming. The README also shows a one-line install path, npm link, if you want tv on your PATH globally. For anyone evaluating whether the bridge actually reaches the chart before adding it to Claude Code, the CLI is the faster check.

Editorial conclusion

Adopt tradingview-mcp if you already pay for TradingView Desktop, work on Pine Script often, and accept that a TradingView update can break the bridge without warning. Skip it if you need unattended automation, server-side data access, or order execution, since the README states it performs chart interaction only. Before wiring it into a daily workflow, run the health check, confirm the debug port is listening on 9222, and pin your TradingView Desktop version so an update does not silently change the internal APIs the bridge reads.

Frequently asked questions

Official sources

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