How to run your first trading agent from an AI code editor using MCP

You can run a trading agent directly from an AI code editor by connecting it to a trading API through the Model Context Protocol. The editor sees a set of tools that let the agent read prices, size orders in plain US dollars, and submit trades, while you keep full custody of the underlying funds. You do not need to build a separate web application or manage exchange-specific contract math, because the API normalizes order sizing and settlement across all supported market types. Before the agent ever touches live capital, you configure scoped keys, hard budget caps, and a kill switch that only you can trigger.

What do you need before you start?

You need an AI code editor that supports MCP, such as Cursor, Claude Code, or any client that can mount an MCP server. You also need a non-custodial wallet where your funds sit, because the infrastructure is designed so that the API never takes custody of your assets. Instead of depositing into a centralized account, you retain control of the wallet and grant the API limited spending authority through a scoped key. The key is generated with trading permissions enabled and withdrawal permissions disabled by design, which means the agent can place orders within the limits you set, but it cannot move funds to an external address or alter the owner-approved withdrawal whitelist.

You should also decide which market type you want to test first. The API supports stocks, crypto, perpetual futures, options, and prediction markets through a single interface. Each market has different volatility profiles, margin rules, and session hours, so a beginner is usually better served by starting with one instrument rather than mixing them immediately. You do not need to pre-fund accounts on multiple venues or learn venue-specific order types, because the API handles the normalization. However, you must understand that trading can lose money, including the entire amount you allocate to the agent, so the capital you authorize should be money you can afford to lose without affecting your financial stability.

Finally, you need a clear plan for what the agent should do. This does not have to be a complex quantitative model or a machine learning system. It can be as simple as a set of instructions written in natural language inside the editor, such as buying a fixed dollar amount when a price condition is met and selling when a target or stop is reached. The AI translates your intent into structured tool calls, but it is still bound by the safety controls you configure in the API dashboard. Writing the plan down before you start helps you avoid the temptation to change the rules mid-session, which is a common source of mistakes.

How does MCP turn natural language into executed trades?

MCP exposes a set of tools to the AI code editor as part of the model context. When you prompt the agent, the editor sees functions like get_price, place_order, or get_portfolio alongside their parameter schemas. The agent does not guess URLs, authentication headers, or payload formats; it calls the tool with arguments that match the schema defined by the API. The editor then sends the request over the MCP transport, and the API validates the request against your scoped key, your hard budget cap, and your position limits before it ever reaches a market venue.

Because the API sizes orders in plain US dollars, the agent does not need to calculate lot sizes, contract multipliers, or margin ratios. If you tell the agent to buy one hundred dollars of an asset, the tool call sends exactly that notional value, and the API translates it into the correct quantity for the underlying market. This removes a common source of bugs where an agent might otherwise misplace a decimal, use the wrong contract unit, or submit a size that is off by a factor of one hundred. The exact request schema is in the docs; the shape looks like this.

curl -X POST "https://api.felix.trade/<endpoint>" \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "market": "example-market",
    "side": "buy",
    "dollar_notional": 100
  }'

The response returns a normalized trade confirmation that the agent can read back into its context. If the order fills, the agent sees the executed dollar size and the average fill price. If the order fails because of a limit breach, a market halt, or insufficient margin, the agent sees a structured error and can decide whether to retry or stop. This loop can happen in seconds, but you remain in control because the API gatekeeps every action. The agent cannot exceed its budget, open a position larger than your limit, or disable its own kill switch, regardless of how the model interprets your prompt.

Why is paper trading the right first step?

Paper trading lets the agent execute against simulated market data and simulated fills without touching real capital. You can test whether the agent interprets your prompts correctly, whether it handles connection errors gracefully, and whether your budget logic works as intended. Many developers skip this step and discover too late that their agent misreads a price level, loops on a retry condition, or conflates paper behavior with guaranteed live behavior. Common mistakes developers make with paper trading for AI agents can help you avoid the usual pitfalls that waste time and create false confidence.

During paper trading, you should treat the session as if the money were real. Set the same hard budget cap you would use in live mode, define the same position limits, and attach the same kill switch. If you relax the rules because the capital is fake, you will learn almost nothing about how the agent behaves under real constraints. The API provides paper trading as a first-class environment that uses the same validation logic as live trading, so the transition to real capital is a single authorization toggle once you are confident in the behavior.

