How to size positions for an AI trading agent using MCP

Position sizing for an AI trading agent using MCP is the process of converting strategy signals into bounded dollar amounts before the agent ever touches a market. The owner defines explicit budgets, per-trade caps, and total exposure limits that the MCP tool layer enforces independently of the agent's reasoning. This means the agent can identify opportunities, but it cannot decide how much of your capital to risk. Those numeric boundaries are set by you, encoded into a scoped key, and validated on every order request.

Why does position sizing matter for MCP trading agents?

Without explicit sizing rules, an AI agent connected to markets through MCP tools would have no inherent sense of proportion. A language model or autonomous system processes signals and generates confidence scores, but confidence is not the same as risk appetite. An agent might interpret a compelling chart pattern or prediction market shift as a reason to deploy a substantial portion of available capital. In manual trading, a human operator implicitly applies personal judgment about account size, recent losses, and other qualitative factors. An agent lacks this judgment unless you replace it with hard numeric constraints. Position sizing is therefore the translation layer between what the agent thinks and what it is permitted to do. It limits the maximum loss per trade, prevents concentration in a single instrument or market type, and ensures the agent operates within a budget that reflects the owner's actual financial tolerance. Trading can lose money, including everything, so these constraints are not optional refinements. They are the primary defense against unbounded autonomous spending. The common position sizing mistakes made by owners often stem from assuming the agent will be conservative by default. It will not. It will be literal. The disconnect between signal generation and capital allocation is one of the most dangerous aspects of autonomous trading. A model might output a recommendation with high confidence, but confidence is a statistical measure, not a monetary one. An eighty percent confidence score does not map to eighty percent of the portfolio. Without a fixed dollar translation, the agent might scale into positions based on the strength of its own reasoning, creating a feedback loop where stronger opinions produce larger bets. This is the opposite of prudent risk management. Prudent risk management requires that bet size is determined by the owner's capacity to absorb loss, not by the agent's enthusiasm for a particular setup. Position sizing rules break this feedback loop. They state that a trade is either within the allowed dollar limit or it is not. The agent's confidence level becomes irrelevant to the quantity executed.

How do you express position size in plain dollars?

Felix normalizes order sizing across stocks, crypto, perpetual futures, options, and prediction markets by using plain US dollars as the universal unit. Instead of forcing the agent to calculate shares, lot sizes, contract multipliers, or token decimals, the owner specifies the desired dollar exposure and the API handles the conversion. This is important because the contract math varies dramatically between market types. An options venue prices contracts in premiums with multipliers. A perps venue uses notional value and margin requirements. A prediction market may quote prices in cents or implied probability. A stock broker uses share counts. Requiring an agent to understand each of these systems simultaneously introduces a significant error surface. By sending orders in dollars, the agent states how much capital it wants to put at risk, and the infrastructure translates that into the correct native format. Consider an agent trading both a stock and an option on the same underlying. The stock is priced in dollars per share. The option is priced in premium per contract, with each contract typically representing one hundred shares. If the agent confuses the two, it might request what it thinks is a five hundred dollar options position and accidentally ask for fifty thousand dollars of notional exposure. By forcing the agent to think only in dollars, Felix removes this ambiguity. The agent requests five hundred dollars of option exposure. The system calculates how many contracts that equals given the current premium and the contract multiplier. Similarly, in perpetual futures, the agent does not need to account for margin ratios or funding rate impacts when stating its desired size. It declares its intended risk in dollars. The infrastructure handles the rest. This separation of concerns is critical for reliability. The agent should reason about markets. The infrastructure should reason about mechanics. The exact request schema is in the docs; the shape looks like this:

{
  "market_type": "perpetual_future",
  "side": "buy",
  "dollar_notional": 500,
  "max_slippage_percent": 2
}

The agent does not need to know the underlying contract size, tick value, or margin schedule. It simply requests a five hundred dollar exposure. The system rejects the request if it violates the scoped key's per-trade limit, regardless of whether the agent meant to send a larger amount. This abstraction removes an entire class of sizing errors, such as decimal place mistakes or confusion between notional value and margin, which are particularly common when agents trade across multiple market types in a single portfolio.

What hard limits prevent an agent from oversizing?

Dollar-based orders solve the unit problem, but they do not automatically solve the cumulative exposure problem. An agent could theoretically send many small orders that add up to a dangerous total position, or it could interpret a sequence of correlated signals as separate opportunities and stack risk unknowingly. The MCP tool layer prevents this by enforcing hard limits that the agent cannot reason around or override. These include a total budget cap that restricts the sum of all deployed capital, a per-trade limit that caps any single order or open position, and often a per-instrument or per-market ceiling to prevent concentration. There is a meaningful difference between telling an agent to be careful and making carelessness impossible. Prompt engineering is not a risk control. An agent might be told to use small position sizes, but depending on the model, the context window, or the tool descriptions, that instruction can be deprioritized in favor of what the agent perceives as a more urgent trading opportunity. Hard limits do not suffer from this ambiguity. They are checked by the MCP server on every call. The server looks at the key, looks at the requested dollar amount, and either permits or denies the action. This is deterministic. It does not depend on the agent's mood, reasoning chain, or interpretation of your instructions. For owners who are not developers, this distinction is important. You do not need to trust the agent's personality. You only need to trust the numbers encoded in the key. The MCP trading tools enforce hard limits at the infrastructure level, below the agent's reasoning. If the agent attempts to size a position at one thousand dollars but the per-trade limit is five hundred dollars, the tool returns an error before the order reaches the market. These limits are bound to the scoped key, not to a prompt or a suggestion. The budget cap also acts as a global brake. Once the agent has deployed its allotted capital, it cannot open new positions until existing ones are closed or the owner raises the cap.

