How to size orders in dollars with MCP trading tools

Dollar-based order sizing means an agent expresses trade intent as a plain US dollar amount, and the trading infrastructure translates that amount into the correct number of shares, tokens, or contracts for the specific venue. Through MCP tools, the agent can state a size like five hundred dollars and let the API handle the underlying unit math across stocks, crypto, perpetual futures, options, and prediction markets. This removes the burden of venue-specific contract calculations from the agent and reduces the risk of unit errors that can occur when an LLM attempts to convert notional value into fractional lots or tick sizes. The agent reasons in the currency it shares with its owner, while the infrastructure enforces precise mechanical execution.

What does dollar-based order sizing mean for an agent?

When an agent trades through a traditional API, it often must compute the exact number of base units required to reach a target notional value. On one venue that might mean dividing five hundred dollars by the current price of an asset, then rounding to the nearest tradable increment, then adjusting for minimum order sizes and lot steps. On another venue, the same logic might require an entirely different rounding rule, tick size, or margin calculation. Dollar-based sizing flips this workflow. The agent simply declares a dollar amount, and the infrastructure layer computes the exact mechanical quantity that corresponds to that value at the current market price. This abstraction is not merely a convenience. It is a structural simplification that prevents the agent from needing to understand contract multipliers, decimal precision, or token denominations. Suppose an agent wants to open a two hundred dollar position on a perps venue. It does not need to know whether the venue uses a one dollar tick, a one cent tick, or a hundred dollar lot. It does not need to calculate how many contracts equal two hundred dollars given the current index price and the contract's notional multiplier. It does not need to worry about whether the venue prices the contract in the base asset or in stablecoins. It simply passes two hundred as the size, and the system resolves the rest. This is especially useful when the same agent moves between market types. A stock broker might require whole share quantities for certain instruments, while a crypto venue might allow eight decimal places, and an options venue might quote in contracts that control one hundred underlying units. The agent does not need to maintain a separate sizing module for each environment. It treats every market as a place where capital is deployed in dollars, and the API manages the translation.

Why does normalization across market types matter?

Developers who build agents for a single market often underestimate how much execution logic changes when they expand to a second or third market type. What developers get wrong about using one API for every market is that they assume unit sizing is a trivial layer that can be wrapped with a simple conversion function. In practice, each market type introduces distinct rules for minimums, increments, margin, and settlement currency. A prediction market might quote probabilities in cents that map directly to dollars, but require whole-share increments. A perps venue might use a coin-margined model where the notional value is in dollars but the collateral is in tokens. An options venue might quote premiums per contract, but the contract multiplier means the true dollar exposure is orders of magnitude larger than the premium paid. When an agent must handle all of this internally, the complexity of the prompt or code grows quickly. The agent starts to make errors at the boundaries, especially when it reasons about position sizing in the context of a total portfolio budget. Dollar normalization pushes all of this complexity into the infrastructure. The agent sees a unified interface where every market accepts a size in dollars, and every position reports its value in dollars. This lets the agent focus on strategy and allocation rather than bookkeeping. It also makes audit logs and risk reports easier to read, because every line item is denominated in the same unit the owner understands. When the agent rebalances, it can compare a stock position worth five hundred dollars and a crypto position worth five hundred dollars directly, without converting between shares and tokens in its reasoning loop.

How do MCP tools expose dollar sizing to the agent?

MCP tools present the agent with a structured interface that looks like a function call. The agent does not need to know the underlying HTTP path or the wire format of a specific venue. It sees a tool definition that includes parameters such as market identifier, side, and size in dollars. The exact request schema is in the docs; the shape looks like this:

{
  "tool": "place_order",
  "arguments": {
    "market": "ETH",
    "side": "buy",
    "size_usd": 250,
    "api_key": "YOUR_KEY"
  }
}

