How to set spend caps and drawdown limits for an MCP trading agent

Spend caps and drawdown limits are hard boundaries that prevent an MCP trading agent from deploying more capital than its owner allows. A spend cap restricts the total notional value of orders over a fixed period, while a drawdown limit halts trading when account equity falls by a predefined amount from its peak. These controls are enforced by the API, not by the agent, so the agent cannot override them even if its reasoning changes. Trading can lose money, including the entire amount allocated, and these limits exist to cap that exposure rather than prevent all losses.

When you connect an agent through MCP, you are giving a language model the ability to place orders across stocks, crypto, perpetual futures, options, and prediction markets. The model interprets prompts, market data, and strategy instructions, but it can also misinterpret signals, hallucinate indicators, or loop on a flawed idea. Spend caps and drawdown limits act as external circuit breakers that protect the owner from both market volatility and agent error. Because the API normalizes order sizing into plain US dollars, the limits are intuitive to set and uniform across every venue. The agent does not need to understand contract multipliers, tick sizes, or margin tiers to stay within the budget.

What do spend caps and drawdown limits actually control?

A spend cap is a budget. You declare the maximum dollar amount of notional orders that an API key may send to market over a specific window. The window can be daily, weekly, or limited to a single session. Once the cumulative notional value of executed or open orders reaches the cap, the API rejects any new order from that key. The cap does not distinguish between winning and losing trades. It simply stops the agent from opening new positions once the budget is consumed. The cap also prevents an agent from inadvertently stacking multiple orders that individually look small but collectively exceed the owner's risk tolerance.

A drawdown limit is a stop on the account balance. You set a maximum acceptable decline, either as a percentage or a fixed dollar amount, from a starting balance or from the highest balance reached during the session. If the account equity drops to that level, the API cancels open orders and optionally flattens all positions. The drawdown limit monitors the wallet or account directly, which means it catches losses that a spend cap alone cannot prevent, such as a rapid adverse move in an already open position. A spend cap might allow an agent to open a position, but only the drawdown limit protects the owner if that position immediately moves underwater. why most trading agents still fail at risk management

How do you set a spend cap before an agent starts trading?

You configure the spend cap when you create the scoped API key. The Felix dashboard or REST interface asks for a budget in US dollars and a time period. Because the API expresses all order sizes in dollars, you do not need to convert between shares, coins, contract sizes, prediction market units, or options lot sizes. A cap of five thousand dollars means five thousand dollars of notional exposure across all five market types combined. This normalization removes the risk of unit errors that often plague automated systems. You can think of it as setting an allowance rather than writing code to police the agent.

The cap applies to the gross notional value of orders, not merely the count of trades. If you set a one thousand dollar daily cap and the agent attempts to place a single order for one thousand one hundred dollars, the API rejects the order before it reaches a venue. This prevents one oversized trade from breaching the budget. You can also set a position concentration limit to ensure that no single trade consumes the entire daily allowance. These two controls work together to enforce both total budget and per trade discipline.

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

{
  "key_label": "mcp-agent-session-01",
  "spend_cap_usd": 5000,
  "period": "daily",
  "drawdown_limit_percent": 5,
  "panic_flatten": true
}

This key is then passed to the MCP server, not to the agent directly. The agent reasons about trades and calls the MCP tool, but the tool holds the credentials and enforces the cap. Because the key is scoped, even if the agent asks to increase its own budget or requests a new key, the API will reject the request. Only the owner, using an owner level credential, can modify or revoke the cap. This architecture prevents a compromised or confused agent from escaping its boundaries. The agent may reason about a trade, but the tool decides whether the trade is allowed.

Many developers assume that a language model will naturally respect a budget mentioned in its system prompt. In practice, models can overlook instructions, especially when market conditions create urgency in their reasoning. The spend cap exists because prompts are not guarantees. what most people get wrong about MCP trading tools through a single API explains why infrastructure level enforcement matters more than prompt engineering for safety.

How do you configure a drawdown limit that halts trading?

You define a drawdown limit in the same key configuration panel or API call where you set the spend cap. You specify either a percentage decline from the session high watermark or a fixed dollar decline from the starting balance. Suppose you allocate twenty thousand dollars and set a five percent drawdown limit. If the account equity falls to nineteen thousand dollars, the system intervenes. The intervention can be as simple as rejecting new orders, or as aggressive as flattening all open positions and revoking the key until the owner resets it. You can also combine the drawdown limit with a time based exit plan that closes positions at a scheduled hour regardless of profit or loss.

