Why AI agents use MCP to manage dollar-based order sizing

AI agents trade most naturally when they reason about money in plain dollars rather than in contracts, lots, or base currency units. MCP allows the agent to express buy or sell intent as simple dollar amounts, while the Felix API translates those amounts into the correct native sizes for each venue. This separation lets the agent focus on strategy and risk, and it prevents an entire class of sizing errors that come from asking a language model to perform contract math.

Why do AI agents think in dollars instead of contracts?

Every trading venue speaks in its own native units. A perps venue measures positions in coin sizes and applies leverage multipliers. An options venue counts contracts, each with its own multiplier. A stock broker counts whole and fractional shares. A prediction market uses outcome shares that trade between zero and one dollars. Forcing an agent to learn each dialect creates friction, hallucination risk, and subtle errors. A language model might confuse the number of contracts with the notional value, or it might miscalculate the base currency equivalent when leverage is applied. A human trader might know that ten shares of a five hundred dollar stock is not the same risk as ten contracts of an out-of-the-money option, but a language model lacks that intuition unless it is explicitly given the full contract specification. Those specifications change, they vary by venue, and they often include edge cases such as fractional share availability or minimum lot sizes. By removing the need for the agent to parse these rules, dollar sizing reduces the prompt complexity and the chance of a hallucinated multiplier. When the agent thinks in dollars, it can state a simple instruction like allocate two hundred dollars to this position and let the infrastructure handle the conversion. This is especially important for agents that operate across multiple market types in a single session. The agent's internal logic can compare a fifty dollar stock position against a fifty dollar perps position as equal risk, even though the native units differ by orders of magnitude. Dollar normalization keeps the portfolio model coherent and makes cross-market rebalancing intuitive. The owner defines the total budget in dollars, the agent allocates in dollars, and the API translates at the edge. No part of this workflow requires the agent to know that a single options contract represents one hundred underlying shares, or that a crypto perpetual uses a different base unit than its spot equivalent. The agent reasons about exposure, and the system reasons about contracts.

How does MCP make dollar reasoning natural?

MCP exposes trading tools to the agent as a simple, discoverable schema. The agent does not need to know HTTP paths, authentication headers, or venue idiosyncrasies. It sees a function such as place_order with a parameter for amount_usd. Because the interface is plain, the agent can generate dollar values from natural language prompts such as reduce exposure by one hundred dollars or double the position to four hundred dollars. The protocol carries the context of prior trades, open positions, and current prices, so the agent can adjust sizing dynamically without maintaining a separate state machine. This is a sharp difference from traditional bots, which are hard-coded to specific contract formats and require manual recoding when a venue changes its minimum lot size. How AI trading agents differ from bots and why MCP matters

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

{
  "symbol": "BTC",
  "side": "buy",
  "amount_usd": 250,
  "order_type": "market"
}

The agent does not need to calculate how many coins two hundred and fifty dollars represents at the current price, nor does it need to format the quantity in the venue's native precision. The API performs that conversion after checking the dollar amount against the scoped key limits. This means the agent's prompt can stay focused on strategy and narrative, not on arithmetic. When the agent wants to scale in, it can simply halve or double the amount_usd parameter. When it wants to exit, it can specify a target dollar value to realize, rather than guessing at slippage and contract granularity. The simplicity reduces the surface area for errors.

What keeps dollar sizing safe across five market types?

Safety lives in two layers. The strategy layer decides how many dollars to deploy. The infrastructure layer enforces whether that dollar amount is allowed. Felix applies this by letting owners set budget caps, per-trade maximums, and position limits in plain US dollars. These limits sit in the key scope, not in the agent's prompt, so the agent cannot talk its way around them. If the agent requests a trade that exceeds the cap, the API rejects it before any venue sees the order. This is true whether the agent is trading stocks, crypto, perps, options, or prediction markets. The dollar limit is universal. Owners can also set time-based budgets, such as one thousand dollars per day or ten thousand dollars per month, which are independent of the market type. This means an agent trading both stocks and crypto from the same key cannot evade a daily limit by switching to a different market. The API aggregates all dollar requests against the same cap. This unified accounting is only possible because every order is normalized to the same unit before enforcement. How to set guardrails for a trading agent