The MCP server receives this structured intent, validates it against the scoped permissions and budget limits attached to the key, then converts the dollar amount into the venue-native unit. The agent never sees the conversion math. It does not need to query the venue for tick size, lot size, or current price in order to compute a quantity. The tool schema itself acts as a guardrail by only exposing parameters that are safe for the agent to manipulate. Because the agent is working through MCP rather than raw API calls, the interface can be described in the system prompt or tool documentation in plain language. An AI editor or autonomous loop can discover the tool, read that size_usd expects a plain number representing dollars, and begin placing orders without custom integration code. The agent can also read the current position value in dollars from reporting tools, which lets it compare target allocation against actual allocation without unit translation. This is the difference between giving an agent a calculator and giving it a cashier who handles the register. The agent states what it wants to spend, and the infrastructure handles the mechanical transaction.

Why is it safer than letting the agent calculate units?

Large language models are capable of reasoning about value and direction, but they are not reliable calculators. When an agent is forced to compute order size by dividing a dollar budget by a live price, it can introduce rounding errors, precision loss, or decimal place mistakes. Worse, if the prompt context does not explicitly define the unit conventions for a venue, the agent might confuse notional value with collateral value, or base currency with quote currency. Suppose an agent attempts to buy five hundred dollars worth of an asset but accidentally expresses the quantity as five hundred units. At a price of fifty dollars per unit, that would represent twenty five thousand dollars of exposure. Dollar-based sizing removes this entire failure mode by never asking the agent to perform the conversion. The agent specifies the economic intent, and the infrastructure computes the mechanical reality. This is a key reason why position sizing protects owner funds from agent error. When the sizing logic lives in the API layer rather than the agent's reasoning loop, it can be tested, audited, and updated independently of the agent's strategy. If a venue changes its minimum order size or tick increment, the infrastructure adapts without requiring a change to the agent's prompt or code. The owner retains confidence that the agent's stated dollar intent is what actually reaches the market. This separation of strategy from execution mechanics is one of the core design principles behind a unified trading API.

How do you test dollar sizing without risking capital?

Before an agent trades real money, it should demonstrate that it understands dollar sizing in a sandbox environment. Felix offers paper trading so that owners can observe how an agent translates its strategic intent into dollar-sized orders without market risk. During this phase, you should verify that the agent consistently uses the size_usd parameter correctly and that the resulting simulated positions match your expectations. Suppose the agent decides to allocate ten percent of a one thousand dollar budget to a single trade. You should see a size_usd value of one hundred in the paper logs, not an arbitrary unit count or a hallucinated figure. This is also the right time to test edge cases. See how the agent behaves when a price moves and it wants to rebalance. See whether it attempts to resize positions in dollars or if it drifts into calculating units manually. Running your first trading agent from an AI code editor is often the fastest way to iterate on these behaviors, because you can prompt the agent, observe the tool call, and correct the logic in a tight feedback loop. Only after the agent has demonstrated predictable sizing behavior in paper mode should you authorize a live key. That authorization is an explicit owner action, not an automatic graduation.

What happens if the agent requests an invalid dollar amount?

Even when an agent reasons in dollars, it can still make mistakes. It might request a size that exceeds its scoped budget, or it might attempt a trade below the venue's minimum notional threshold. The MCP infrastructure intercepts these requests before they reach the market. How MCP trading tools enforce hard limits that agents cannot cross explains that the API evaluates every order against the key's preconfigured caps. If the agent asks for ten thousand dollars but the key has a five hundred dollar daily budget, the request is rejected at the infrastructure layer. The agent receives an error and must adapt. Similarly, if the agent asks for a fractional dollar amount below the venue's minimum, the API can round, block, or return a clarifying error rather than forwarding a malformed order. This means the owner does not need to trust the agent to stay within bounds. The trust is shifted to the scoped key and its hard limits. Owners should still monitor logs, because a rejected order stream can signal that the agent's strategy is misaligned with its budget or that the prompt needs adjustment. A panic or kill switch remains available to flatten positions and revoke the key if the agent's behavior degrades. The combination of dollar-based intent, infrastructure-level validation, and owner-controlled revocation creates a stack where the agent has freedom to act but cannot act destructively. Trading can lose money, including everything, so these layers exist to limit the scope of error rather than to guarantee profit.

Frequently asked questions