How to build MCP trading tools from first principles

MCP trading tools let an LLM agent call real financial markets through a standard protocol, but the hard part is not the wire format. It is designing a system where an autonomous agent can spend real money without ever being able to steal it, while still handling five different market types through one interface. The Felix API and MCP layer exist to solve that exact problem. They turn an agent's intent into a scoped, non-custodial action that respects hard limits set by the owner.

What is an MCP trading tool and why does it matter for trading?

MCP, or Model Context Protocol, is a standard way for an LLM to discover and call external tools. In trading, those tools are not generic web search or calendar lookups. They are actions that move money. An MCP trading tool is therefore a function exposed to the agent that can read balances, place orders, or check positions, but only within boundaries that the owner defined before the agent started. The reason this matters from first principles is that most financial APIs were built for human clicks or deterministic bots. They assume the caller is either a person with a browser or a fixed script with hardcoded logic. An LLM agent is neither. It reasons in natural language and can generate new plans on the fly. If you give such an agent an unscoped trading API, you are giving it an open ended ability to spend. That is unsafe by default. The correct starting point is to invert the trust model. Instead of asking the agent to behave and hoping it does not overtrade, you build the tools so that the agent literally cannot execute an action that exceeds the owner's budget. The MCP layer becomes a translation and enforcement layer, not just a connector. It takes the agent's intent, validates it against live constraints, and either executes a normalized order or returns a clear refusal. This is the difference between a chatbot that talks about markets and an agent that trades them with real money. Developers building MCP trading tools should think about the tool schema as a contract. Each parameter should have clear bounds. The description fields in the tool definition should remind the agent of the safety model, not just the syntax. For example, a place_order tool should note that the dollar_amount parameter is capped by the owner's budget, so the agent understands that a refusal is not a bug but a boundary. This alignment between the tool's metadata and the underlying enforcement layer reduces confusion and keeps the agent's reasoning grounded.

How does one API normalize five market types?

Stocks, crypto, perpetual futures, options, and prediction markets each have their own conventions for sizing, pricing, and margin. A stock broker might work in whole shares. A perps venue might use contract sizes and leverage tiers. An options venue might quote in premiums and deltas. A prediction market might use binary shares and fees. If the agent had to understand each of these, its prompt context would explode with venue specific math and its error rate would rise. Felix addresses this by sizing every order in plain US dollars. The agent states an intent like allocate two hundred dollars to this outcome or reduce exposure by one hundred dollars. The API normalizes the instruction into the contract math, lot size, or share count required by the underlying venue. The agent never needs to compute leverage, tick size, or notional value. It reasons about risk in dollars, and the system handles the rest. This normalization also applies to reading positions. When the agent asks for its current exposure, it receives a consolidated view denominated in dollars across all five market types. It does not need to parse a stock portfolio, a crypto wallet, a perps margin account, an options greek report, and a prediction market balance separately. The API presents one unified balance and one unified position list. This design choice matters because it keeps the agent's reasoning layer simple. Complex reasoning about edge cases is where LLMs make mistakes. By removing venue specific contract math from the agent's context, you reduce the surface area for hallucinated lot sizes, incorrect leverage assumptions, or misread decimals. How to trade every market type through one API with real money explains the mechanics in more detail. The same normalization applies to order types. A market order, a limit order, and a stop order might have different names and parameter shapes across venues. The MCP tool presents a unified vocabulary. The agent learns one set of terms and one set of constraints. When the API translates the request to the venue, it handles the specific encoding. This means the agent's prompt and tool definitions can remain stable even if the underlying venue changes or if the owner reallocates budget across market types.

Where do safety controls live in the stack?

