How to run a trading agent with Claude from first principles

A trading agent running inside Claude is an LLM that uses Model Context Protocol tools to read balances and place orders through a single API. You do not need to write a trading bot from scratch or manage exchange-specific libraries. You need a wallet you control, a scoped API key with strict permissions, and a clear set of limits before the agent ever sees a market. The rest is configuration, testing, and gradual exposure to real price movements.

What do you need before you start?

Think of the agent as three layers. The top layer is Claude, the language model that reasons about what to do. The middle layer is the MCP client, which lets Claude discover and call tools. The bottom layer is the Felix API, which normalizes order sizing in plain US dollars and routes to stocks, crypto, perpetual futures, options, and prediction markets. Your funds sit in a wallet you control. The agent can spend within limits you set, but it can never withdraw to itself or to an address you have not approved. This is non-custodial by construction. You do not surrender custody to a platform or to the AI.

You will need to decide which markets to access first. A beginner usually starts with one market type to limit complexity. The API uses the same shape for all five, but the risk profiles differ significantly. Perpetual futures and options carry leverage and expiry mechanics that can accelerate losses beyond the initial margin. Stocks and prediction markets move differently and carry their own liquidity patterns and hours. Crypto spot markets trade continuously but can gap on weekends. Choose one domain, understand its basic mechanics, and let the agent operate there until you have observed enough behavior to trust the control layer.

How does Claude differ from a traditional trading bot?

A traditional trading bot runs on a fixed script. It loops, checks a price, and fires an order. It does not reason. An MCP trading agent, by contrast, reads a tool schema, decides whether to act, and constructs arguments dynamically based on the context window. Claude sees functions like get_balance, place_order, or get_positions, and chooses which to call based on your prompt and the current market state. This means the agent can adapt to new instructions without a code deployment, but it also means the prompt becomes part of the control surface. A poorly worded prompt is not just a user experience issue. It is a live risk factor.

This distinction matters for risk management. A bot typically fails because of a code bug or a bad static parameter. An agent can fail because of prompt ambiguity, tool misinterpretation, or an unexpected market state described in natural language. Understanding how trading bots differ from MCP trading agents helps you apply the right safety controls. Scoped keys, budget caps, and position limits become more important when the decision maker is an LLM rather than a deterministic loop. The LLM can improvise, so your guardrails must be explicit and hardcoded at the API level, not just suggested in the prompt.

How do you set up safety controls before the first trade?

Safety is not an afterthought. It is the first configuration step. Felix uses scoped API keys, which means the key you give Claude can only perform the actions you whitelist. If you only want the agent to read balances and place spot orders, you remove permissions for withdrawals, leverage changes, or option writing. Budget caps enforce a maximum dollar exposure per day or per trade. Position limits prevent the agent from concentrating too much in one instrument. Exit plans and take-profit logic can be encoded as automated rules that trigger even if the LLM is slow to respond. These rules live at the API layer, so they execute regardless of what the model is thinking.

Live trading requires explicit owner authorization of a key. Until you authorize, the agent can only paper trade. Paper trading exists for testing and lets you observe how Claude interprets prompts without risking capital. However, paper environments lack slippage, liquidity gaps, and the emotional pressure of real losses. Reading why paper trading misleads AI agents before you draw strong conclusions from simulated results is strongly recommended. Treat paper trading as a syntax check and a prompt validation tool, not a performance forecast. It confirms the agent can form orders correctly. It does not confirm the strategy has edge.

The most important control is the panic or kill switch. It flattens positions and revokes access immediately. You should test this before going live. Know where it is and what it does. Verify that it works from your mobile device, not just your development machine. Using scoped API keys for real money is non-negotiable because a general key is too broad for an autonomous system. Scope, test, then authorize. If you cannot confidently trigger the kill switch in under thirty seconds, your setup is not ready for live markets.

What does a first deployment look like in practice?

