How to take an AI trading agent live with MCP

Taking an AI trading agent live with MCP means connecting a scoped API key to a real money wallet after the agent has proven its behavior in paper trading. The owner must explicitly authorize the key, set hard budget caps and position limits, and confirm that withdrawal addresses remain under their sole control. Once live, the agent can place orders denominated in plain US dollars across stocks, crypto, perps, options, and prediction markets. It cannot withdraw funds, alter its own scope, or exceed the configured limits because those controls are enforced by the infrastructure, not the agent.

What does going live mean for an MCP trading agent?

MCP trading tools let an AI agent inside a code editor or automation layer call trading functions through a single API. The agent sees a set of tools it can invoke, such as checking a balance, reading a price, or placing an order. Going live is not simply adding credentials to a prompt or changing a boolean flag in the agent's reasoning. It is a deliberate state change where the owner moves from simulated balances to real money with enforceable constraints. The API treats paper and live modes as distinct trust domains. A key must be explicitly promoted to live status by the owner, and that promotion is only possible after safety limits are attached to the key. What most people get wrong about MCP trading tools is treating the API like a passive data feed rather than an execution layer with built-in safety controls. When the agent is live, every tool call has financial consequences. A price check is harmless, but a market order moves real capital. The agent does not inherently know the difference between paper and live mode. The API knows, and it enforces the difference through the scoped key. That separation of concerns is what keeps the agent from accidentally spending money that the owner did not intend to risk.

A traditional trading bot runs a fixed script that executes the same logic every cycle. An MCP trading agent reasons about context and may adapt its plan based on new information. Because the agent can interpret new information, its limits must be enforced outside the prompt, not inside it. Relying on the agent to self-regulate is unreliable. The prompt might say trade only one hundred dollars, but if the agent miscounts or reinterprets the constraint, the API must still block the oversized order. The hard limits live in the key scope, not in the conversation history.

How do you set hard limits before the first live order?

The Felix API normalizes order sizing in plain US dollars across all venues, but the safety layer operates before any order reaches a venue. The owner sets a maximum daily or total budget cap, position limits per market type, and an exit plan. These constraints are attached to the key at creation time and cannot be loosened by the agent. How to trade every market through one API with hard limits the agent cannot cross describes how these constraints are enforced at the API level rather than inside the agent prompt. The API translates the plain dollar amount into the venue-specific contract math, so the agent does not need to know whether a stock lot is one hundred shares or a crypto perp is denominated in another unit. It simply specifies the dollar value, and the API handles the sizing. This removes an entire class of errors where agents miscalculate lot sizes or contract multipliers.

Because the system is non-custodial, funds remain in a wallet the owner controls. Withdrawal addresses are owner-approved only and cannot be altered by the agent. A practical checklist for non-custodial AI trading covers the custody model in detail. The agent can spend within its scope, but it can never withdraw to itself or to an unapproved address. Even if the agent's reasoning layer were compromised, the infrastructure would not allow a withdrawal request to succeed. The owner can also define a drawdown limit or a time-based expiry for the key, after which the key automatically degrades to read-only or is revoked entirely. This is useful for agents that are meant to run only during a specific event or trading window.

Why does every agent need paper testing first?

Paper trading uses the same MCP tools and API surface as live trading, but balances are simulated and no real money moves. The owner should observe the agent through multiple market conditions, including volatile periods, to see whether it respects size limits and does not attempt to exceed its scope. The paper environment is identical to the live environment from the agent's perspective. The tools have the same names, the parameters have the same shapes, and the responses have the same structure. The only difference is that the execution layer simulates fills instead of sending orders to real venues. This fidelity is important because it means the agent will not encounter new API behavior when it goes live. It will encounter new financial behavior, which is a different risk.

During paper testing, validate every tool the agent might call. If the agent is expected to trade options, ensure it handles contract selection correctly in simulation. If it trades prediction markets, confirm it understands binary outcome pricing and does not misinterpret the probability as a dollar value. Errors in paper mode are free. Errors in live mode cost real money. Do not authorize a live key until the agent has executed a complete mock strategy without attempting to breach limits. The owner should also test the panic switch during paper mode. Triggering the kill switch should flatten simulated positions and revoke the test key. If that step fails in simulation, it will fail in live mode when it matters most.

How do you authorize a live key while keeping custody?

Live trading requires explicit owner authorization of a key. The owner generates a scoped key that is restricted to specific markets, order types, and budget ranges. This key is then connected to the MCP client, such as Claude or Cursor, through the standard MCP tool configuration. The authorization step is a deliberate gate. Without it, the key remains in paper mode even if the agent requests live execution. The owner must log into the Felix dashboard or use an authenticated owner endpoint to promote the key. This ensures that an agent cannot social-engineer its way into live trading by asking the owner to paste a key. The owner is always the one who crosses the boundary.

The exact request schema is in the docs; the shape looks like this.

{
  "api_key": "YOUR_KEY",
  "mode": "live",
  "budget_cap_usd": 1000,
  "allowed_markets": ["stocks", "crypto"],
  "position_limits": {
    "max_single_order_usd": 100
  }
}

This illustrative shape shows the relationship between the key, the mode flag, and the budget constraint. The exact field names and endpoint paths are documented in the docs. The critical point is that the budget cap is set before the agent connects, not after. Once the agent is live, it can query its remaining budget through the API, but it cannot raise the cap. Some owners choose to start with a very small live budget, observe the agent for a week, and then increase the cap only after reviewing audit logs. This staged approach reduces the maximum damage an agent can do while it is still earning trust.

What should you watch when the agent starts trading real money?

Once the agent is live, the owner should monitor audit logs rather than just portfolio value. Audit logs record every tool call, the parameters passed, and whether the API enforced any limit. How audit logs and observability enforce hard limits on trading agents explains how this record becomes the source of truth for agent behavior. The logs answer questions that portfolio value cannot. They show whether the agent tried to place an oversized order and was rejected, whether it queried prices repeatedly in a loop, or whether it attempted to access a market that was outside its scope. These behavioral signals are early warnings. A portfolio might be up while the agent is already exhibiting risky behavior that will eventually cause losses.

Watch for drift. An agent that behaved correctly in paper mode may behave differently when it sees real slippage or latency. If it attempts to size an order that would breach the cap, the API should reject it. That rejection is a signal to review the agent's reasoning, not just a system error. Trading can lose money, including everything, so the owner should verify that the agent is not compensating for rejected orders by placing multiple smaller ones that collectively exceed intent. This is sometimes called order slicing, and while it can be legitimate, it should be understood rather than accidental. The audit log will show the sequence of orders and their timestamps, which makes the pattern visible.

How do you shut down the agent safely if something goes wrong?

Every live deployment should have a known panic switch. The Felix API includes a kill switch that flattens open positions and revokes the agent's key. The owner can trigger this manually, and some owners choose to automate the trigger based on external monitors. The flattening step is important because simply revoking the key leaves positions exposed to market risk. An open perp or an options position can still lose money even if the agent cannot place new orders. The kill switch attempts to close those positions into the market, subject to the same safety limits and liquidity constraints as normal trading. It is not a guarantee of profit or even of exit at a specific price, but it is a controlled wind-down.

Before going live, write down the exact steps to pause the agent. This includes revoking the MCP server connection, rotating the API key, and moving remaining funds to a cold wallet if needed. Knowing these steps in advance prevents hesitation during a fast market move. The goal is to make the shutdown procedure as practiced as the deployment procedure. Some owners run a fire drill once a month during paper mode, triggering the kill switch and restoring the connection from scratch. This ensures that muscle memory exists for an event that may never come, but if it does, the response is immediate rather than experimental.