How to avoid common mistakes when using an LLM trading agent with MCP

LLM-powered trading agents connected through MCP make predictable mistakes that cost money. You avoid them by treating the agent as a non-deterministic reasoning layer, not a deterministic script, and by enforcing hard infrastructure limits that the model cannot override. The most common errors come from vague prompts, ambiguous tool descriptions, skipped paper testing, and relying on natural language for safety. Understanding these failure modes before deploying an agent is essential, because the convenience of MCP also makes it easy to act on a misunderstanding at machine speed.

Why do LLM agents make different mistakes than traditional bots?

Traditional trading bots execute deterministic instructions written in code. If the logic is flawed, the flaw is repeatable and usually visible in a backtest. LLM agents, by contrast, reason over natural language and probabilistically select tools from an MCP server. The same prompt can produce different actions on different days, depending on how the model interprets market context, tool descriptions, and its own prior outputs in the conversation. This means the class of errors is semantic rather than syntactic. A bot might place an order for the wrong symbol because of a string mismatch. An LLM agent might choose the wrong symbol because it reasoned that a particular asset was the best expression of a vague instruction like 'the most volatile tech name today.' It might also hallucinate a parameter, such as inventing a ticker that does not exist, or misreading a tool output and building a plan on false data. The non-determinism is not a bug in the model; it is a property of the architecture. Treating an LLM agent like a deterministic script is the first mistake. Developers should expect variability and design their controls to catch reasoning errors, not just code errors.

How can a vague prompt cause an unintended order?

Natural language is imprecise, and LLMs interpret instructions literally within the bounds of their training. A prompt that says 'buy a small amount when the market drops' leaves three variables undefined: the asset, the threshold for a drop, and the definition of small. One day the agent might interpret a two percent decline as a drop and allocate ten dollars. Another day it might interpret a half percent decline as sufficient and allocate one thousand dollars. If the prompt is part of a longer conversation, the model may also use earlier context that the developer forgot about, effectively changing the instruction set without warning. Another common issue is giving the agent a goal without constraints. Telling an agent to 'maximize returns this week' without specifying a budget, allowed markets, or leverage limits invites the model to reason its way into high-risk instruments. It does not understand risk the way a human trader does. It understands patterns in language, and the language of high returns often correlates with the language of high risk in the training data. Precise prompts help, but they are not sufficient by themselves. The only reliable way to prevent an unintended order is to combine precise instructions with infrastructure-level limits that the agent cannot override, such as a hard cap on the dollar value of any single order.

How does an ambiguous tool description lead to the wrong market?

An MCP server exposes tools to the model, and the model chooses which tool to call based on their names and descriptions. If the description for a stock trading tool and a perps trading tool are both summarized as 'execute a trade,' the model may select the wrong one. The agent does not know that perpetual futures carry funding rates or that options have expiration dates unless that information is present in the tool schema or the prompt. A developer might assume the model understands finance, but the model understands text. Suppose a tool named 'execute_market_order' is available for both a stock broker and a perps venue. The model might route an order intended for a spot equity position to a leveraged perpetual contract because the tool description did not explicitly distinguish the underlying market type. The consequences include unexpected leverage, different fee structures, and exposure to funding costs that the developer never intended. To reduce this risk, tool descriptions should be explicit about market type, instrument behavior, and required parameters. The Felix API normalizes order sizing in plain US dollars across all five market types, which removes one source of confusion, but the model still needs to know which tool corresponds to which market. Clear naming conventions and detailed descriptions in the MCP tool manifest are the developer's responsibility. Never assume the model will infer financial semantics from a terse label.

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

{
  "api_key": "YOUR_KEY",
  "market_type": "stock",
  "spend": 500,
  "side": "buy",
  "symbol": "EXAMPLE"
}

Why should paper trading be mandatory before live execution?

Paper trading exists so that an agent's entire decision loop can be observed without risking capital. Many developers test individual API calls in isolation and assume the agent will behave correctly when those calls are chained together by an LLM. That assumption is dangerous. The transition from reasoning to action is where most LLM agent failures occur. In paper mode, you can watch the agent plan a trade, select a tool, populate parameters, and submit an order. You can verify that it respects the budget cap, that it does not double-submit orders when market data updates, and that it handles errors gracefully. Paper trading also reveals whether the agent is anchoring on stale information. If the MCP server returns a cached price and the agent reasons from it, the mistake is visible in the logs before it costs money. Felix requires explicit owner authorization before a key can access live markets, but the authorization step should only happen after a successful paper trading period. How to take an AI trading agent live with MCP covers the transition process, and How to backtest AI trading strategies before using real money explains why observing behavior under realistic conditions matters even when no code is being backtested in the traditional sense. Skipping paper trading is a mistake because it removes the only opportunity to see the agent fail for free. It is also the only way to observe how the agent behaves when a market moves sharply, because sharp moves often trigger unexpected reasoning chains in the model.