How does a step-by-step sizing flow work in practice?

Suppose you are building an agent to manage a small portfolio across multiple market types. The configuration process follows a clear sequence that separates strategy logic from risk logic. The agent decides what to trade; the sizing layer decides how much it may commit. The following steps create a complete sizing boundary before the agent is allowed to send its first order.

1. 01Set the total budget cap. Decide the maximum dollar amount the agent may have deployed at any time. This cap should reflect money you can afford to lose entirely. It is not a target. It is a damage control boundary.
2. 02Define the per-trade limit. Choose the maximum dollar amount for any single order or open position. This is typically a small fraction of the total budget to avoid concentration. Many owners use a rule such as no more than two percent of the budget cap per trade, but since the API uses dollars, you translate that into a fixed number. Fixed numbers are easier for the tool layer to enforce.
3. 03Add per-market or per-instrument limits. Decide whether the agent may hold multiple positions in correlated assets, and if so, how much each individual position may be worth. Correlation matters. If your agent trades a stock and a prediction market on the same event, the positions may move together. Per-instrument limits prevent this stacking.
4. 04Configure exit rules in dollars. Define stop or take-profit thresholds so the agent knows when to close a position, not merely when to open one. Exit rules are part of sizing because a position that is allowed to grow without bound is effectively a larger size than intended. Dollar-based stops enforce that the exposure never exceeds the planned amount for longer than intended.
5. 05Create and scope the API key. Embed the numeric limits directly into the key. The agent receives only this scoped key, which cannot withdraw funds or alter its own limits. The key is the contract. If the key only permits five hundred dollars per trade, the agent cannot accidentally or deliberately request more.
6. 06Run in paper trading mode. Let the agent operate against live market data with fake money. Verify that it respects the sizing rules when volatility is real. Paper trading reveals whether the agent understands the difference between its signal and its budget. Watch for attempts to resize or average down in ways that violate cumulative limits.
7. 07Authorize live trading explicitly. Only after paper testing confirms consistent behavior should you authorize the key for live markets. Live trading requires explicit owner confirmation. Authorization is a deliberate human action. It ensures that live trading never happens by accident.

This sequence ensures that sizing is not an afterthought. It is built into the infrastructure before the agent ever reasons about a specific trade.

Where do non-custodial controls fit into the sizing decision?

Position sizing limits the speed and magnitude of loss, but non-custodial architecture defines the absolute worst-case boundary. Felix is non-custodial by construction. Funds sit in a wallet that the owner controls. The scoped key allows the agent to spend within pre-approved limits, but it is mathematically incapable of withdrawing funds to itself or changing withdrawal addresses. Withdrawal addresses are owner-approved only. Traditional API keys often carry broad permissions. If you give an agent a standard exchange key, you might be giving it the ability to trade, withdraw, and change account settings. The scoped key in Felix is different. It is constructed so that the permissions are a strict subset. Even if the agent's logic is hijacked by a prompt injection or a flawed reasoning step, the key itself cannot be used to steal funds. This is why sizing and custody must be discussed together. A perfectly sized trade that is drained from the account by a withdrawal instruction defeats the purpose. The non-custodial design means that the sizing limits are the real limits. The agent cannot escape them by moving money out of the account. This means that even if the agent's reasoning is compromised, its sizing logic is bypassed somehow, or market conditions move against every open position, the agent cannot drain the wallet beyond the budget cap. The owner retains ultimate control. The practical checklist for non-custodial MCP trading includes verifying that the key lacks withdrawal permissions and testing the panic kill switch before any live capital is deployed. The kill switch flattens all positions and revokes the scoped key instantly. Sizing and non-custodial architecture work together. Sizing determines how fast the agent can lose the budget it is given. Non-custodial design ensures the agent is never given the entire wallet.

How do you test sizing logic without risking capital?

Paper trading exists for this purpose. The agent connects to the same MCP tools, sees the same live market data, and sends the same requests, but the orders are not executed with real money. This lets you observe whether the agent correctly interprets sizing instructions under actual market conditions. For example, if you set a per-trade limit of two hundred dollars and the agent repeatedly attempts to send five hundred dollar orders in paper mode, you have identified a configuration error before any capital is lost. One common mistake is to treat paper trading as a backtest. It is not. Backtests run on historical data. Paper trading runs on live data with a simulated wallet. The value of paper trading is that it tests the integration between the agent's reasoning, the MCP tool calls, and the API's limit enforcement. You want to see what happens when the agent encounters a rejected order. Does it handle the error gracefully, or does it retry repeatedly? Does it adjust its size downward, or does it crash? These operational behaviors only appear when the system is running. You should also verify that the total budget cap works as expected. If the agent has a two thousand dollar cap and attempts to open a fifth five-hundred-dollar position while the first four are still open, the system should reject it. Watching this happen in paper mode confirms that the arithmetic is correct. You should run the agent long enough to see how it behaves during volatile periods, because market stress often reveals gaps in logic. It is important to remember that paper trading does not guarantee future performance. It only proves that the plumbing works. Once the agent consistently respects the dollar-based limits and the hard caps in paper mode, you can authorize the same scoped key for live trading with confidence that the safety layer is intact.