Suppose your agent is supposed to buy a fixed dollar amount every hour and sell if the price drops by one percent. In paper trading, you can run it for a full market session and inspect the order history to see if it actually triggers on the schedule you intended, or if it misinterprets a temporary price drop as a larger trend. You can also check whether the cumulative dollar exposure stays within your cap over time. If the agent drifts toward the limit faster than expected, or if it ignores your sell condition, you have time to tighten the logic before any real money is at risk.

What safety controls prevent losses beyond your budget?

The most important control is the hard budget cap. You set a maximum dollar amount that the agent can deploy, and the API enforces this at the infrastructure level on every order request. The agent cannot override the cap, even if your prompt becomes ambiguous, the model hallucinates a trading idea, or the market moves violently. How an AI agent trades within a hard budget it cannot exceed explains the mechanics in detail, including how the cap interacts with open positions and pending orders.

Scoped keys add another layer of defense. You can generate a key that is allowed only to trade specific markets, only in specific directions, or only up to specific position sizes. Withdrawal addresses are owner-approved only, so the agent can never send funds to itself or an external wallet. If the key is somehow compromised, the attacker can only trade within the narrow scope you defined, and you can revoke the key instantly from the dashboard without touching the underlying wallet.

The panic or kill switch is the final backstop. At any moment, you can flatten all positions and revoke the agent's access with a single action. The API will attempt to close open trades and then disable the key, preventing further submissions. This is useful if the market moves against you, if the agent enters an unexpected loop, or if you simply want to pause for review. You should test the kill switch during paper trading so you know how quickly it executes and what flattening looks like for your chosen market type, whether that means selling shares, closing contracts, or settling positions.

How do you evaluate the agent before going live?

Evaluation is the bridge between paper trading and live capital. Start by reviewing the agent's decision log, which records the model's reasoning and the tool calls it made. Look for instances where the agent ignored a price constraint, repeated the same order after a rejection, or changed its reasoning without new data. These are signals that the prompt or the tool schema needs tightening. How to evaluate taking an AI trading agent live using MCP offers a practical framework for this review and a checklist of red flags.

You should also verify that the agent respects the exit plan you wrote. Suppose you instructed it to sell if the position drops by two percent. Check the paper trading logs to see whether it actually submitted the sell order at the threshold, or whether it invented a justification to hold longer because it predicted a rebound. An agent that rewrites its own rules during execution is not ready for live trading. Fix the prompt, add explicit guardrails in the tool parameters, or reduce the scope of the key until the behavior is strictly predictable.

Run the agent through a stress scenario. Imagine a sudden price spike or a market halt. In paper mode, simulate how the agent responds when an order is rejected or when market data stalls. Does it stop and wait for you, or does it retry aggressively? Unbounded retry loops can burn through budget quickly if the API did not catch them. Make sure the API-level rate limits and position limits are tight enough to catch runaway behavior even if the agent logic fails or the model produces an unexpected plan.

What should you monitor during the first live session?

When you authorize live trading, keep the session short and the budget small. Watch the real-time order log alongside the agent's reasoning trace. The reasoning trace shows you why the agent decided to trade, and the order log shows you what actually reached the market. Any mismatch between the two is a bug. If the agent says it wants to buy one hundred dollars but the order log shows a larger notional value, stop the session immediately and inspect the tool parameters before resuming.

Monitor your open exposure, not just the number of trades. An agent can stay within a trade count limit while building a concentrated position that exceeds your risk tolerance. The API enforces position limits, but you should still watch the portfolio view to see how the agent's allocations drift over time. If you intended a flat, evenly distributed set of positions but the agent is heavily weighted toward one volatile asset, that is a signal to intervene and adjust the prompt or the scope of the key.

Keep the kill switch visible and accessible throughout the session. The first live session is not about maximizing returns; it is about verifying that the system behaves as designed under real market conditions. Trading can lose money, including the entire budget you allocate, so the goal is to confirm safety and consistency before you consider scaling the budget or extending the session length. If anything feels unexpected, flatten, revoke, and return to paper trading. It is better to pause and fix the logic than to let an unproven agent continue operating while you hope for recovery.