Why must safety controls live outside the prompt?

Developers often try to control an agent by writing detailed safety instructions into the system prompt. They might include rules like 'never spend more than one hundred dollars per trade' or 'only trade stocks.' This is a mistake. An LLM can ignore, misinterpret, or hallucinate past these instructions. The only safe controls are those enforced by the infrastructure, not described in natural language. Felix uses scoped API keys, budget caps, position limits, and owner-approved withdrawal addresses to enforce boundaries that the agent cannot negotiate. The model can request a trade, but if the request violates a hard limit, the API rejects it. This is the difference between a suggestion and a constraint. How non-custodial trading keeps your money safe when an AI agent trades describes the custody model, and How to control the risks of non-custodial trading with real money details the specific controls available. Relying on prompts for safety is like relying on a conversation to lock a door. The lock must be physical. Even a well-intentioned model can make an error when context length grows or when it is asked to reason across multiple conflicting instructions. The prompt is the start of the process, not the end of it.

How do hard limits prevent catastrophic losses?

Hard limits are the final expression of the principle that the agent should be able to act within boundaries but never redefine them. A spend cap prevents the agent from draining an account, even if it repeatedly attempts to trade. A position limit prevents concentration in a single instrument, even if the model becomes convinced that one asset is an opportunity. Market scoping on the API key prevents the agent from accessing instruments that the owner never intended to trade, such as options or perps, if the owner only authorized stocks. Order sizing in plain US dollars removes an entire category of contract-math errors that occur when developers manually calculate lot sizes, multipliers, or notional values. Suppose an agent misreads a price feed and thinks an asset is trading at one dollar instead of one hundred dollars. Without a hard limit, it might request a position that it believes is five hundred dollars but is actually fifty thousand. A spend cap set at five hundred dollars would cause the API to reject the order regardless of the agent's reasoning. These limits are not training wheels. They are permanent guardrails that remain in place for the lifetime of the agent. They protect against bugs, hallucinations, and unexpected market conditions with equal force. The owner should set them conservatively and review them regularly, because an agent that starts with a small budget can still cause disproportionate harm if the limits are loosened without cause.

How do you verify a kill switch before going live?

A kill switch that flattens positions and revokes the scoped API key is the last line of defense, but an untested switch is only theoretical. The time to discover that revocation fails is not during a market crash. The verification process should be performed in paper trading mode first. Trigger the switch manually, observe that open orders are canceled, positions are flattened, and the key is revoked. Then confirm that the agent cannot place new orders until the owner explicitly re-authorizes the key. After that test succeeds, repeat the process with a small live position to ensure that real-world latency and venue behavior do not break the sequence. The key insight is that revocation must be instant and irreversible from the agent's perspective. If there is any delay, or if the agent retains a cached session that allows further requests, the switch is not a switch. It is a suggestion. Testing it is not paranoid. It is the minimum standard for any autonomous system that can move real money. You should also verify that the owner notification channel works, because a silent kill switch is less useful than one that tells you why it fired. The test should be documented and repeated whenever the MCP server or agent configuration changes.

What are the most common mistakes to review before deploying?

• ·Treating the LLM as a deterministic script instead of a reasoning layer.
• ·Writing vague prompts that leave asset selection, sizing, or timing undefined.
• ·Copying generic tool descriptions that do not distinguish market types.
• ·Skipping paper trading and going straight to live authorization.
• ·Relying on system prompts for safety instead of hard infrastructure limits.
• ·Failing to test the kill switch before capital is at risk.

These mistakes are not exotic edge cases. They appear in nearly every project where a developer connects an LLM to a trading API for the first time. The underlying theme is that the developer assumes the model understands intent, when it only understands text. Correcting this assumption early prevents most downstream failures.

Trading with an LLM agent through MCP is not inherently dangerous, but it is inherently different from writing a script. Trading can lose money, including everything, and an autonomous agent does not reduce that risk. The mistakes described above are common because they map human intuitions about instructions onto a system that does not share those intuitions. An LLM does not know what you mean; it knows what you wrote. Bridging that gap requires precise prompts, explicit tool descriptions, thorough paper testing, and hard infrastructure limits that do not depend on the model's cooperation. Every layer of control you add reduces the probability of a costly misunderstanding. The goal is not to prevent the agent from acting; it is to prevent it from acting outside the boundaries you set. That is the difference between an experiment and a disaster.