TradingView MCP Jackson: 81 AI Tools for Chart Analysis in 2026

Last updated: April 2026

TradingView is the most widely used charting platform in retail trading — over 90 million registered users as of 2025, according to TradingView’s own metrics. But it has never offered a public API for programmatic chart interaction. You can’t pull live indicator values, automate Pine Script workflows, or export structured data from your chart environment through any official endpoint.

That limitation is exactly what TradingView MCP Jackson — and the original tradingview-mcp project it forks — set out to solve. Not by reverse engineering TradingView’s servers, but by exploiting a standard debugging interface that’s been sitting inside every Electron-based desktop app since day one: Chrome DevTools Protocol (CDP).

If you’re already familiar with the Model Context Protocol (MCP) — Anthropic’s open standard for connecting AI models to external tools — you understand the architectural pattern. If not, the short version: MCP lets an AI model like Claude call structured tools (functions with typed inputs and outputs) exposed by a local or remote server. TradingView MCP Jackson is one such server. It exposes 81 tools that read, control, and automate your local TradingView Desktop charts.

How does TradingView MCP work under the hood?

The architecture is a three-hop chain: Claude Code communicates with the MCP server over stdio, the MCP server communicates with TradingView Desktop via Chrome DevTools Protocol on localhost:9222, and TradingView Desktop is just an Electron app running Chromium under the hood.

The key insight: TradingView Desktop is an Electron app. Electron is Chromium. Chromium ships with Chrome DevTools Protocol — the same debugging interface used by VS Code, Slack, and Discord. When you launch TradingView with the flag --remote-debugging-port=9222, you expose a local WebSocket endpoint that can read DOM state, execute JavaScript, intercept network requests, and interact with the application programmatically.

This is not a hack or a reverse-engineering effort. CDP is a Google-documented standard built into every Chromium application. The MCP server simply speaks this protocol to query your chart state, read indicator values, and inject Pine Script code — all on your local machine, with zero data leaving your network.

What does the Jackson fork add to the original?

The original tradingview-mcp by @tradesdontlie (1,000+ GitHub stars, 435+ forks as of April 2026) established the 78-tool foundation: chart reading, Pine Script development, drawing tools, replay mode, alerts, multi-pane layouts, and screenshot capture. It’s a comprehensive toolkit for anyone who wants AI-assisted chart interaction.

Lewis W. Jackson’s fork — tradingview-mcp-jackson — adds three tools and one critical fix that shift the project from “toolkit” to “daily workflow system”:

The morning_brief tool is the differentiator. Instead of manually opening each chart, checking each indicator, and making a mental note of session bias, you run one command — tv brief in your terminal or tell Claude to run morning_brief — and get structured output for every symbol on your watchlist. This is the difference between a set of tools and a repeatable process.

What are the 81 MCP tools?

The full tool set divides into nine functional categories. Here’s what each group does and when you’d reach for it:

Chart reading (4 tools)

These are your entry point for any analysis. chart_get_state returns the current symbol, timeframe, and all loaded indicator names with their internal IDs. data_get_study_values reads the actual numeric output of every indicator on the chart — RSI values, MACD crossovers, Bollinger Band widths. quote_get pulls the latest price, OHLC, and volume. data_get_ohlcv returns raw price bars, with a summary: true option that compresses 100 bars into compact statistics.

Custom indicator data (4 tools)

This is where the tool becomes genuinely powerful for systematic traders. If you use Pine Script indicators that draw lines, labels, tables, or boxes (line.new(), label.new(), table.new(), box.new()), these four tools extract that rendered data as structured JSON. You can read support/resistance levels drawn by a custom indicator, session bias labels, analytics tables, or zone boxes — all programmatically. If you’ve built a personal AI agent that needs to read structured chart data, this is how you feed it.

Chart control (6 tools)

Symbol switching, timeframe changes, chart type toggles (candles, Heikin-Ashi, Renko), indicator management, date scrolling, and indicator input adjustment. These let Claude (or any MCP client) navigate your chart environment the same way you would manually.

Pine Script development (6 tools)

This is the workflow that most traders underestimate. The cycle is: inject code → compile → read errors → fix → recompile. With these tools, Claude can write a Pine Script indicator from a natural language description, inject it into the editor, compile it, read compilation errors, fix the code, and iterate — all without you touching the Pine Editor. pine_analyze and pine_check even work offline for static analysis and server-side compile checks.

The practical application: describe a trading concept to Claude — say, a Fair Value Gap detector with session filtering — and let it write, test, and debug the indicator. This is a concrete example of context engineering in action: the model has access to the live chart state, the compilation feedback loop, and your trading rules, which gives it enough context to produce working code reliably.

Replay mode (6 tools)

TradingView’s replay mode lets you step through historical bars one at a time. These tools automate that process: enter replay at any date, step forward, run autoplay at a configurable speed, place simulated trades with buy/sell/close actions, check position status and P&L, and return to real-time. This turns replay from a visual exercise into a data-generating practice engine.

Morning brief (3 tools — Jackson fork)

As described above: morning_brief scans your watchlist against your rules, session_save persists the output, session_get retrieves previous sessions for comparison.

Multi-pane, alerts, drawings, UI (8+ tools)

Layout management (2×2 grids, 3×1 splits, up to 8 panes), price alert creation and deletion, shape drawing (horizontal lines, trend lines, rectangles, text), watchlist management, screenshot capture, and batch operations across multiple symbols or timeframes.

CLI access

Every MCP tool is also exposed as a tv CLI command with pipe-friendly JSON output. This means you can chain tools in shell scripts, pipe chart data into Python or Node.js processing pipelines, or build cron-based monitoring without touching Claude Code at all.

