claude-tradingview-mcp-trading: letting Claude Code place trades on BitGet

The strategy lives in rules.json, and the agent reads it before anything else

The architecture is unusual in that the trading strategy is not code. It is a file, `rules.json`, and the README's step table shows the agent reading it as step one of every run.

The full sequence is described in the What This Does section as five outcomes: Claude connected to your exchange so it reads your TradingView chart and executes trades on BitGet automatically, a safety check where every condition in your strategy must pass before a single trade goes through, 24/7 cloud execution on a Hostinger VPS, automatic tax accounting with every trade logged to `trades.csv`, and the project being free with no email, course or upsell.

The step table then spells out what Claude actually does in a run. It reads your `rules.json` strategy, pulls live price and indicator data from TradingView, calculates MACD from raw candle data, evaluates market bias as bullish, bearish or neutral, checks trade limits for a daily cap and max trade size, runs the safety check with every entry condition checked, executes the trade via BitGet if all conditions pass, logs the trade to `trades.csv` with date, price, fees and net amount, and saves a full decision log to `safety-check-log.json`.

The important design decision is that the strategy is data and the agent is the interpreter. The same agent can be pointed at a different `rules.json` without touching code, and the README says the onboarding flow can optionally build a strategy from a YouTube channel, which implies the rule format is meant to be authored rather than programmed.

When the safety check fails, the README says the run stops and tells you exactly which condition failed and the actual values, and that no trade goes through unless everything lines up. The `safety-check-log.json` file is the record of that reasoning, kept separately from the trade log so you can audit decisions that never became orders.

The one-shot prompt is the setup, and the manual path is the same steps by hand

The README positions a single file as the entry point. You open Claude Code in the project directory, paste the entire contents of `prompts/02-one-shot-trade.md`, and Claude does the rest.

What that prompt does is described in the Getting Started section, and it is a lot for a pasted file. Claude acts as your onboarding agent: it clones the repo, walks you through connecting BitGet, sets your trading preferences, connects TradingView, optionally builds a strategy from a YouTube channel, deploys it to a Hostinger VPS, and runs the bot for the first time. Every step is interactive, and it pauses when it needs something from you while handling everything else itself.

For anyone who wants to understand the steps manually or troubleshoot a specific part, the README then documents the same process as explicit commands. That section starts with prerequisites: TradingView MCP must already be set up, which was built in a previous video, Claude Code installed and running, a BitGet account, and Node.js 18 or newer, checked with `node --version`.

Cloning is the first manual step, and it is the same on both platforms apart from the shell:

git clone https://github.com/jackson-video-resources/claude-tradingview-mcp-trading
cd claude-tradingview-mcp-trading

Then the credentials, copied from the example file on Mac and Linux with `cp .env.example .env`, and with `Copy-Item .env.example .env` on Windows. The repository ships that example file, and it is where the full set of settings lives.

The exchange keys are the only hard boundary in the design

The `.env.example` file is where the risk controls live, and the comment at the top of the credentials block is the most important line in the repository. Withdrawals: OFF. IP whitelist: ON.

The README restates this as two rules that apply to every exchange, and it is the right framing. The safety check that Claude runs is implemented inside an agent loop, and an agent loop is a probabilistic component. A strategy that fails its own check is a good sign, but it is not the same guarantee as an API key that cannot move money out of the account.

The example file defines the whole configuration surface:

BITGET_API_KEY=your_api_key_here
BITGET_SECRET_KEY=your_secret_key_here
BITGET_PASSPHRASE=your_passphrase_here
BITGET_BASE_URL=https://api.bitget.com
TRADE_MODE=spot
PORTFOLIO_VALUE_USD=1000
MAX_TRADE_SIZE_USD=100        # No single trade can exceed this value
MAX_TRADES_PER_DAY=3          # Bot stops executing after this many trades in a calendar day
SYMBOL=BTCUSDT
TIMEFRAME=4H
PAPER_TRADING=true

The comments explain the intent of each guardrail. `PORTFOLIO_VALUE_USD` is used to calculate position size. `MAX_TRADE_SIZE_USD` means no single trade can exceed that value, and `MAX_TRADES_PER_DAY` means the bot stops executing after that many trades in a calendar day. `TRADE_MODE` is either spot or futures, and `SYMBOL` and `TIMEFRAME` pick the market and the chart interval. `PAPER_TRADING=true` is described as running in paper trading mode, which logs decisions but never places real orders.