Non-custodial architecture reinforces this boundary. Funds sit in a wallet the owner controls. The agent can spend within its scoped limits but can never withdraw funds to itself or an unapproved address. Withdrawal addresses are owner-approved only. A panic switch lets the owner flatten positions and revoke the key instantly. Scoped keys mean that even if the agent's reasoning goes awry, the maximum damage is bounded by the dollar cap assigned to that key. A practical checklist for scoped API keys for beginner trading agents

The normalization logic also protects against accidental overexposure. Because the API converts dollars to native units, it can enforce minimum and maximum order sizes on a per-venue basis without exposing that complexity to the agent. If an agent tries to place a two dollar order in a market where the minimum is ten dollars, the API returns a clear error and the agent can adjust. The agent remains in the dollar abstraction, but the system enforces reality at the edge.

When should an agent change its dollar size mid-session?

An agent should adjust dollar sizing when the market structure or its own portfolio state changes. Suppose the agent detects rising volatility in a perps market. It might want to halve new order sizes from two hundred dollars to one hundred dollars to keep expected risk constant. Or imagine the agent has hit a drawdown limit of five percent on its allocated budget. It should reduce sizing until the strategy recovers. Correlation is another trigger. If two positions that were previously uncorrelated start moving together, the agent might trim each by a fixed dollar amount to avoid doubling up on the same macro risk. These decisions belong to the agent's strategy, but they are expressed in the same simple dollar terms. How AI agents size positions when trading real money across markets

Another common trigger is a shift in the agent's confidence score. If the agent uses a prediction model to score trade setups, it might map that score directly to a dollar range. A high conviction signal gets four hundred dollars, a medium signal gets two hundred dollars, and a low signal gets skipped entirely. This mapping is trivial to express in natural language and trivial to audit. The owner can read the reasoning trace and see exactly why the agent chose four hundred dollars instead of two hundred. Because the API handles the translation, there is no risk that the agent's confidence score gets multiplied by the wrong contract multiplier.

The API does not need to know why the agent changed its mind. It only checks that the new dollar amount is within scope and then converts it. This separation of concerns is deliberate. The agent handles the narrative and the model. The infrastructure handles the math and the safety. If the agent decides to increase size after a winning streak, the owner-approved guardrails still apply. A position limit of five hundred dollars per asset means the agent cannot override its own constraint simply because it feels confident. The dollar abstraction makes this easy to audit. An owner can read the agent's reasoning trace and see exactly where it decided to cut one hundred dollars from a position. That trace maps directly to the API call, with no hidden conversion steps.

How do developers test dollar sizing before going live?

Felix offers paper trading so that dollar amounts can be validated without real capital at risk. A developer can run the agent against live prices with a paper key, observe whether the agent respects dollar budgets, and verify that the API converts sizes correctly across market types. The paper environment uses the same MCP tool schema and the same API responses as live trading, so behavior in testing is representative of behavior in production. When the agent consistently places one hundred dollar orders, respects a five hundred dollar budget cap, and handles rejection errors gracefully, the developer can be confident in the logic.

Transitioning to live trading requires explicit owner authorization. The agent does not automatically graduate from paper to real money. The owner must create a new scoped key with live privileges, set fresh dollar limits, and authorize the connection. This deliberate step prevents accidental deployment. During the first live sessions, many developers keep tight limits, such as a twenty dollar per-trade cap and a one hundred dollar total budget, while they observe the agent in real market conditions.

Developers should also test edge cases. What happens when the agent tries to place a one dollar order in a market with a ten dollar minimum? Does it catch the error and retry, or does it halt? What happens when a position grows due to market movement and exceeds the dollar cap? The paper environment lets the developer observe these scenarios without financial consequence. Logging and audit trails in the paper environment mirror the live environment, so the developer can practice reading the agent's decision chain and the API's enforcement chain side by side.

It is worth stating plainly that trading can lose money, including the entire budget allocated to an agent. Paper trading cannot capture every real-world condition, such as sudden liquidity gaps or slippage in fast markets. Dollar sizing helps manage risk, but it does not eliminate it. The agent might follow its strategy perfectly and still lose. That is why the panic switch and kill switch exist. They are not optional extras. They are part of the safety architecture that makes agentic trading viable.