How do you set it up?

The prerequisites are straightforward: TradingView Desktop (a paid subscription is required for real-time data), Node.js 18+, and Claude Code (or any MCP-compatible client). The setup runs on macOS, Windows, and Linux.

The repository includes a one-shot setup prompt you can paste directly into Claude Code — it will clone the repo, install dependencies, configure MCP, and copy the rules template. For manual setup:

# 1. Clone and install
git clone https://github.com/LewisWJackson/tradingview-mcp-jackson.git ~/tradingview-mcp-jackson
cd ~/tradingview-mcp-jackson
npm install

# 2. Set up your trading rules
cp rules.example.json rules.json
# Edit rules.json: add your watchlist, bias criteria, risk rules

# 3. Launch TradingView with CDP enabled
./scripts/launch_tv_debug_mac.sh     # macOS
# scripts\launch_tv_debug.bat        # Windows
# ./scripts/launch_tv_debug_linux.sh # Linux

# 4. Verify connection
# In Claude Code: "Use tv_health_check to verify TradingView is connected"

# 5. Run your first morning brief
# In Claude Code: "Run morning_brief and give me my session bias"
# Or from terminal:
npm link    # install tv CLI globally (one time)
tv brief

The MCP configuration goes into ~/.claude/.mcp.json:

{
  "mcpServers": {
    "tradingview": {
      "command": "node",
      "args": ["/Users/YOUR_USERNAME/tradingview-mcp-jackson/src/server.js"]
    }
  }
}

How does the morning brief workflow actually function?

The morning brief is designed as a pre-session routine. Before you trade, you want to know the bias for each instrument on your watchlist. Traditional approach: open each chart, cycle through timeframes, check indicators, make mental notes. With TradingView MCP Jackson, the sequence is automated:

Step 1: You define your rules once in rules.json — which symbols to scan, what constitutes bullish/bearish/neutral for your trading style, and which risk rules Claude should check before each session.

Step 2: Run tv brief (or ask Claude). The system iterates through your watchlist, switches to each symbol, reads all indicator values, and applies your rules to generate a bias assessment.

Step 3: Save the brief with session_save. It persists to ~/.tradingview-mcp/sessions/YYYY-MM-DD.json.

Step 4: Next morning, compare with session_get. Did your bias change? Did the levels you were watching get hit? This creates a structured feedback loop — the foundation of deliberate practice in trading.

For someone trading with Smart Money Concepts — Fair Value Gaps, liquidity sweeps, breaks of structure — this workflow is directly applicable. You configure rules.json to check for the conditions you care about, and the morning brief tells you where to focus your attention. If you’re unfamiliar with how CFDs or spreads interact with these strategies, we’ve covered the mechanics in our articles on CFD contracts and spread costs (in Polish).

How does this compare to other TradingView MCP servers?

The TradingView MCP ecosystem has fragmented into two architecturally distinct approaches in early 2026:

The CDP approach is more powerful for individual traders who use TradingView as their primary charting tool and want AI-assisted analysis of their actual charts with their actual indicators. The API-based approach is better for screening, backtesting, and data analysis workflows that don’t depend on a specific chart configuration.

If you’re building a broader AI-powered risk management stack, you might combine both approaches: use the CDP server for real-time chart analysis and Pine Script development, and an API-based server for historical backtesting and multi-asset screening.

What are the risks and limitations?

This is where intellectual honesty matters. TradingView MCP Jackson is a powerful tool, but it operates in a gray area with real constraints:

Terms of Service risk. TradingView’s Terms of Use restrict automated data collection and scraping. While the CDP approach reads your local app rather than TradingView’s servers, and the project explicitly forbids data redistribution, the automated interaction with the application interface could be interpreted as violating TradingView’s terms. The project’s disclaimer makes this risk clear — account bans or suspensions are a possibility.

Fragility. The tool accesses undocumented internal APIs. TradingView Desktop updates can break functionality without warning. The v2.14+ launch bug fix in the Jackson fork is a direct example — a TradingView update broke the original launch script, and someone had to patch it.

Not a trading system. This is a workflow automation tool, not an algorithmic trading bot. It doesn’t execute trades on any exchange. It reads and controls your charting interface. The morning brief generates bias assessments — it doesn’t tell you what to buy or sell. Any trading decision remains entirely yours.

No data verification. The tool reads indicator values and chart state as TradingView renders them. It doesn’t independently verify that the data is correct or that indicators are calculating properly. Garbage in, garbage out — if your chart configuration is wrong, the AI analysis of that chart will be wrong too.

Who is this tool actually for?

TradingView MCP Jackson is best suited for a specific type of trader: someone who already uses TradingView Desktop as their primary charting tool, has a defined trading process (specific indicators, specific watchlist, specific rules for bias), and wants to reduce the manual friction of pre-session analysis.

If you’re a discretionary trader who trades based on gut feel and doesn’t have a repeatable process, this tool won’t help you — you’ll just be automating randomness. If you’re a quantitative trader who needs institutional-grade data pipelines and execution, you should be using proper market data APIs and execution management systems, not a Chrome DevTools hack.

The sweet spot is the systematic-but-manual trader who has rules they apply every day but spends 30–60 minutes before each session just reading charts and checking indicators. That’s the time this tool compresses to a single command.

For developers interested in how MCP works as a protocol standard — and why the tool-calling pattern matters beyond trading — this project is also an excellent reference implementation. 81 tools in a single MCP server, well-documented, with both stdio and CLI transports.