Claude Code + TradingView MCP: What's Missing Before Auto-Trading

You've seen the clips: Claude Code opens a TradingView chart, pastes in a Pine Script that compiles first try, and helpfully adds an alert for you — all off a single prompt. It looks like there's one last step missing — actually send the order once it triggers.What nobody tells you first: that last step isn't the next MCP tool waiting to be written. TradingView MCP has no slot for it at that layer at all.

This piece isn't a review of which MCP server you should use — there are at least three named tradingview-mcp projects on GitHub, we haven't benchmarked them, and this piece won't either. It also isn't about which AI model writes better Pine. It does exactly one thing: cleanly separate "what Claude Code can touch inside TradingView through MCP" from "what's actually still missing before real fully-automated order execution," and point out that this cutline is drawn by the MCP protocol itself.

Three Things TradingView MCP Currently Does For Claude Code

Categorize first. The three most active tradingview-mcp projects are actually positioned very differently, and lumping them together misreads what the MCP layer itself is capable of. This table is here for comparison — don't bother memorizing it. The point is that the three repos are taking three different routes.

Each repo's README explicitly says it doesn't handle order execution. tradesdontlie has a section titled "What This Tool Does Not Do" that lists, word for word, "Execute real trades (chart interaction only)". atilaahmettaner's README says "It does not execute trades, manage money, or guarantee any result." lev-corrupted has no order-placement tools and its README makes no such promise either.

Gap One: There's No Slot For "Order Placement" In The MCP Layer By Design

"Let Claude place orders directly" isn't stuck because someone hasn't written the tool yet — it's stuck because the MCP layer doesn't have a slot for it. The Model Context Protocol official spec defines the concept of a tool like this, word for word:

One sentence: MCP lets the model invoke tools directly. But the same spec page has this next:

Put together, those two sentences are decisive: any tool that produces real-world consequences — placing an order, moving funds, actually moving money — should require human confirmationper MCP's own guidance. tradesdontlie choosing not to expose an order-placement tool is the most conservative reading of that SHOULD: since there's no way to guarantee every call goes through a human approval step, they don't offer the tool at all.

Here's what that means for how you use Claude Code: if you want fully-automated order placement, what you need to add isn't "an order-placement MCP" — it'sa separate execution layer sitting alongside the MCP layer, one whose trigger signal comes from a TradingView alert, not from Claude's next tool call. That's the skeleton every section from here on keeps coming back to.

Gap Two: It Writes Pine Script, But Doesn't Care How Your Execution Layer Consumes It

It's true that Claude Code can now write Pine Script — tradesdontlie'spine_smart_compile tool chain (pine_set_source →pine_smart_compile → pine_get_errors →pine_get_console → pine_save) exists for exactly this. lev-corrupted's set even ships v3 → v6 version conversion and a sandbox.

But compiling inside TradingView and what your execution layer sees once it's live are two different things. When the alert triggers, the payload TradingView sends, the position size, the qty_type — all of it is determined by what you declared in Pine and the alert-message template you set. If the Pine your MCP wrote, or the alert message it built, doesn't include the fields your execution layer needs, the execution layer either 500s or breaks quietly.

We've covered these breakpoints in more depth elsewhere. AI-generated Pine has several independent gates between compile and live order —this piecewalks through them in order; position sizing is computed on TradingView's side, not by your exchange account, andthis piecebreaks that trap open across the entire article; duplicate orders from alerts having no cross-run memory sit inthis piece. None of those three gaps are handled by MCP.

So what should you do? When you have Claude Code write Pine, paste your execution layer's expected JSON schema into the prompt too, and force it to write the alert message as literal, valid JSON — no MCP will do this for you. All MCP does is make it faster to see whether the code you got compiles cleanly in TradingView.

Gap Three: It Can Create Alerts, But What Happens After They Fire Is Another Layer

