What to check before running a trading agent from Claude

Claude can control a trading agent through the Model Context Protocol, but the connection is only as safe as the limits you configure first. Before the agent sends its first order, you need to create a scoped key, set a budget cap, define an exit plan, and verify the non-custodial wallet setup. This checklist walks through each step so that the agent can trade within boundaries it cannot cross, even if the model misinterprets a prompt or the market moves against the position.

What does Claude need to trade?

Claude does not log into a brokerage website or wallet interface. Instead, it connects to Felix through the Model Context Protocol, which exposes trading tools that Claude can invoke like any other function. If you run Claude Desktop or another MCP client, you configure the Felix MCP server once, and the tools appear in Claude's context automatically. The MCP server translates natural language intent into structured API calls, so when you ask Claude to check a position or place an order, it sends a request to the Felix API on your behalf. You still need an API key, but unlike a traditional exchange key, this key is scoped by you before Claude ever uses it. The key permissions determine which markets the agent may access, whether it can read data or also submit orders, and how much capital it is allowed to spend. One key reaches stocks, crypto, perps, options, and prediction markets, but the permissions attached to it can restrict the agent to just one of those categories. You should start by deciding exactly what the agent is allowed to do, then generate a key that matches that scope and nothing more. The API normalizes order sizing and market conventions, so Claude does not need to learn venue-specific formatting rules.

The connection is persistent. Once the MCP server is running, Claude can invoke trading tools in the middle of a longer conversation about market conditions. This means you might ask Claude to summarize a news article and then immediately say 'open a position based on this.' The model will switch from analysis to execution within seconds. That speed is useful, but it also means you should be careful about accidental instructions. A scoped key ensures that even if Claude misunderstands a casual remark as a trading signal, the API will only execute what the key allows.

How do you scope the agent's authority?

Start with the principle of least privilege. If the agent is meant to trade prediction markets, do not grant it permissions for options or perps. If it is only meant to read prices and report them, disable trading entirely. The Felix LLM trading safety model is built around this idea: the model should not have an opportunity to make a mistake it cannot recover from. Scoped keys are the first layer. You define the action set, the market types, and the maximum spend per order. You can also restrict the agent to specific symbols or categories. Non-custodial architecture means the funds stay in a wallet you control. The agent can submit orders, but it cannot withdraw funds to an external address unless that address has been pre-approved by you. This is why non-custodial trading keeps your money safe even when the agent has active access. You should also set a daily or weekly budget cap that the agent cannot exceed. Once the cap is hit, the API rejects further orders until you reset it. The agent cannot raise its own cap because the permission to modify limits is reserved for the owner. Withdrawal addresses are owner-approved only, so even if the agent were compromised, it could not move funds outside your control. You should also review the default permissions that come with a new key. Disable any market type or action that is not part of your plan. If you are building a simple price alert bot, turn off order submission entirely. If the agent will only trade during market hours, you can set time windows on the key so that orders submitted outside those windows are rejected automatically. These constraints reduce the attack surface and prevent errors that happen when a model acts on stale information.

How do you cap the agent's budget and positions?

Budget caps are expressed in plain US dollars. The API normalizes venue-specific contract math, so you tell the agent to risk one hundred dollars, not to calculate lot sizes, margin multipliers, or token decimals. This removes a common source of error where a model misreads a contract specification and submits an order ten times larger than intended. Because the API handles the translation, you can think in terms of dollar exposure rather than contract units. Position limits work alongside budget caps. You can set a maximum position size for each market type, as well as a total exposure limit across the portfolio. For example, you might allow a two hundred dollar position in a single stock and a five hundred dollar total across all stocks. These are hard limits for stock trading and other asset classes that the agent cannot negotiate or override. The system enforces them at the API level, not inside the model's reasoning loop. This is critical because an LLM can hallucinate, misread a prompt, or interpret a vague instruction aggressively. The API acts as the final gatekeeper. If the agent attempts to exceed the limit, the order is rejected and Claude receives an error message explaining why. You can also set rate limits on how many orders the agent may place per minute, which prevents rapid-fire mistakes during a confusion loop. When you set a position limit, think about correlation. A five hundred dollar total exposure limit might be breached if the agent opens three correlated positions that move together. You can set sub-limits per symbol or per sector to prevent concentration. The API tracks exposure in real time, so if an existing position grows in value and pushes the agent over the total limit, new orders are blocked until the exposure drops.

