How an AI agent executes orders through MCP

An AI agent executing orders through MCP translates a natural language instruction into a structured, dollar-sized request that a trading API routes to a venue. The owner keeps full custody because the agent can trade within preset limits but cannot withdraw funds to itself or any unapproved address. Safety checks run before the order leaves the system, including budget caps, position limits, and a kill switch that the agent cannot override.

What does MCP do for a trading agent?

MCP stands for Model Context Protocol. It is an open standard that lets a large language model client, such as Claude or Cursor, discover and invoke tools exposed by a server. In the Felix stack, the MCP server offers trading tools that include placing orders, checking balances, reading positions, and fetching market data. When the agent decides to act, it does not write raw HTTP requests or manage API keys. Instead, it emits a natural language intention, and the MCP layer translates that intention into a structured tool call. This separation matters because the LLM reasons about what it wants to do, while the MCP server handles how to express that desire in the exact syntax the trading API expects. The agent never sees secrets; the MCP server holds a scoped key that can trade but cannot withdraw funds. This arrangement keeps the agent’s reasoning surface separate from the authorization surface.

Because the MCP server is the only component that speaks directly to the Felix API, you can swap or upgrade the LLM client without changing the trading logic. The server exposes the same tool definitions whether the agent is running in Claude Desktop, Cursor, or another MCP-compatible client. The tool definitions include descriptions that tell the LLM what each function does, what parameters it accepts, and what constraints apply. For example, a tool description might note that the notional parameter is in US dollars and must not exceed the daily budget cap. The LLM uses this metadata to decide which tool to call and what arguments to pass. If the agent’s reasoning is flawed, the tool schema still enforces valid ranges and required fields, which adds a layer of structural validation before any financial instruction is formed.

That three-layer architecture, LLM reasoning, MCP validation, and API execution, means you can change the underlying model without rewriting the trading code. You can also update the API or add new markets without changing the agent’s instructions. The contract between the agent and the trading world is the tool schema, and the schema is versioned and documented. A trading API built for AI agents covers the design of that interface in more detail.

How does a natural language instruction become an order?

The lifecycle begins with a prompt. The prompt might come from a human, from a scheduled workflow, or from the agent’s own internal loop. The LLM reads the prompt, reviews the available tools, and generates a plan. Suppose the agent receives a prompt that says, 'Deploy half of the free cash into a broad market index fund.' The agent must first check its cash balance using a balance tool, then decide whether the condition is met, and finally call the order tool with the correct side, asset, and notional amount. The MCP server receives the tool call, validates the parameters against its local schema, and forwards it to the Felix API.

The API then performs the safety and normalization layer. It checks that the requested notional fits inside the remaining daily budget and the per-asset position limit. It maps the generic asset identifier to the venue-specific symbol. It converts the dollar amount into the correct number of shares, contracts, or units, accounting for whatever lot size or margin rules the venue requires. The agent does not need to know whether the asset trades in hundred-share lots, decimal sizes, or contract multipliers. How an AI agent executes orders while you keep full custody explains this custody model in more detail.

Once the order passes the safety layer, the API signs the request with the scoped key and sends it to the relevant venue, which might be a stock broker, a crypto exchange, a perps venue, an options venue, or a prediction market. The venue acknowledges the order, assigns an identifier, and returns fill updates. The API normalizes these updates into a standard format so the agent receives the same fill structure regardless of the underlying market type. The agent can then log the fill, update its internal state, or decide to place a follow-up order. Every step is logged, and every failure is returned as a structured error that the agent can, if configured, report back to the owner.

What safety checks run before an order reaches a venue?

Safety is not an afterthought. It is the first gate. Before any tool call reaches the API, the MCP server validates the schema. After that, the API applies the owner-configured policy. The policy includes a hard budget cap, which might be set to a specific daily amount. If the agent has already spent most of that budget, a new large order is rejected immediately. The policy also includes position limits. If the agent is already at its maximum allowed exposure in a single asset, any additional order in that asset is blocked. These limits are enforced by the infrastructure, not by the agent’s reasoning, so a bug or a confused prompt cannot override them.

Withdrawal controls are even stricter. The scoped key attached to the MCP server can place orders and cancel orders, but it cannot move funds to a new wallet. Withdrawal addresses are whitelisted by the owner during setup, and the agent cannot add new addresses. This means that even if the agent were compromised, the worst case is limited to trading losses within the capped budget, not a total loss of the wallet balance. The owner also configures an exit plan, which might include stop-loss rules or time-based flattening. How the safety model for trading agents differs from trading bots covers why this model is stricter than traditional bot permissions.

