TradingView MCP: Import a Pine Strategy Into Trigr

Use the TradingView MCP and Trigr's MCP to port a Pine Script strategy into Trigr, backtest it with costs, iterate in experiments and create a paper agent.

Trigr Research9 min read
On this page
  1. What can the TradingView MCP server actually do?
  2. Why port the logic instead of the data?
  3. How do you connect both MCP servers?
  4. How do you get your Pine Script source?
  5. How do Pine concepts map to Trigr's node graph?
  6. What does the step-by-step session look like?
  7. How do you go from paper to live?
  8. Why use Trigr for this instead of automating Pine alerts?
  9. Next steps

TL;DR: TradingView's official MCP server cannot read Pine Script, so the practical path is to paste your own strategy code into an assistant that also has Trigr's MCP server connected. The assistant maps the Pine logic to Trigr's TRIGGER, FILTER, SIGNAL, RISK and EXECUTE nodes, saves one strategy, backtests it with slippage and funding, iterates in labelled experiments, and creates a paused paper agent. Going live on Hyperliquid happens only in the Trigr app.

What can the TradingView MCP server actually do?

TradingView launched an official MCP server as a public beta on 2026-09-16, at https://mcp.tradingview.com/mcp. According to the TradingView MCP documentation, it uses OAuth with your TradingView account, requires an Essential plan or higher (trial plans are excluded), and is limited to about 100 requests per minute per user. TradingView's announcement also warns that during the beta the tool list is limited and market data is delayed.

Its 35 documented tools cover watchlists, OHLCV and economic data, symbol search, the screener, news, fundamentals and forecasts, documents, calendars and alerts. That makes it useful for looking things up in conversation.

What it does not do matters more for this guide. As of September 2026 it has no Pine Script tools and no Strategy Tester tools. It cannot read your scripts, write them, or return a backtest. It also has no broker balances, positions or order placement. So "import my TradingView strategy" is not a single MCP call; it is a translation job, and that is where an assistant connected to Trigr helps.

Why port the logic instead of the data?

Before any setup, one ground rule. TradingView's Terms of Use limit its market data to display. They name algorithmic decision-making, algorithmic trading and other machine-driven processes that do not involve human-readable display as prohibited uses, and they forbid third-party tools that enable that kind of use.

How that clause applies to TradingView's own MCP server is not spelled out publicly. The workflow below avoids the question entirely:

  • Take the strategy logic from TradingView: your own Pine code, which is your work.
  • Backtest and run it on Trigr's own point-in-time data, not TradingView's.
  • Never pipe TradingView prices, screener output or indicator values into an automated agent or into the backtest.

If you use the TradingView MCP at all in this flow, use it for things you read yourself, such as checking a watchlist to decide which market you want to test.

How do you connect both MCP servers?

You need a Trigr account (MCP works on every plan, including Free) and an assistant that supports remote MCP servers. Each server authorizes separately in your browser. For Trigr, the browser flow creates a revocable credential, so there is no API key to copy.

Claude Code

claude mcp add --transport http --scope user trigr https://trigr.xyz/mcp
claude mcp add --transport http mcp-tradingview https://mcp.tradingview.com/mcp
claude
# Inside Claude Code: /mcp → authenticate each server

The TradingView line is optional; the Trigr line is the one this workflow depends on. The full Trigr walkthrough, including approval modes and troubleshooting, is in connecting Claude Code and Codex to Trigr.

Codex

codex mcp add trigr --url https://trigr.xyz/mcp
codex mcp login trigr
codex mcp add tradingview --url https://mcp.tradingview.com/mcp
codex mcp login tradingview

Backtests can take longer than Codex's default 60-second tool timeout. Raising it in ~/.codex/config.toml avoids spurious failures:

[mcp_servers.trigr]
url = "https://trigr.xyz/mcp"
tool_timeout_sec = 300

Claude and ChatGPT on the web

In Claude, go to Customize → Connectors → "+" → Add custom connector, paste https://trigr.xyz/mcp, then connect and complete the Trigr authorization. Repeat with the TradingView URL if you want it. Claude's Free plan allows only one custom connector, so pick Trigr there.

In ChatGPT, turn on Developer mode in Settings → Security and login, then create a developer-mode app with the Trigr MCP URL and OAuth. Full MCP write actions depend on your ChatGPT plan and workspace, so check OpenAI's current connector availability. The guided setup page has copy-ready steps for each client.

How do you get your Pine Script source?

Which route you have depends on whose script it is.

Source How to get the code Caveats
Your own script Open it in the Pine Editor, select all, copy, and paste into the chat Simplest and cleanest route
Your own script, via automation The community tradesdontlie/tradingview-mcp server's pine_get_source reads the open script from TradingView Desktop Unofficial; drives the desktop app over a debug port and undocumented internals; its README warns about TradingView's ToS
Someone else's open-source script Add it to a chart and choose "Source code" in the script's status line Credit the author; the default license is MPL 2.0
Protected or invite-only script Not available Only the author can see the source