The limit is evaluated continuously against the account equity or wallet balance, not just at the end of a trade. In fast moving markets, such as perpetual futures or options, the mark price can change between the agent's reasoning step and its execution step. The API monitors the equity independently of the agent's loop. If the threshold is breached during a spike, the safety system acts immediately. This independence is critical because an agent relying on MCP may have several seconds of latency between observation and action.

You should calibrate the drawdown limit to the expected volatility of the strategy. A mean reversion strategy that holds positions for minutes might need a tighter limit than a macro trend strategy that holds for weeks. The limit should be a hard stop that you are willing to accept as the worst case for a single session. Once triggered, the agent cannot resume trading until the owner explicitly authorizes a new session or key. This prevents the common failure mode where an agent doubles down after losses to recover. practical checklist for non-custodial MCP trading

What happens when an agent hits a safety boundary?

When the spend cap is reached, the API returns an error to the MCP tool, which forwards it to the agent. The agent may log the event, notify the owner through a webhook, or simply idle. The exact behavior depends on how the developer wired the MCP client. The important part is that no new orders reach any venue. Existing positions remain open unless a separate exit plan or the drawdown limit forces them closed. The owner retains full visibility into which orders consumed the budget and when the cap was reached. The API tracks cumulative notional exposure in real time, so the cap is always current.

When a drawdown limit triggers, the response depends on the configuration chosen at key creation. If panic flatten is enabled, the API sends exit orders to close all positions across stocks, crypto, perps, options, and prediction markets. The API handles the venue specific math, so the agent does not need to compute contract sizes, decimal places, or margin requirements. The exit plan runs without agent consent, which protects the owner when the agent is stuck in a reasoning loop or repeating a losing pattern. The key may then be revoked automatically to prevent any further activity.

After a boundary event, the owner should review the session logs before reauthorizing the agent. The API provides an audit trail of every order, fill, and safety event. You can see exactly which trades consumed the spend cap and which market move caused the drawdown. This transparency is a feature of the non-custodial model. The owner controls the wallet, the API enforces the limits, and the logs show precisely where the boundary was crossed.

How do you test caps and limits without risking real money?

You should never validate safety boundaries in a live market for the first time. Felix provides a paper trading mode that mirrors the live API behavior, including the enforcement of spend caps and drawdown limits. When you create a paper key, you set the same parameters you intend for live trading. The agent trades against simulated market data and simulated fills. The API returns the same error codes and boundary events as it would in production. This lets you confirm that the agent handles budget exhaustion and drawdown halts correctly. Paper mode is available for all five market types, so you can test a multi asset strategy safely.

To test thoroughly, run a full paper session with the same strategy and prompts you plan to use live. Monitor whether the spend cap blocks orders at exactly the threshold you set. Simulate a market decline to see if the drawdown limit triggers at the correct equity level and whether the panic flatten closes positions as expected. If the agent is supposed to pause and notify the owner, verify that the notification path works. Adjust the cap size, drawdown percentage, or exit plan based on what you observe. Only authorize a live key after the paper session behaves exactly as intended.

Paper trading validates the plumbing of your safety controls, but it does not predict profitability or guarantee that live markets will behave identically. Slippage, liquidity gaps, and partial fills in real markets can alter outcomes. The purpose of the test is to prove that the agent cannot bypass the spend cap or drawdown limit, not to forecast returns. how developers can backtest AI trading strategies before going live offers additional guidance on separating safety verification from strategy validation.

Why are these controls considered non-custodial?

Non-custodial means the agent never takes possession of the owner's funds. The wallet remains under the owner's private key, and the scoped API key only permits order placement within the defined limits. The agent cannot withdraw funds, change withdrawal addresses, or alter its own budget. Even if the MCP server were compromised or the agent were tricked into malicious behavior, the attacker could only place trades within the spend cap. The drawdown limit would still halt activity if those trades caused equity to fall. The owner can revoke the key at any moment from the dashboard, cutting off access without needing to move funds.

Spend caps and drawdown limits reinforce this architecture by adding programmable constraints to the key itself. The owner sets them at creation time, and they are enforced by the API infrastructure, not by a prompt that the agent might ignore. This separation of concerns is deliberate. The owner controls the funds, the API controls access, and the agent controls strategy. When any layer fails, the other layers contain the damage. That containment is the core of non-custodial agentic trading. These controls are not optional extras. They are the foundation that makes it safe to hand an API key to an autonomous reasoning system.

Configuring spend caps and drawdown limits is not a one time task. As market conditions change and strategies evolve, you should revisit these boundaries. A cap that felt conservative in a low volatility regime may become too tight or too loose after a shift in the market. Regular review of the audit trail helps you decide whether to tighten the drawdown limit or increase the spend cap for the next session. The goal is to keep the agent productive while ensuring that a single session cannot damage the overall portfolio.