# FriesTrader > A fully automated AI trading agent, unattended once set up: trades real Robinhood orders via its Agentic Trading MCP. Two scheduled Claude Code sessions a day screen stocks and place trades under a narrow gate, with mechanical risk rules as the safety layer. Cheap to run -- Claude Pro only, no metered API spend. Not financial advice. - **Type:** MCP server - **Install:** `agentstack add mcp-yizhisong-friestrader` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [YizhiSong](https://agentstack.voostack.com/s/yizhisong) - **Installs:** 0 - **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [YizhiSong](https://github.com/YizhiSong) - **Source:** https://github.com/YizhiSong/FriesTrader ## Install ```sh agentstack add mcp-yizhisong-friestrader ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # FriesTrader An AI trading agent built to run cheap and fully on its own, trading real orders on [Robinhood](https://robinhood.com) using its [Agentic Trading MCP server](https://robinhood.com/us/en/agentic-trading/). Once set up, it runs unattended on its own schedule every weekday, no manual triggering needed. Two short scheduled Claude Code sessions a day screen stocks, write out their reasoning, and (only under a narrow, explicit gate) place real trades, without a team of specialized sub-agents burning tokens on every decision. The actual safety mechanism is mechanical, auditable risk rules, not the model's judgment, and because it's just two lean sessions instead of a multi-agent pipeline, it runs comfortably on a Claude Pro subscription (as low as $200/year on the annual plan), no Claude Max or metered API spend required. This is a template/framework extracted from a real, live deployment. Adapt it, don't just run it blind — read "What this does and doesn't solve" below before pointing it at real money. ## Why this is safer than it sounds "Fully autonomous" and "trading real money" together should make you nervous. Here's what actually stands between a thesis and an order: - **Every trade passes through mechanical rules the LLM cannot override** — position sizing, stop-loss, take-profit, daily/weekly loss limits, a wash-sale guard. A good story never cancels a stop-loss. - **New deployments start in `dry_run` and stay there** for a minimum number of cycles (`dry_run_min_cycles_before_live`) before a live order is even possible, so you can watch it screen and reason before it touches real money. - **Only you can flip `execution.mode` to `"live"`** — the agent is explicitly barred from ever changing this itself, and refuses to place live orders while `dry_run`. - **Every decision is logged, approved or rejected** — `trade_log.jsonl` is append-only, so you can check whether the reasoning is actually sound, not just trust it. ## Requirements - A [Robinhood](https://robinhood.com) account with [Agentic Trading](https://robinhood.com/us/en/agentic-trading/) enabled, connected via Robinhood's own MCP server. - [Claude Code](https://claude.com/claude-code), on a Pro subscription or higher. - A GitHub account, to host your own fork of this repo. ## How it works Trading runs as **two separate phases, on two separate schedules** — a full trading day's closing data feeds the thesis, and a fresh opening price is used for the actual order, rather than trading on a stale overnight price. ```mermaid graph TD RH[Robinhood MCP] -- watchlist + scan / quotes / historicals --> A[Phase A: Screen & Thesis] A -- thesis per candidate --> P[pending_proposals.jsonl] P --> B[Phase B: Re-verify & Risk Enforcement] RR[risk_rules.json] -- mechanical limits --> B RH -- fresh open price / positions --> B B -- dry_run or gated live order --> RH B -- every decision logged --> L[trade_log.jsonl] L -- plain-English recap --> REC[trade_log_recent.md] ``` - **Phase A** (Steps 1–3, ~4:30pm Central weekdays) — screens candidates from your watchlist plus a supplementary market scan, gathers signals, writes a logged thesis per candidate to `pending_proposals.jsonl`. Places no orders, not even dry-run ones. Full spec: `PHASE_A_TASK.md`. - **Phase B** (Steps 4–7, ~8:35am Central weekdays) — re-verifies Phase A's proposals against fresh opening data, enforces `risk_rules.json` mechanically, and dry-runs or (gated) places orders. Full spec: `PHASE_B_TASK.md`. Both are designed to run as cloud-hosted scheduled agent sessions, independent of any local machine — each run clones this repo fresh and commits/pushes its results back to `main`, so the repo itself is the persistent state, not local disk. - `risk_rules.json` — the hard, mechanical limits (position sizing, stop- loss, loss limits, universe filters, execution mode, wash-sale guard). Nothing in this system should be able to override these. Several fields need your own account details before this is usable — see First-time setup below. - `PHASE_A_TASK.md` / `PHASE_B_TASK.md` — the full, self-contained spec each phase follows. - `trade_log_template.jsonl` — the log line shapes; real logs accumulate in `trade_log.jsonl` in this same style. ## See it in action This is what a real Phase B cycle actually produces (`trade_log_recent.md`, regenerated every run, symbols genericized): > **2026-07-09** > > **Loss limit**: OK — daily 0.0%, weekly -2.1%, within -5%/-10% limits. > > **Held positions** (stop-loss / take-profit): > - EXAMPLE — stop 7.00% (vol-scaled), drawdown -2.3% — holding > > **New-entry candidates considered**: OTHER, ANOTHER > - OTHER — approved: medium conviction, $60.00 (12% of account) > - ANOTHER — rejected: max_concurrent_positions already filled this cycle > > **Orders placed**: OTHER — buy $60.00 (dry_run) No JSON parsing required to see what it did and why. Full field-level examples (thesis records, raw `trade_log.jsonl` lines) are further down in Example output. ## What this does and doesn't solve - It gives you a structured, auditable version of "let an LLM screen and reason about trades" instead of an opaque one. - It does **not** make LLM-driven stock picking more likely to beat a simple index fund — there's no established track record for that, and this can't backtest the reasoning step honestly (news-based reasoning can't be validated against historical data the model may already know the outcome of). - The risk rules are the actual safety mechanism here, not the reasoning quality. Treat loosening them as the highest-risk change you can make to this system. - This is a template extracted from a real deployment trading a small personal account, shared for others to learn from or adapt. It is genuinely not financial advice, and running it against real money is entirely your own decision and risk. ## First-time setup 1. **Fork this repo** (or otherwise create your own copy) to your own GitHub account — make it private, since it'll accumulate real trading data (`trade_log.jsonl`, proposals) once running. Phase A/B commit and push results back to `main`, so you need a repo you actually control, not this one. 2. Robinhood's [Agentic Trading](https://robinhood.com/us/en/agentic-trading/) requires a separate, dedicated account — distinct from your regular investing account, and restricted to only the funds you put in it. See that page to open one and connect its MCP server to Claude Code (or to your routine's MCP connections). Nothing below works without this: every tool call in `PHASE_A_TASK.md`/`PHASE_B_TASK.md` (quotes, positions, orders, etc.) goes through it. 3. Fill in `account_number` in `risk_rules.json` with your own Robinhood account number, set `starting_capital_usd` to your real starting balance, set `universe.watchlist_name` to a watchlist you've already created and populated in your Robinhood account, and review every other threshold — the defaults here are illustrative, not a recommendation. 4. Create a scan via the Robinhood MCP's `create_scan` tool (relative volume > 2.0x, market cap above your `min_market_cap_usd`), then paste its ID into `universe.supplementary_scan_id`. Phase A calls this scan every run to surface movers outside your watchlist — left as the placeholder, that call fails every cycle. 5. Fill in `wash_sale_avoidance.linked_accounts` with every Robinhood account number you personally control, not just this one — if this is genuinely the only account you trade in, a single-entry list (just this account's number) is enough. Leave `enabled: true` unless you specifically want buys never blocked on wash-sale grounds. 6. Keep `execution.mode` set to `"dry_run"`. Leave it there for at least the number of cycles set in `dry_run_min_cycles_before_live` — don't shortcut this. 7. After each cycle, read `trade_log.jsonl` yourself. Look specifically at rejected candidates and stop-loss triggers, not just the trades that "worked" — that's where you'll see if the reasoning step is actually sound or just getting lucky with an uptrend. 8. Only flip `execution.mode` to `"live"` yourself, by hand, after you've reviewed enough dry-run cycles to trust the output. Do not let the agent flip it for you as a shortcut. ## Keeping your fork updated This template gets improvements over time. - **Easiest: GitHub's "Sync fork" button**, on your fork's main page. No local git needed. Works cleanly as long as nothing conflicts with your own changes. - **If that button refuses (conflicts, usually in `risk_rules.json`)**, resolve locally: ``` git remote add upstream https://github.com/YizhiSong/FriesTrader.git git fetch upstream git merge upstream/main ``` Resolve any conflicts in `risk_rules.json` by hand — your own account details and thresholds should win, not upstream's placeholders. ## Running it Two schedules need to fire: Phase A around 4:30pm Central on weekdays (hand Claude Code `PHASE_A_TASK.md` to execute), and Phase B around 8:35am Central on weekdays, 5 minutes after market open (hand it `PHASE_B_TASK.md`). Each run is a fresh Claude Code session pointed at this repo — no state needs to persist locally between runs, since the repo itself (`risk_rules.json`, `pending_proposals.jsonl`, `trade_log.jsonl`) is what's read and written each time. - **Recommended: Claude Code's own scheduled cloud routines.** Set one routine to run `PHASE_A_TASK.md` on the Phase A schedule and a second for `PHASE_B_TASK.md` on the Phase B schedule, with the routine's source pointed at **your fork** from First-time setup, not this repo. This runs independent of any machine being on — the actual point of "fully automated." - **Alternative: a local scheduler** (cron, Windows Task Scheduler, etc.) invoking the Claude Code CLI against your fork on the same two schedules. Works, but only while that machine is running, and you're responsible for keeping the repo synced (`git pull` before, `git push` after each run) since the repo — not local disk — is the source of truth. If you go this route, make sure only one scheduler is ever active for a given phase — two schedulers firing the same phase in the same cycle risks duplicate `risk_check`/`order` log entries, or duplicate real orders once `execution.mode` is `"live"`. ### Routine prompt templates The task specs don't cover scheduling, dates, or saving results — that's up to whatever runs them. These are the real prompts this project's live deployment uses; copy one in and swap in your own account number. #### Phase A prompt ``` You are running the DAILY automated Phase A step (screening & thesis only) for a small real personal trading account on Robinhood (account_number: ). This repo has already been cloned into your working directory. PHASE_A_TASK.md in this checkout is the full source-of-truth spec for what to do (Steps 1-3) — read and follow it exactly. First, determine today's REAL date, day-of-week, and time-of-day in America/Chicago (Central) via Bash — do not guess or infer these: TZ='America/Chicago' date +'%Y-%m-%d' TZ='America/Chicago' date +'%A' TZ='America/Chicago' date +'%H:%M:%S' Use the date as the 'date' field and the time as the 'timestamp' field (time-of-day only, e.g. "16:30:01" — never prepend the date to it) on every line you write, per PHASE_A_TASK.md's Output section. Read risk_rules.json fresh from this checkout every run — never assume prior values or cache across runs. Follow PHASE_A_TASK.md's Steps 1-3 exactly, including the screened/thesis/summary line shapes and the End-of-run summary section. Overwrite pending_proposals.jsonl in this checkout with this run's results (do not append to prior contents). Do NOT touch trade_log.jsonl. Hard stop: place_equity_order, review_equity_order, place_option_order, review_option_order, cancel_equity_order, and cancel_option_order should not be available to you in this session (exclude them at the connector level if your MCP setup allows it) — do not attempt them regardless, and do not check or reference execution.mode. When pending_proposals.jsonl is fully written, commit and push it back to this repo's main branch: git add pending_proposals.jsonl git commit -m "Phase A run " git push origin main If the push is rejected (e.g. a race with another run), run 'git pull --rebase origin main' once and retry the push once. If it still fails, report the exact conflict/error in your final summary rather than force-pushing or discarding either side's changes. End with a concise summary of what you screened/filtered/proposed, and confirm the push succeeded (include the resulting commit hash). ``` #### Phase B prompt ``` You are running the DAILY automated Phase B step (re-verify, risk enforcement, order review/execution, logging) for a small real personal trading account on Robinhood (account_number: ). This repo has already been cloned into your working directory. PHASE_B_TASK.md in this checkout is the full source-of-truth spec for what to do (Steps 4-7) — read and follow it exactly. First, determine today's REAL date, day-of-week, and time-of-day in America/Chicago (Central) via Bash — do not guess or infer these, and do not compute day-of-week yourself from the date string: TZ='America/Chicago' date +'%Y-%m-%d' TZ='America/Chicago' date +'%A' TZ='America/Chicago' date +'%H:%M:%S' Use the date as the 'date' field and the time as the 'timestamp' field (time-of-day only, e.g. "08:35:01" — never prepend the date to it) on every line you write to trade_log.jsonl, per PHASE_B_TASK.md. Determine is_monday from the day-of-week output (true only if it's literally 'Monday') for the Step 4 weekend-gap check. Read risk_rules.json fresh from this checkout every run — never assume prior values or cache across runs. Read pending_proposals.jsonl and trade_log.jsonl fresh from this checkout too. Follow PHASE_B_TASK.md's Steps 4-7 exactly, including the idempotency rule (key off each candidate's own proposal_date, not today's date), the dry-run cycle count rule, the priority/tiebreak rules, and the live-order gate in Step 6. This task is authorized to place real live orders only under that gate's narrow, explicit condition. Do not add, remove, or loosen any condition of that gate on your own judgment, and never change execution.mode or any other value in risk_rules.json yourself. Append every decision to trade_log.jsonl (do not touch pending_proposals.jsonl except to read it). When done, commit and push trade_log.jsonl back to this repo's main branch: git add trade_log.jsonl git commit -m "Phase B run " git push origin main If the push is rejected (e.g. a race with another run), run 'git pull --rebase origin main' once and retry the push once. If it still fails, report the exact conflict/error in your final summary rather than force-pushing or discarding either side's changes — this file is an append-only audit trail, treat any conflict here as serious and report it clearly rather than guessing how to resolve it. End with a concise summary of what you checked, approved, rejected, and (if applicable) placed, and confirm the push succeeded (include the resulting commit hash). ``` ### Example output **Phase A — thesis record** (one JSON line per candidate in `pending_proposals.jsonl`): ```json { "date": "YYYY-MM-DD", "timestamp": "HH:mm:ss", "symbol": "XXXX", "stage": "thesis", "thesis": "1-3 sentences on what changed and why it might matter", "conviction": "low | medium | high", "invalidation": "what would prove this thesis wrong", "direction": "long | avoid | exit_existing", "risk_flags": ["..."], "pct_below_52wk_high": 0.15, "sources": ["Outlet Name: https://...", "..."] } ``` `risk_flags` and `pct_below_52wk_high` are only included when `direction` is `"long"` — omitted for `avoid`/`ex … ## Source & license This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [YizhiSong](https://github.com/YizhiSong) - **Source:** [YizhiSong/FriesTrader](https://github.com/YizhiSong/FriesTrader) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** yes - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/mcp-yizhisong-friestrader - Seller: https://agentstack.voostack.com/s/yizhisong - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.