The final layer is the panic or kill switch. The owner can trigger it at any time through the dashboard or an API call. When activated, the switch flattens all open positions, cancels all pending orders, and revokes the scoped key. The agent cannot read the kill switch state in order to race against it, and it cannot override the revocation. This is a hard break that returns control to the owner instantly. Trading can lose money, including everything, but these controls exist to bound the speed and scale at which that can happen.

How do dollar-sized orders work across different markets?

One of the most confusing parts of multi-market trading is that every venue uses its own sizing language. A stock broker might ask for share quantities. A perps venue might use contract sizes and margin tiers. An options venue uses contracts and multipliers. A prediction market might use outcome shares that sum to one dollar. The Felix API removes this burden from the agent by accepting orders in plain US dollars. When the agent says, 'Buy two hundred and fifty dollars of this asset,' the API translates that amount into the correct venue-native units.

This abstraction is especially important for an LLM because large language models are good at reasoning about dollar amounts and percentages, but they are prone to arithmetic errors when juggling contract multipliers and fractional sizes. By forcing the agent to think in notional dollars, the API prevents mistakes like ordering one hundred times too much because a decimal was misplaced. The API also handles the mapping from a generic asset name to the venue symbol. The agent can refer to an asset by a common name, and the API resolves the exact ticker or contract code required by the venue.

The same dollar-sizing logic applies across all five market types. Whether the agent is trading stocks, crypto spot, perpetual futures, options, or prediction markets, the interface remains consistent. The agent does not need to learn a new order format for each venue. It simply states its intended notional exposure and side, and the API manages the rest. This consistency reduces the surface area for errors and makes it easier to move an agent from paper trading to live trading without rewriting its core logic.

How do you connect an agent through MCP?

Connecting an agent requires installing or running the Felix MCP server and pointing your LLM client at it. The server exposes a tool catalog that the client discovers automatically. You configure the server with a scoped key, which can be authorized for paper trading or live trading. The LLM client then presents the available tools to the agent whenever it forms an intention to trade. The agent does not need to know HTTP paths, authentication headers, or venue identifiers. It only needs to reason about goals and select the right tool.

The exact request schema is in the docs. The shape looks like this. The snippet below shows an illustrative tool call, not an authoritative endpoint definition.

{
  "name": "place_order",
  "arguments": {
    "asset": "EXAMPLE-ASSET",
    "side": "buy",
    "notional_usd": 250,
    "order_type": "market"
  }
}

The server responds with a standardized object containing the order identifier, the requested notional, the estimated filled notional, and the status. The agent can then poll or receive push updates for fills. If the order violates a safety rule, the server returns a structured error that the agent can read and, if instructed, surface to the owner. Because the API is the single integration point, the agent does not need separate credentials for a stock broker, a crypto exchange, or a prediction market. One key and one API grant access to all five market types, provided the owner has authorized each market during key setup. Non-custodial trading for AI agents describes how the custody model works in practice.

What should you monitor after an order is sent?

Execution is only the midpoint. After the order is acknowledged, the owner should monitor fills, position drift, and budget consumption. The API provides a unified dashboard and log stream that normalizes events across all venues. You can see that an agent spent a certain amount on a stock order, opened a perp position with a margin requirement, and sold a prediction market contract, all in one timeline. This visibility is important because an agent can place many orders quickly, and small errors can compound if they are not caught early.

The agent itself can also be programmed to monitor its own state. For example, it can check its current exposure before placing a new trade, or it can read the daily spent budget to decide whether to wait. However, the owner should not rely solely on the agent’s self-policing. The infrastructure-level caps are the real backstop. Review the logs periodically, compare the agent’s intended strategy against its actual fills, and test the kill switch in paper mode so you know it works when you need it.

Remember that trading can lose money, including everything, and no amount of automation removes that risk. Slippage, gaps, and venue downtime can all turn a theoretically sound strategy into a loss. Start with paper trading to observe the full execution path, then move to live trading with a small budget cap. Increase limits only after you have seen consistent, predictable behavior across different market conditions. The goal of the MCP layer is not to guarantee profits, but to give the agent a clear, bounded, and auditable path from intention to execution.