Safety in MCP trading is not a prompt engineering trick. It is a property of the infrastructure. The Felix system is non-custodial by construction, which means the owner controls the wallet and the agent can only spend within limits that the owner sets. The agent receives a scoped key that can place trades but cannot withdraw funds to itself or any address that the owner has not explicitly approved. Even if the agent's reasoning is hijacked or hallucinates a harmful plan, the key simply does not have permission to steal. The controls are layered. Budget caps set a maximum amount the agent can deploy over a given period. Position limits cap exposure to a single asset or market type. Drawdown limits can trigger automatic flattening if the account loses a predefined amount. Exit plans, such as take profit or stop loss rules, can be attached to orders so that the agent does not need to monitor the market continuously to manage risk. Finally, a panic or kill switch lets the owner flatten every position and revoke the agent's key instantly. These limits are enforced below the agent, at the API level. The agent can request anything within its tool definitions, but the API rejects anything that violates the owner's preapproved constraints. This architecture is what makes it possible to let an LLM trade real money without trusting the LLM. How the safety model for MCP trading tools works from first principles covers the architecture in detail. The owner sets these parameters through a dashboard or CLI before the agent is ever connected. They are not part of the agent's prompt. This separation is critical. If the safety rules were written in natural language inside the agent's context window, a clever prompt injection or a confused reasoning step might convince the agent to ignore them. By moving enforcement to the API and wallet layer, the owner ensures that the limits are cryptographic and financial, not social.

What does a minimal MCP integration look like?

An MCP integration exposes a set of tools to the LLM client, such as Claude or Cursor. The agent discovers these tools at startup, reads their schemas, and can call them during its reasoning loop. A typical toolset might include functions to check balance, place an order, list open positions, or cancel pending trades. When the agent decides to act, it generates a function call. The MCP client forwards it to the Felix MCP server, which validates the request against the owner's safety settings and then routes it to the relevant market. The exact request schema is in the docs; the shape looks like this.

POST /v1/orders
Headers: X-API-Key: YOUR_KEY
Body:
{
  "market": "example-market-id",
  "side": "buy",
  "dollar_amount": 150.00,
  "type": "market"
}

The response returns the executed size, the average fill price, and the post trade balance. If the order would breach a budget cap or position limit, the API returns a 403 with a clear message and the agent sees the refusal. The agent can then adjust its plan or ask the owner for guidance. Developers can also use the REST API directly without an MCP client. The security model is identical. Paper trading exists for testing, and live trading requires the owner to explicitly authorize a key for real money. That authorization step is a deliberate friction point. It ensures that no agent can accidentally slip from simulation to live execution because of a configuration typo.

How should an agent size positions before it trades?

Position sizing is the single most important lever for keeping an agent safe. The agent should not guess its own allocation. Instead, the owner should set hard dollar limits that the agent discovers through its tools. When the agent checks its available budget, it receives a number that already reflects the owner's risk tolerance. The agent then sizes its orders as fractions of that available budget, not as absolute guesses about optimal trade size. This approach is inverted from traditional algorithmic trading. In a fixed bot, the programmer hardcodes the sizing logic. In an agentic system, the programmer exposes the constraints and lets the agent reason within them. The agent might decide to allocate thirty percent of its remaining budget to a new position, or it might decide to hold cash. The key is that the percentage is applied to a ceiling that the owner controls. Sizing in dollars rather than contracts or shares also removes a common source of error. An agent that thinks in contracts might accidentally request a perp position that is ten times larger than intended because it misread the notional multiplier. An agent that thinks in dollars cannot make that mistake. The API handles the conversion. How to size positions for an AI trading agent from first principles provides a deeper walkthrough.

What happens when an agent hits a limit or the market moves?

Markets move, and agents make mistakes. A well designed MCP trading system assumes both will happen and prepares for them at the infrastructure level. If an agent hits a budget cap, the API rejects the order and the agent receives the refusal in its context window. A well prompted agent will interpret this as a signal to stop trading and wait for the owner to reset the cap or for the next budget period to begin. If a position moves against the agent, drawdown limits act as a circuit breaker. When the account equity drops by the predefined amount, the system can flatten positions and lock the key until the owner reviews the situation. This is not a suggestion to the agent. It is a forced exit executed by the safety layer. The panic switch is the final backstop. At any moment, the owner can press a kill switch that flattens all positions across all five market types and revokes the agent's key. The agent does not need to cooperate. The revocation happens in the API layer, below the MCP server. Once revoked, the agent's function calls return authentication errors. It can no longer trade. These guardrails are essential because LLMs are not deterministic. They can loop, hallucinate, or be prompted by unexpected market events into contradictory actions. How guardrails for trading agents break in practice examines the edge cases. The lesson is that safety cannot be left to the agent. It must be enforced by the tools the agent uses. Trading can lose money, including the entire budget allocated to the agent. No safety layer can eliminate market risk. It can only contain the damage to the preapproved limit.