Can I connect TradingView to Claude via MCP?

Yes. The standard architecture is a four-layer stack: a TradingView webhook fires structured JSON alerts, an HTTP MCP server receives them and exposes execution tools to Claude, scoped exchange API keys (withdrawals disabled) provide the trading credentials, and a policy layer enforces hard size and throughput caps before any order reaches the exchange. The full stack runs on a small VPS.

Do I need the TradingView Pro tier for webhooks?

Yes, TradingView alert webhooks are gated behind the Pro+ tier (Pro, Premium, or Trial). Free and Pro-tier accounts can fire alerts but not webhooks. Pro+ has been the standard requirement for automated TradingView strategies since 2019 and has not changed.

Should the MCP server handle the trade decision or just expose tools?

Just expose tools. The cleanest architecture is for the MCP server to be a thin layer that receives webhooks and exposes tools (get_market_context, get_recent_alerts, place_order). The decision logic lives in Claude's reasoning. The reason: putting decision logic in the MCP server reintroduces the "code is the strategy" problem that an agentic stack is supposed to solve. Keep the server dumb; keep the model smart; enforce safety in the policy layer.

How do I prevent the agent from making catastrophic trades?

Hardcoded caps in the MCP server's policy layer. Three rules at minimum: per-trade size cap (rejects orders above a USD amount), per-symbol position cap (rejects if the resulting position would exceed a notional), per-minute throughput cap (catches runaway agents). The caps must be in code, not in the prompt: models obey prompt rules 99% of the time and the 1% is what bankrupts you.

Can I run this without a VPS?

Technically yes: a Cloudflare Worker or AWS Lambda can host the MCP server endpoint, and Claude can call it from anywhere. The downside is that the audit log and persistent state need separate storage (S3, DynamoDB, or similar). For prototyping, a $5 VPS is simpler. For production with serious capital, the serverless setup is more robust because there is no single host to crash.

What if Claude makes a tool call that the exchange does not support?

The exchange adapter should return a structured error to Claude, and Claude should reason about it. Common cases: symbol not listed, position size below minimum, exchange in maintenance. The policy layer should fail closed (default to rejection) when the exchange returns an unrecognised error code, so silent failures do not let bad trades through. Logging the error to the audit trail lets you improve the prompt next time the same case arises.

How to Connect TradingView to Claude via MCP (2026)

The architecture, in one diagram

The full stack has five layers. Skipping any of them produces a brittle system.

Layer	Component	Responsibility
1	TradingView alert	Fire JSON webhook on a Pine condition
2	MCP server (HTTP)	Receive webhook, expose tools to Claude
3	Claude (or another MCP client)	Read alert + context, decide
4	Exchange / wallet adapter	Execute the decision via scoped credentials
5	Audit log	Record decision, reasoning, outcome

Step 1: The TradingView webhook

In TradingView, every alert can fire a webhook with a JSON body. The Pine Script alert message field becomes the body verbatim, so the cleanest pattern is to emit structured JSON from Pine.

Pine alert template (Pro+ tier needed for webhook):

{"symbol":"{{ticker}}","price":{{close}},"side":"{{strategy.order.action}}","ts":"{{time}}","reason":"breakout_confirmed"}

Set the webhook URL to your MCP server's /alert endpoint. TradingView fires synchronously; expect 1–5 second latency between condition trigger and webhook receipt.

Step 2: The MCP server

The MCP server has two surfaces. An HTTP endpoint to receive TradingView webhooks, and an MCP tool surface for Claude to call when deciding.

Minimal Python skeleton (FastAPI + mcp-server):

from fastapi import FastAPI; from mcp.server.fastmcp import FastMCP; app = FastAPI(); mcp = FastMCP("trading"); alerts = []

Register three tools on the MCP server: get_recent_alerts(symbol, n) returns the last N TradingView alerts for a symbol; get_market_context(symbol) fetches current price, funding, and recent on-chain flows; place_order(symbol, side, size_usd, max_slippage_bps) executes via the exchange adapter with hardcoded caps. Claude calls these tools after the webhook wakes it.

Step 3: Scoped exchange API keys

The structural rule: the agent must never have withdrawal permission. On Binance, Bybit, Kraken, and Hyperliquid, create an API key with trade-only scope. Withdrawals disabled at the exchange level; IP-allowlist the MCP server's static IP.

Store the key in a secrets manager: never in a config file checked into git, never in the prompt. The MCP server reads the key at startup; Claude never sees credentials.

Step 4: The policy layer

Between Claude's decision and the exchange call, insert a policy layer that enforces hard limits regardless of what the model says. Three rules minimum:

Per-trade size cap. Reject orders above a hardcoded USD amount.
Per-symbol position cap. Reject if the resulting position would exceed a hardcoded notional.
Per-minute throughput cap. Reject if more than N orders have been placed in the trailing 60 seconds (catches a runaway agent).

The policy layer lives in the MCP server, not in the Claude prompt. Models obey prompt rules 99% of the time. The 1% is what bankrupts you.

Step 5: The audit log

Log every webhook, every Claude tool call, every exchange response, and every policy rejection. Structured JSON in append-only storage. The audit log is what lets you debug a bad trade, prove a regulatory inquiry, and improve the agent's prompts over time.

At minimum: alert payload, the reasoning Claude returned, the tool call sequence, the policy decision, the exchange response, and the realised PnL when the position closes. Without this, you cannot tell whether the agent is good or lucky.

A worked example

End-to-end flow for a single signal:

Pine condition fires: 20-period breakout confirmed on BTC/USDT 1h.
TradingView posts {"symbol":"BTCUSDT","price":67250,"side":"buy","ts":"...","reason":"breakout_confirmed"} to the MCP server's /alert endpoint.
The MCP server appends the alert and triggers Claude via the MCP client (or Claude polls a queue).
Claude calls get_market_context("BTCUSDT") and reads funding rate, current spread, recent news. Claude calls get_recent_alerts("BTCUSDT", 5) for context on the recent signal density.
Claude decides: act, with a reasoning trace. It calls place_order("BTCUSDT", "buy", 1000, 10).
The policy layer checks: size $1000 is under cap, position would be $1000 (under cap), throughput is 1/min (under cap). Passes.
The exchange adapter places the order, returns the fill price and order ID.
The audit log records the full chain.

Production checklist

API keys with withdrawals disabled and IP-allowlisted: verified at deploy and monthly.
Policy caps hardcoded in the MCP server, not just in the prompt.
Audit log writes to append-only storage (S3 with object lock, or equivalent).
Healthcheck endpoint on the MCP server, with TradingView's alert system pointed at a backup URL on failover.
Manual kill switch: a single endpoint that disables place_order instantly.
Per-strategy isolation: separate MCP server processes per strategy, with separate API keys, so one runaway agent cannot affect others.

Where this architecture breaks

Three known failure modes worth designing for:

TradingView outage. Webhooks do not fire. The agent has no signal. Either accept the dependency or run a parallel signal source.
Claude rate-limit or downtime. Tool calls fail mid-decision. Build idempotent retries and a fallback to a cheaper model.
Exchange API change. Order placement returns a new error code. The policy layer should fail closed (reject the trade) rather than fail open.

None of these break the architecture conceptually: they just require ops discipline. The TradingView → Claude → exchange pipeline is robust once each layer assumes the others can fail.