The community server is not affiliated with TradingView, needs a paid TradingView subscription and TradingView Desktop started with remote debugging enabled, and can break when TradingView changes its app. If you use it, use it only to read your own code, not to collect data.

For published open-source scripts, TradingView's publishing rules apply: rebuilding someone else's script in Trigr is a derivative work, so credit the author and respect the license.

How do Pine concepts map to Trigr's node graph?

A Trigr strategy is a node graph: exactly one TRIGGER, optional FILTERs, a SIGNAL that combines them, a RISK node, and an EXECUTE node. Here is a typical Pine strategy to translate:

//@version=6
strategy("EMA 20/50 + RSI", overlay = true, pyramiding = 1,
     default_qty_type = strategy.percent_of_equity, default_qty_value = 10)

fast = ta.ema(close, 20)
slow = ta.ema(close, 50)
rsi  = ta.rsi(close, 14)

if ta.crossover(fast, slow) and rsi < 70
    strategy.entry("Long", strategy.long)

if strategy.position_size > 0
    entry = strategy.position_avg_price
    strategy.exit("Exit", "Long", stop = entry * 0.97, limit = entry * 1.06)
    if bar_index - strategy.opentrades.entry_bar_index(0) >= 48
        strategy.close("Long")

Most of it maps directly:

Pine concept Trigr equivalent
Entry condition (ta.crossover(fast, slow)) TRIGGER node, e.g. an MA-cross indicator with fast 20 and slow 50
Extra condition (rsi < 70) FILTER node: RSI, length 14, comparator <, threshold 70
and / or between conditions SIGNAL node combine mode (all, any, score or group)
default_qty_value = 10 percent of equity RISK size (1–100% of capital)
margin_long / leverage assumptions RISK lev (1–50×)
strategy.exit stop and limit RISK sl and tp, as percentages (0.2–50%)
Trailing stop RISK trailAtr (ATR multiple) and trailAtrPeriod
Close after N bars RISK maxBars (time stop)
strategy.long only RISK direction: long, short or both
pyramiding RISK max positions (1–20 same-side entries; above 1 only with the signal-flip exit, since any TP/SL, trail or time stop requires 1)
Reversing on the opposite signal RISK onOpposite: reverse, ignore or reduce-only; exitOnFlip
request.security higher timeframe A node's own timeframe, read from completed higher-timeframe bars only
Chart symbol The strategy's market; any node can read a different asset

Two translation details deserve a check. First, a Pine crossover fires on one bar, while a condition node may describe a state (fast above slow). In Trigr's engine the MA-cross condition is evaluated as that state, so after a stop-out the strategy can re-enter while the trend persists. Decide whether that is what you want, and test both readings as experiments. Related: exitOnFlip is on by default, so the port also exits on the opposite cross; set it to false to match a Pine strategy that only exits on its stop, target or time stop. Second, the catalog's parameter names and ranges are authoritative, not the assistant's memory, which is why the workflow below starts with a catalog search.

What has no Trigr equivalent?

Be honest with yourself here, and ask the assistant to be honest too:

  • Arbitrary custom Pine math. Loops, arrays, custom functions and bespoke formulas cannot be expressed; only catalog indicators and data sources can.
  • Limit and stop entry orders. Trigr fills at the next bar's open after a signal.
  • Multi-level exits. Partial take-profits (qty_percent), break-even moves and custom exit graphs are not available; RISK offers one TP, one SL, an ATR trail, a time stop and flip handling.
  • Trailing by points or percent. The trail is ATR-based.
  • Pyramiding beyond 20 entries, pyramiding combined with a TP/SL or trail, or add-on rules that grow size per extra entry (Trigr offers only volatility-target and regime sizing).

If your edge lives in one of these, the Trigr version is a different strategy. Treat it as a new hypothesis, not a port.

What does the step-by-step session look like?