tradesdontlie has alert_create, alert_list, alert_delete— Claude can read the current alert list, add, and delete them. For "running many strategies in parallel and tuning them all at once" that's a real capability. But once the alert exists: whether the webhook URL is reachable, whether the payload passes the exchange API's validation, whether the signal is duplicated, whether there's a fallback path if the exchange goes down — all of those things happen after the alert fires.

The MCP layer sees none of it. Unless you loop trigger feedback back into Claude as another round of context — but at that point you're building your own orchestration; MCP isn't the one giving you that. Thefive-layer debugging flowchartin another piece walks all of these gates end-to-end; MCP creating the alert for you only gets you as far as gate 0.

Gap Four: Nobody Owns Cross-System State Consistency

A concrete scenario: you ask Claude, through tradesdontlie's MCP, to disable all alerts on a particular strategy. It does; the alerts vanish from the chart. Meanwhile — is your execution layer still receiving signals from somewhere else (say, another account's API)? Nobody guarantees the two sides stay in sync. tradesdontlie only touches the TradingView Desktop UI on this machine, not the server-side alert queue on your account, and it has no idea whether you've fanned the same signal out to other places.

This is why "let Claude Code automate your whole trading operation" can only live in a single-machine, single-account, human-supervised setup right now — not because the capability isn't there, but because MCP doesn't own cross-system consistency. To make it own that, you need a coordination layer in the middle (your own backend, broker-side logic, or a handshake with another MCP server), and that's no longer a "plug in an MCP in the afternoon" kind of job.

So What Did MCP Actually Solve?

This is the part I think gets misread the most. MCP didn't solve "auto-trading" — it never was trying to. What it solves is: "once you hand your idea over to the AI, the steps the AI needs to take inside the specific window and data context that is TradingView."

All three used to mean you opened TradingView yourself, copied and pasted, switched tabs, took notes. MCP lets the AI do those steps directly in the window you already have open. That's a real, solid time saving. But all of it is assistive production, not execution on your behalf.

To Reach Full Auto-Trading, Here's What You Add Beyond MCP

Given the division of labor above, once the MCP layer's job of "AI touches the chart" is handled, the remaining responsibilities aren't many, but none of them are optional. This list isn't meant to be copied — it's meant to be a list where you can spot which item is missing and add it back.

• A separate webhook receiver (roll your own or hosted), triggered by TradingView alerts, not by Claude's next tool call
• The receiver needs: payload signature verification, deduplication (take the first signal on any given candle), risk gates (position caps, daily max-loss kill switch), a dry-run flag
• Exchange API keys with least privilege: no withdrawal, IP allowlist, 2FA on
• A "this minute the system is healthy" heartbeat — otherwise it breaks quietly and nobody notices

None of that is MCP's job, and none of it is Claude Code's job either.These belong to the execution layer. The API-key-permissions piece is more complete inthis piece; getting a webhook from zero to actually receiving a signal is in thecomplete tutorial.

For example, TVSBot's execution layer was designed around exactly this cutline — your own API key, dry-run before real orders, risk gates applied at the account level. Once Claude Code has written the Pine and built the alert, the signal is handed off to the execution layer. This split isn't here to fragment functionality — it's here so that between "AI touches the chart" and "money moves" there's a gate a human can actually inspect.

Being Honest: This Is A Route Choice, Not A Capability Gap

Everything above about "MCP can't auto-trade" isn'ttechnically impossible — someone could write an order-placement MCP tool, and there are already MCP servers wrapping broker APIs (just not TradingView-related ones). So the more precise version is: the maintainers of every active tradingview-mcp project have chosen not to, and the MCP official spec also advises human confirmation for any tool with real-world consequences. This is a route choice, not a capability gap.

If someone eventually ships a "Claude Code places orders directly" MCP, three questions still apply. Does it deduplicate? Can it dry-run? When it breaks, does it fail loudly or does it silently keep sending orders? The answers to those have nothing to do with whether the tool is an MCP — they apply to any automated trading architecture.

Frequently Asked Questions