How to run a trading agent from Claude using MCP

You can run a trading agent directly from Claude by connecting it to Felix through the Model Context Protocol. The agent stays inside your Claude session and calls tools that route orders to markets through a single API, while your funds remain in a wallet you control. This walkthrough explains how to configure the connection, set hard safety limits, and place your first order without copying keys into chat prompts or giving up custody.

What do you need before you start?

Start with Claude Desktop or any MCP client that supports stdio or HTTP transport. Anthropic maintains the reference implementation, but other compatible clients work as long as they can launch a subprocess or connect to an HTTP endpoint. You will need a Felix account and a freshly generated API key. During creation, the key defaults to paper trading, which means every order it sends is simulated and no real capital moves. This lets you test the entire flow without risk. Your actual funds sit in a wallet or brokerage account that you own; the agent never takes possession of them. Instead, it receives a scoped key that can only spend within boundaries you define. It is helpful to read the claude trading agent custody model before you begin so you understand why the agent can never withdraw funds to itself. You should also decide your maximum budget and which markets you want to access, because these permissions are locked in when the key is created. The Felix infrastructure connects to stocks, crypto, perpetual futures, options, and prediction markets, but your key can be restricted to just one of them or any combination. If you are unsure, start with a single market and a small paper budget. You can always create additional keys later with different scopes. Finally, make sure the machine running Claude has network access to the Felix API endpoints, that you are comfortable editing a JSON configuration file to register the server, and that your operating system allows subprocess execution because some hardened environments block stdio pipes.

How do you configure the MCP server?

The Felix MCP server is a lightweight binary that Claude launches as a subprocess over stdio. You register it in your MCP client configuration by pointing to the executable and passing your API key through an environment variable. This keeps the key out of chat history and out of reach of the language model, which is important because you never want to paste credentials into a prompt. When Claude starts, it discovers the available tools automatically through the MCP protocol. Typical tools include checking your account summary, placing an order, listing open positions, canceling orders, and triggering the panic switch. The server acts as a translator between Claude’s natural language reasoning and the Felix REST API, but it can only invoke operations that your key is scoped to perform. If your key lacks permission for options, then any attempt to trade options will return a clear permission error before the request leaves Felix. The same applies to budget limits. The server does not know your private keys or exchange passwords; it only knows the scoped API key. You do not need to install separate exchange SDKs or manage venue-specific authentication, because the single API normalizes access across every market type. The server handles connection pooling, retries, and error formatting so that Claude receives clean, structured responses it can explain to you. The configuration file is usually a simple JSON object that lists the command path and the environment map, and you can find examples in the Felix documentation. If you update the key permissions or rotate the credential, you simply restart the Claude client to pick up the new environment variable.

How do you verify safety limits before going live?

Before you let the agent touch real money, open the Felix dashboard and confirm the safety profile attached to your key. Check that the market scope includes only what you intend to trade. If you only want to trade stocks and crypto, disable perps, options, and prediction markets. Next, set a daily spend cap and a total drawdown limit that reflect a budget you are genuinely willing to lose. These are not advisory guidelines; they are enforced by the API on every request. You can also set a maximum position size per trade and a maximum open position count so the agent cannot accidentally concentrate your entire budget in one order or open too many simultaneous trades across different markets. Beyond that, you can attach an exit plan that defines stop-loss or take-profit thresholds, which the system will execute even if Claude is offline. These boundaries live in the API, not in the agent, which means the agent cannot talk its way around them or edit them mid-session. The how to set spend caps and drawdown limits article covers the details of choosing these numbers. Make sure you know exactly where the panic switch is located on your dashboard, because it flattens open positions and revokes the key instantly. Paper trading exists so you can test every one of these limits without financial risk. Place some orders, hit a cap, and watch the rejection. Only after you observe the agent respecting the boundaries in simulation should you authorize the key for live trading. Remember that trading can lose money, including the full amount you allocate, so treat the cap as a hard ceiling rather than a soft suggestion.

How does the agent place its first order?

Once the server is connected, you can instruct Claude in plain language. For example, you might ask it to buy a hundred dollars of a particular crypto perp. Claude reasons through your request, selects the appropriate tool from the MCP server, and fills in the symbol and dollar amount. It does not need to know contract sizes, margin requirements, or venue-specific tick sizes. The API sizes the order in plain US dollars and handles the contract math required by the underlying venue. The how developers size orders in dollars article explains why this abstraction matters. The exact request schema is in the docs; the shape looks like this:

curl -X POST YOUR_API_ENDPOINT \
  -H "Authorization: Bearer YOUR_KEY" \
  -d '{
    "market": "perps",
    "symbol": "ETH",
    "dollar_amount": 100
  }'

The API returns the execution details to Claude, which then presents the filled notional value, the average price, and the remaining budget for that session. If the order would exceed your spend cap, position limit, or market scope, the API rejects it before it reaches the venue. The agent sees the error and reports it to you, but it cannot override the limit. This is the core safety guarantee. You can place orders across any of the five market types using the same pattern, because the API abstracts the differences between stocks, crypto, perps, options, and prediction markets. The agent can also check your open positions or cancel working orders by calling the relevant tools, so you do not need to switch between a chat window and a trading terminal. Over time, you can build more complex prompts, such as conditional entry rules or periodic rebalancing, but the mechanics remain the same. The MCP layer handles the translation, and the API enforces the limits.

How do you monitor and audit the agent?

After the agent starts trading, you should watch its activity in real time. The dashboard streams every tool call and order response, showing timestamps, market, symbol, dollar amount, and the remaining budget. You can also pull these events into your own observability stack through webhooks or log aggregation. The audit logs and observability for trading agents article describes how to wire this up. Because the system is non-custodial, you can cross-reference the Felix audit trail with your wallet or broker statements to confirm that every transaction matches the authorized parameters. If you see a request that looks unexpected, you can trace exactly what Claude asked, what the server sent, and what the API returned. This removes ambiguity about whether the agent, the market, or the API produced an unexpected result. You can also set alert thresholds, such as notifying you when the daily spend reaches fifty percent or when a position is opened outside your usual hours. Reviewing these logs daily, especially during the first week of live trading, helps you catch misinterpretations early before they repeat. Good observability is not optional for automated trading; it is the only way to verify that a scoped key is behaving exactly as intended.

How do you stop the agent if something goes wrong?

You retain several ways to halt the agent, and you should know them before you start. The most decisive is the panic switch on the dashboard, which simultaneously flattens open positions and revokes the API key. Because the key is gone, the MCP server loses authentication immediately and Claude can no longer place orders. You can also disable the Felix tool inside Claude’s settings, which stops the session without revoking the key. If you prefer a softer intervention, you can lower the spend cap or remove a market from the key’s scope in the dashboard, and the API will enforce the new restrictions on the next request. This is useful if you want to keep the agent running but reduce risk after a losing streak. Withdrawal addresses are owner-approved only, so even in a worst-case scenario where the agent behaves erratically, it cannot send funds to an external address. The non-custodial design means the worst outcome is losing the budget you explicitly scoped, not your entire wallet. Trading can lose money, including your entire allocated budget, so keeping the panic switch within reach is a basic operational requirement. Test it in paper mode so you are comfortable with the sequence when seconds matter.