What is an exchange MCP server?
An exchange MCP server is an adapter that exposes an exchange’s API as a set of tools a language model can call. Instead of you reading a chart and typing an order, the model asks the server for balances, prices or open positions — and, if the server exposes those tools, tells it to place and cancel orders.
The Model Context Protocol is a general standard for connecting models to external tools and data. An exchange MCP server is one implementation of it: the “tools” happen to be your trading account.
Why this suddenly matters
For most of the last decade, connecting an LLM to a broker meant writing glue code. You handled auth, you decided which endpoints to expose, you wrote the parsing, and every decision about what the model could reach was one you made explicitly, in code you had read.
MCP removes that work — which is the appeal, and also the problem. Installing a server is a config entry. The set of actions the model can take is now decided by whoever wrote that server, and the default is not always the conservative one. The gap between “the model can see my portfolio” and “the model can liquidate my portfolio” is a permission flag, and it is not always yours.
What a server typically exposes
Servers differ, but the tools tend to fall into three tiers:
| Tier | Example tools | What a mistake costs |
|---|---|---|
| Read-only | balances, positions, order history, prices | Nothing directly — but it is still your account data going into a model’s context |
| Order management | cancel order, amend order | Recoverable, though a wrongly cancelled stop can leave a position unprotected |
| Order placement | market order, limit order, close position | Real money, immediately, and there is no undo |
The first two are genuinely useful and comparatively safe. The third is where the interesting failure modes live.
The three failure modes worth understanding
A tool call is not a decision. When a model calls place_order, nothing
about that call reflects deliberation. It is a token sequence that matched a
pattern. It can be triggered by a misread chart, an ambiguous instruction, or
text the model encountered in its context that looked like a command. The
exchange cannot tell the difference between a well-reasoned order and a
hallucinated one — both arrive as a signed API request.
Parameters go wrong in ways that are hard to see. A quantity off by a decimal place, a side flipped, a price in the wrong units, a stop submitted as a limit. Each looks entirely plausible in a tool-call log. You will notice the consequences before you notice the parameter.
Context is an attack surface. If the model reads anything you did not write — a news page, a scraped forum, another tool’s output — that text sits in the same context as its instructions. A model with order-placement tools and an untrusted input source is a combination that deserves more caution than it usually gets.
Where the boundary should sit
The useful question is not “is this safe” but “what cannot happen regardless of what the model outputs”. A few boundaries are worth setting deliberately:
- Use a trade-only key with withdrawals disabled. This is the one that bounds the worst case. Whatever else goes wrong, funds cannot leave the account.
- Start read-only. Most of the value of connecting a model to an exchange is in reading — summarising positions, checking exposure, explaining why a setup looks the way it does. Order placement is a separate decision, and it can come later or never.
- Practise on testnet first. Every parameter mistake you are going to make is cheaper to discover there.
- Keep risk limits out of the prompt. A daily-loss limit written as an instruction is a suggestion; the model can reason its way around it, or simply not attend to it. The same limit written as a function that rejects the order is a limit.
- Put approval between the plan and the order. If a human sees direction, entry, stop and size before anything is submitted, none of the three failure modes above reaches the exchange.
That last point is the whole design argument for a workbench sitting between the model and the venue, rather than wiring them directly together. The model still does the reading and the drafting — that part is genuinely useful. What changes is that its output is a proposal rather than an action, and the limits around it are code rather than text.
FAQ
Is an MCP server the same thing as a trading bot?
No. A trading bot runs a strategy you defined, deterministically, on rules you wrote. An MCP server exposes capability to a model that decides what to do in the moment. A bot does the same wrong thing predictably; a model does a different wrong thing each time. They fail in different ways and are worth evaluating separately.
Can I use one without letting the model place orders?
Yes, and for most people this is the sensible starting point. If the server exposes trading tools you do not want, either configure them off or use an API key without trading permission — the key is the boundary you control, and it does not depend on the server behaving as documented.
Where do my API keys end up?
That depends entirely on the server, which is why it is worth checking before installing. At minimum, find out whether keys are read from your environment or stored in a file, whether they are ever written to logs, and whether anything leaves your machine. A server that cannot answer those three questions from its README is not one to hand a live key.
Does the exchange know an order came from a model?
No. The request is signed with your key and is indistinguishable from one you placed by hand. The account is yours and so is the fill — which is the reason the boundary has to exist on your side.
Related
- Read-only vs trade permission on an API key
- Why MCP needs an approval layer
- Size the trade before you place it: position size calculator