Here is a realistic prompt sequence. In manual approval mode, every save, backtest and agent creation shows an approval page in your browser first, bound to the exact arguments.

  1. Set the frame. "Here is my Pine strategy [paste]. Before building anything, call trigr_get_account_context, trigr_list_my_strategies and trigr_list_my_agents, then list every Pine behavior we must preserve: fill timing, process_orders_on_close, calc_on_every_tick, any request.security lookahead, pyramiding, and commission and slippage settings."
  2. Map it against the catalog. "Use trigr_search_catalog to find the exact indicator ids and RISK parameters for this logic. Give me a mapping table, and list anything you had to approximate or drop."
  3. Check data first. "Call trigr_get_data_coverage for ETH on 4H and tell me the coverage window before we spend credits."
  4. Save one strategy. "Create one draft with trigr_create_strategy named 'EMA 20/50 + RSI (ported from Pine)'." It appears in Trigr Studio immediately.
  5. Run a gross and a net backtest. "Run trigr_run_backtest on that strategyId. Then run it again with frictions: slippage 5 bps per side and real historical funding." Fees and the builder fee always apply; slippage and funding are opt-in, so the first run is gross. A standard backtest costs 50 credits.
  6. Read the evidence. "Use trigr_get_backtest_result and trigr_get_backtest_trades to compare trade counts and exits with my TradingView results, and explain every large difference." Reading stored runs and trade logs is free.
  7. Iterate as experiments. "Test a 2.5× ATR trail instead of the 6% take-profit as an experiment with experimentLabel: 'Exp 1 — ATR trail 2.5x'." Each labelled run lands in that strategy's version history without changing the saved recipe. The MCP server's own instructions tell assistants to keep one strategy per idea and treat parameter, filter, exit or sizing changes as experiments. Iterating with AI experiments explains why this keeps your trial count honest.
  8. Promote the winner. "Save the best experiment with trigr_edit_strategy, then backtest the saved recipe once without a label." The edit uses the recipe hash, so a stale edit fails safely.
  9. Create a paper agent. "Create a paper agent with trigr_create_agent: $1,000 capital, one slot at 100% on ETH, using this strategy's current recipe hash." Agents created over MCP are always PAPER and always PAUSED.

Expect differences from the TradingView numbers. Trigr fills at the next bar's open, uses point-in-time data, applies fees on every trade, and resolves intrabar TP/SL conflicts conservatively. Why your Pine Script backtest looks better than it will trade walks through each gap.

How do you go from paper to live?

This is the step the assistant cannot take, by design. Trigr's MCP server cannot start execution, place a live trade, withdraw funds, or edit exchange credentials. It can pause an agent, rename it or change its capital, but not start one.

In the Trigr app, you review the paused paper agent, start it, and let it build a forward record on data that did not exist when you chose the strategy. Paper agents fill at the current Hyperliquid price and pay fees, but model no slippage or funding. The paper trading guide covers what to watch.

When you decide to go live, create a new Hyperliquid agent from the same strategy in the app (an existing agent's venue can't be switched) and approve a trade-only agent key that can place and cancel orders but cannot withdraw. You keep the master wallet and custody of your funds. Only crypto perps can run live in the current beta; TradFi HIP-3 markets are backtest and paper only.

Backtests are not guarantees; perps are leveraged and can lose more than expected.

Why use Trigr for this instead of automating Pine alerts?

A common alternative is wiring TradingView alerts to a webhook bot. That runs the strategy on TradingView's signals, which can run into the data-use restrictions above, and it keeps TradingView's optimistic backtest as your only evidence.

The Trigr path is different in three ways that matter:

  • Honest evidence before capital. Point-in-time data, next-bar-open fills, and explicit gross versus net results with slippage and funding.
  • Bounded AI authority. The assistant builds and tests, but approvals are single-use and bound to exact arguments, and live trading stays in your hands. See the Trigr MCP server overview for the full tool list.
  • One path to execution. The same strategy moves from backtest to paper agent to a non-custodial Hyperliquid agent without being rewritten.

Next steps

Connect your assistant from the Trigr MCP setup page, paste one Pine strategy you know well, and compare the Trigr trade log against your TradingView list before you trust either. The AI agents and MCP docs list every tool used above.

Frequently asked questions

Can the official TradingView MCP server read my Pine Script strategies?

No. As of September 2026, TradingView's official MCP server (public beta since 2026-09-16) documents 35 tools for watchlists, market data, screeners, news, fundamentals, calendars and alerts. None of them reads or writes Pine scripts or Strategy Tester results, so you paste the code from the Pine Editor or use another route.

Can I run a TradingView strategy automatically on Hyperliquid with Trigr?

You can rebuild the strategy's logic as a Trigr node graph, backtest it on Trigr's own point-in-time data, and run it as a trading agent. Trigr's MCP server can only create a paused paper agent; you resume it in the app, and going live means creating a Hyperliquid agent from the same strategy in the Trigr app yourself.

Does every Pine Script strategy translate to Trigr?

No. Rule-based strategies built from standard indicators, TP/SL, trailing stops and time stops usually map well. Arbitrary custom Pine math, limit or stop entry orders, multi-level partial exits and custom exit logic have no direct equivalent, and the assistant should tell you where it approximated.

Is it allowed to use TradingView data in an automated trading agent?

TradingView's Terms of Use restrict its market data to human-readable display and prohibit algorithmic trading and other machine-driven uses of that data. The safe pattern is to port your own strategy logic, then backtest and run it on Trigr's data, never piping TradingView data into automation.

Put the idea to an honest test.

Describe a strategy in plain English or from your own AI assistant, backtest it on point-in-time data, and forward-test it on paper before any real money is involved.