Start with a small, specific prompt. Instead of asking Claude to beat the market, give it a bounded task. For example, suppose you want to maintain a fixed percentage allocation between two assets. You define the target weights, the rebalance threshold, and the maximum order size in dollars. You tell the agent to check balances once per hour and to trade only if the drift exceeds the threshold. This keeps the reasoning scope narrow and the risk visible. The agent has a clear objective, a clear constraint, and a clear idle state. Ambiguity is the enemy of safe automation.

Claude connects through MCP tools or the REST API. Most beginners start with an MCP client like Claude Desktop or Cursor. The client reads the tool definitions from Felix and presents them to the model. When Claude decides to act, it emits a tool call that the client forwards to the API. You do not need to write the integration logic yourself. You only need to configure the client with the correct server endpoint and the scoped key. The exact request schema is in the docs; the shape looks like this:

{
  "intent": "place_order",
  "market_type": "crypto",
  "symbol": "BTC",
  "side": "buy",
  "dollar_amount": 50.00,
  "max_slippage_percent": 1.0
}

The agent does not need to understand lot sizes, tick sizes, or venue-specific contract math. The API normalizes these details and sizes orders in plain US dollars. This removes an entire class of beginner errors where a bot sends the wrong decimal place or contract multiplier. You think in dollars, the agent thinks in dollars, and the API translates. This normalization is especially helpful when you run the same prompt across multiple market types, because the dollar abstraction hides the underlying instrument complexity.

How do you move from paper trading to live markets?

Transitioning to live trading requires explicit owner authorization of a key. The system will not trade real money until you approve the specific key and its scope. Before you authorize, review the full permission list one more time. Confirm the budget cap, the approved withdrawal addresses, and the kill switch settings. Trading can lose money, including everything. No safety control can eliminate market risk. It can only limit how quickly the agent can spend what you have allocated. Authorization is a deliberate act that marks the boundary between simulation and real exposure.

Start with an amount you can afford to lose entirely. This is not pessimism. It is a calibration standard. If the loss would affect your sleep, the budget is too high. Reduce the cap, extend the paper trading period, or simplify the strategy. Evaluating an autonomous trading system as a beginner means watching behavior rather than returns. Does the agent follow the prompt? Does it respect the dollar limits? Does it panic or freeze in volatile conditions? Does it generate unexpected tool calls? Answer these questions with small sums before you consider scaling the budget or adding markets.

How do you keep the agent healthy after launch?

An agent is not a set-and-forget system. Markets change, and so should your controls. Review the agent's audit logs regularly. The logs show every tool call, every order, and every error. Look for drift. If the agent starts trading more frequently than intended, or if the prompt wording leads to unexpected interpretations, update the prompt or tighten the scope. Add markets only when you have verified behavior in the first one. Expanding too quickly is a common source of uncontrolled risk.

Schedule periodic kill switch tests. Verify that revoking the key immediately halts new orders and that the flatten logic executes as expected. Update your exit plans if market volatility changes. An agent that worked in a calm market may need tighter position limits when ranges expand. Maintenance is continuous, not a one-time setup task. You should also review the prompt itself monthly. A prompt that made sense in a trending market may become dangerous in a choppy one. The LLM does not know the regime has changed unless you tell it.

What are the most common first mistakes?

Beginners often give the agent an open-ended goal like grow the portfolio without defining drawdown limits or instrument scope. The LLM interprets this broadly and may trade more aggressively than intended. Always pair the objective with constraints. State what the agent should not do as clearly as what it should do. Define the maximum number of trades per day, the allowed symbols, and the conditions under which it must stop. A good prompt reads like a contract with a careful employee, not a wish to a genie.

Another mistake is confusing activity with edge. An agent that places many orders feels productive, but frequent trading increases fees and slippage. A well-constrained agent should often do nothing. If your strategy does not have a clear idle state, the prompt is too loose. Finally, beginners sometimes ignore the non-custodial structure and try to fund the agent with more capital than necessary. Keep the wallet balance modest relative to your total holdings. The agent can only spend what is in the wallet, so excess funding is unnecessary risk. Fund only what the budget cap allows.