Claude for Trading: A Research Workflow to a Paper Agent

TL;DR: Connect Claude or Claude Code to Trigr's MCP server, then run research as a fixed pipeline: read account context, pre-register one hypothesis with costs and a trial budget, search the catalog, build one strategy, test variants as labelled experiments, freeze the winner, and let Claude create a paused paper agent. Claude does the tedious work; you keep the decisions, and nothing goes live without you.

Why use Claude for trading research at all?

Claude is good at the parts of quant research that are tedious for humans: translating an idea into exact parameters, keeping track of which variants were tried, reading hundreds of trades for patterns, and writing up results. It is not good at knowing what a backtest would return without running one. No language model is.

That is why the setup matters more than the prompt. Connected to a real engine through the Model Context Protocol, Claude calls tools and reports real numbers. Left alone, it produces plausible fiction. The workflow below keeps Claude on the right side of that line.

How do you connect Claude to Trigr?

Trigr runs one remote MCP server at https://trigr.xyz/mcp.

• Claude on the web or desktop: add a custom connector with that URL, then connect. Custom connectors are available on Claude's Free, Pro, Max, Team and Enterprise plans, with Free limited to one.
• Claude Code: run claude mcp add --transport http --scope user trigr https://trigr.xyz/mcp, then authenticate from the /mcp menu.

Authorization happens in your browser and creates a revocable credential, so there is no API key to paste anywhere. You choose an approval mode per connection: manual, where Trigr asks for a browser confirmation before each consequential action, or autonomous, where the connection continues without prompts. Both use a ten-minute, single-use authorization bound to the exact tool arguments. The full setup, including Codex, is in connecting Claude Code and Codex to Trigr.

In Claude Code, Trigr's reusable prompts appear as slash commands: /mcp__trigr__build_strategy, /mcp__trigr__improve_strategy and /mcp__trigr__research_marketplace. In Claude's chat apps you can simply say "Use Trigr to build a strategy."

What does the research workflow look like?

Once connected, run every research session through the same five steps. The order matters more than the wording of any single prompt.

Step 1: Start with account context

Every Trigr workflow begins by reading your plan, credits, saved-strategy quota, existing strategies and agent summaries. This is cheap and prevents the most common waste: a research plan that needs 40 backtests on an account with credits for 10, or a new draft that duplicates a strategy you already have.

Ask Claude to summarize what it found before proposing anything.

Step 2: Pre-register the hypothesis

This is the step people skip, and it is the one that makes the rest meaningful. Before any backtest, write down with Claude:

• The idea, in one sentence and with a mechanism: "ETH longs work better when funding is negative, because crowded shorts get squeezed."
• Market and timeframe.
• Costs: a slippage assumption in basis points per fill and whether to include funding.
• A trial budget: the maximum number of variants you will test, for example eight.
• Ranking metric and minimum evidence: for example risk-adjusted return with a minimum trade count, not the highest raw return.
• Pass or fail criteria, stated before you see results.

The reason is statistical. Bailey and López de Prado's work on the Deflated Sharpe Ratio shows that the best Sharpe ratio across many trials is biased upward by the number of trials. An assistant that can run 50 variants in an hour will find an impressive one by chance. A written budget keeps the search small and the result interpretable.

Step 3: Search the catalog and build one strategy

Claude should never guess an indicator name or a data feed. Trigr's capability catalog lists the assets, timeframes, indicators, data sources and parameter ranges that actually exist, and Claude can check point-in-time data coverage for a market before relying on a series. If your idea needs ETH funding on a 4H timeframe, Claude looks up the exact source id and its history first.

Then Claude validates the node graph and saves one draft. Open it in Studio and read it: the trigger, each filter, and the RISK node's size, leverage, direction and exits. Anything Claude saves appears in the same account you use in the app.

Step 4: Backtest gross, then net

Claude runs a first backtest. Trigr applies trading fees and the builder fee to every run, so the first result is gross of slippage and funding only. Claude then runs it again with your pre-registered slippage and funding. Report the two side by side.

Fills happen at the next bar's open after a signal, every feature uses only data available at the bar's close, and when a take-profit and stop-loss are both touched inside one bar the engine replays 5-minute bars to see which came first, with the stop winning if it is still ambiguous. Those rules are explained in point-in-time backtesting.

Step 5: Iterate with experiments, not new strategies

Every change inside your budget, such as a tighter stop, an added filter or a different EMA length, runs as an experiment. Claude calls trigr_run_backtest with the strategy's id and an experimentLabel, and the run is recorded in that strategy's version history without touching the saved recipe. trigr_get_backtest_result lists every run with its label, so the trial count stays in plain view. A new market, timeframe or signal family is a new strategy; everything else is an experiment. The reasoning is in iterating on a strategy with AI experiments.

Have Claude page through the trade log of the leading variant; stored runs and their trades can be read for free. Two units to keep straight: trade prices are reference prices before slippage, and per-trade P&L is in units of an account that starts at 100, not dollars.

How do you freeze the winner and test it honestly?

When the budget is spent, pick one winner and freeze it: record the exact graph and cost assumptions. Do not swap it for the runner-up after seeing more results.

Then look for evidence the search did not touch. Be precise here, because it is easy to fool yourself:

If the frozen winner fails its test, the idea is rejected. Re-tuning against the same window turns it into research data.

How does the paper agent step work?

The last step Claude can take is creating a paper agent in a paused state, with your frozen strategy in a slot and a capital amount. It can also edit the agent's name, capital or paused state. It cannot start execution, place a live trade, withdraw funds or edit exchange credentials; those capabilities are not exposed over MCP at all.

You review the agent in the Trigr app and start it yourself. Paper agents fill at the current Hyperliquid price and deduct a 4.5 bps taker fee plus the builder fee; they model no slippage and no funding. The guide to paper trading agents covers how long to run one and what to compare.

Who does what?

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

Next steps

Use the guided MCP setup to connect Claude, then start with the build prompt and a written trial budget. The MCP server guide lists every tool and limit.