`MAX_TRADES_PER_DAY` is worth reading as a calendar-day limit rather than a rolling window, which means a restart does not reset it if the counting is stored in the log. The repository also carries a `trades.csv` file, which is both the tax log and, plausibly, the state the day counter is derived from. The README does not say explicitly which.

The exchange guide table lists ten supported exchanges with a setup document each, including BitGet, Binance, Bybit, OKX, Coinbase Advanced, Kraken, KuCoin, Gate.io, MEXC and Bitfinex, even though the video and the code path are described in terms of BitGet.

TradingView is a local desktop app, and the cloud mode is a different data source

The connection to TradingView is done through a local MCP server, and the setup is two commands on Mac:

tv_launch
tv_health_check

The health check should return `cdp_connected: true`, and Windows and Linux have their own setup documents. The word cdp points at the Chrome DevTools Protocol, which is how a local browser can be inspected and scripted, and the practical consequence is that a TradingView desktop app has to be running on the same machine as the bot.

That is the constraint the cloud deployment section addresses, and it does so by changing the data source rather than by running a browser on a server. Cloud mode pulls candle data directly from Binance's free market API instead of TradingView, and the README states that no TradingView Desktop is needed in the cloud, and that the strategy logic and safety check are identical.

This is the most important architectural caveat in the project, because identical logic over different data is not the same result. A strategy written against a TradingView chart's indicator values is being evaluated against a different feed in the cloud, and the README does not describe any reconciliation between the two. It also means the local and cloud modes are not two deployments of one system, they are two systems that share a rules file.

The local run itself is one command, `node bot.js`, and the package manifest confirms the shape. The package is `claude-tradingview-mcp-trading` at version 1.0.0, the main entry is `bot.js`, and the scripts are `start` and `dev`, both running `node bot.js`. The runtime dependencies are only `dotenv` and `node-fetch`, with `engines` requiring Node 18 or newer, and the `bot.js` script is a single file at the root of the repository.

Cloud mode is a cron job that runs once and exits

The VPS deployment is deliberately simple, and the detail that matters is in the scheduling section. The bot runs one check and exits, so it is scheduled with the VPS's built-in cron, and the README gives a table of crontab lines matching the chart timeframe, all running from the repo directory and logging to `bot.log`.

A 4H chart maps to a line that fires every four hours, a 1D chart to one that fires once a day at 9am UTC, and a 1H chart to one that fires every hour. The README says to run `crontab -e` and add the line that matches your chart timeframe. That coupling is the point: if the strategy was written against a 4-hour chart, a cron that fires hourly will evaluate it against bars it was not designed for.

The VPS itself is a Hostinger KVM plan, described as the cheapest being plenty, from around $5 per month. You SSH in as root:

ssh root@YOUR_VPS_IP

And the deployment on the machine is a package install and a clone:

apt update && apt install -y nodejs npm git
git clone <your-repo-url> bot && cd bot
npm install

The environment variables are then set on the VPS from the same `.env.example`, and the table of them adds `PAPER_TRADING` set to false when ready, along with `SYMBOL` and `TIMEFRAME` examples of BTCUSDT and 4H.

One scheduling subtlety is worth flagging. The bot runs one check and exits, so the daily trade cap cannot be enforced by the process staying alive. It has to be enforced across invocations, which means the state has to survive between cron runs. The repository includes a `railway.json` file at the top level, which suggests a Railway deployment path exists alongside the VPS one, and the README section on running in paper mode is where the trading mode is settled, but the README does not describe the counter's storage, so the daily limit's durability across restarts is worth verifying yourself before relying on it.

The repository top level is small and tells you most of what the project is: `bot.js`, `rules.json`, `trades.csv`, `prompts/`, `docs/`, `package.json`, `package-lock.json` and `railway.json`. The `prompts/` directory is where the one-shot prompt lives, and `docs/` holds the per-exchange setup guides.

Editorial conclusion

Adopt this repository as a starting point if you want to see how a rule-driven trading agent is wired end to end, and if you will run it in paper trading mode first. Do not point it at a funded account on the strength of the README, because the safety check lives inside an agent loop rather than inside the exchange, and the exchange guardrails the README asks for, withdrawals off and IP whitelist on, are the only hard boundary. Verify first that `PAPER_TRADING=true` is genuinely in effect on the account you connect, that the exchange API key cannot withdraw, and that the VPS cron line matches the timeframe of the chart the strategy was written against.

Frequently asked questions

Official sources

1. Issues
2. jackson-video-resources/claude-tradingview-mcp-trading on GitHub
3. README