How do you test before going live?

Paper trading is the only environment where you should let Claude experiment. Create a paper key, connect it to your MCP client, and run the agent through realistic scenarios. Ask it to place a small order, check the position, and exit. Watch how it handles ambiguous instructions. If you say 'reduce my exposure,' does it sell the entire position or just a portion? Does it confuse market orders with limit orders? These mistakes are harmless in paper mode.

• ·Place a small order and verify the position size matches the dollar amount you intended.
• ·Ask the agent to exit the position and confirm it chooses the correct order type.
• ·Submit an order that exceeds the budget cap and verify the API rejects it.
• ·Trigger the kill switch and confirm it flattens all positions and revokes the key.
• ·Test ambiguous prompts like 'reduce exposure' or 'buy more' to see how Claude interprets them.

You should also test edge cases. Ask the agent to trade more than its budget cap and verify that the API blocks the order. Paper trading also lets you test the authorization flow itself. Create a live key, but do not authorize it yet. Verify that the API rejects orders from the unauthorized key. This confirms that the safety gate is working. Only after this test should you complete the authorization step with a small initial budget. During testing, document the exact prompt patterns that worked and the ones that caused confusion. Prompt design is a major factor in agent reliability, and a news-driven trading checklist for beginners can help you structure inputs that the model is less likely to misinterpret. Never authorize a live key until you have seen the agent behave correctly across multiple paper sessions.

How do you build an exit plan and kill switch?

An exit plan is a set of rules that tell the agent when to close a position, but it is also a hard limit. You can configure take-profit and stop-loss levels at the API level so that even if Claude fails to act, the system will exit the trade. This protects you from a model freeze or a network delay. The exit plan is part of normal operations. The kill switch is different. It is a manual or automated trigger that immediately flattens all positions and revokes the API key. It is owner-controlled and the agent cannot override it. You should define the conditions under which you will use it before you start trading. Examples include a sudden market crash, a string of unexpected orders from the agent, or a loss that hits your daily budget cap faster than anticipated. The kill switch is not a substitute for proper limits, but it is the final backstop. Test it in paper mode at least once. Know the exact command or button, and make sure you can execute it without needing to ask the agent for help. After you pull the switch, review the logs to understand what triggered the event before you consider reactivating the agent. Some traders automate the kill switch with external monitoring. For example, you might run a script that watches the portfolio value and triggers the switch if the drawdown exceeds a threshold you set. This removes human reaction time from the equation. Whether manual or automated, the switch must be independent of the agent's own logic. If the agent is the one monitoring the portfolio, it might fail to trigger the switch precisely when it is most needed.

How do you monitor the agent after it goes live?

Once live, the agent operates within the boundaries you set, but boundaries do not remove the need for oversight. Review the order logs daily at first. Look for orders that are technically within limits but strategically wrong. For instance, the agent might be allowed to trade up to one hundred dollars per order and might place five orders in one minute because the prompt said 'scale in.' The API permitted each order, but the behavior was not what you intended. This tells you to tighten the prompt or add a rate limit. Audit logs also let you verify that the non-custodial wallet only moved funds to pre-approved settlement addresses. If you see any attempt to withdraw to an unapproved address, that is a signal to revoke the key immediately, even though the system would have blocked it anyway. Over time, you will refine the scoped key permissions, the prompt templates, and the budget caps based on what the logs reveal. You may discover that the agent works well for prediction markets but makes predictable errors with options Greeks. In that case, you simply remove the options permission from the key. Remember that trading can lose money, including everything, and no set of limits can guarantee that an automated strategy will be profitable. The goal of the checklist is to prevent runaway losses, not to promise returns. Consider setting a calendar reminder to review and rotate the API key every few months. If the key has been stored in an MCP client configuration file or a backup, rotation limits the damage from a future leak. When you rotate, use the opportunity to tighten permissions based on what you have learned from the logs. The best scoped key is one that has been refined through observation.