Can Claude trade for me?
Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs before acting on a number.
Yes — a language model can place orders on your account, if you connect it to an exchange through an MCP server that exposes order-placement tools. Nothing about the model does this on its own; it is a thing you set up deliberately, in about ten minutes, and it is easier to set up than to reason about.
The more useful question is not whether it can. It is what you are actually configuring when you do, and which parts of it you control.
What the setup consists of
Three pieces, and it helps to be precise about which does what.
The model produces text. Among the text it can produce are structured requests to call a tool. It has no network access of its own and no notion of your account.
The MCP server is a program running on your machine that holds your exchange
credentials and exposes a set of named functions — get_balance,
get_positions, place_order — as tools. It is the only component that talks to
the exchange.
The client (Claude Desktop, an IDE, your own application) sits between them. It shows the model which tools exist, passes tool calls to the server, and returns results. Crucially, it also decides whether to ask you first.
The model never touches your account. The server does, on the model’s instruction, subject to whatever the client chooses to enforce.
What it is genuinely good at
Worth stating clearly, because the risk discussion tends to crowd it out: most of the value here has nothing to do with placing orders.
- Summarising exposure across positions in a way your exchange UI does not
- Explaining what a position is doing and why, at a moment when you are not thinking clearly
- Pulling together data from several endpoints into one answer
- Answering “what would it take for this to get uncomfortable” without you opening a spreadsheet
All of this works with read-only tools, carries essentially no risk, and is the part people underrate. If you connect nothing but read access, you get most of the benefit and almost none of the exposure.
What it cannot do
It cannot know what it does not have. If the tools expose spot balances and not futures positions, its answers about your exposure will be confidently incomplete. It does not know the shape of the hole.
It cannot be relied on to follow a limit written as text. A rule in a prompt is a strong input to a probabilistic process. It holds most of the time. The exceptions are unpredictable and correlated with unusual situations, which are the situations where the limit mattered.
It cannot verify its own reasoning. A misread chart and a correct read produce the same kind of confident output.
It cannot undo an order. Nothing can.
The part most people skip
MCP’s specification says this about tools:
“Tools in MCP are designed to be model-controlled, meaning that the language model can discover and invoke tools automatically based on its contextual understanding and the user’s prompts.”
And about safety:
“For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations.”
SHOULD, not MUST. The protocol recommends an approval step and does not
require one, and explicitly leaves the interaction model to implementations.
So whether you are asked before an order goes out is a property of the client
you happen to be using — not something MCP guarantees.
That is worth checking before you assume it.
Five questions to answer before connecting a live key
1. What can this key do if everything else fails? The permission set on the key is the only boundary that does not depend on software behaving correctly. A key that cannot trade cannot be talked into trading by any prompt, bug or mislabeled tool.
2. Which server am I actually running, and whose code is it? Some venues ship their own — Alpaca and OKX publish MCP servers, and IBKR offers a hosted connector. For others, what is widely used is third-party code holding your keys. That is not disqualifying, but it is a different trust decision from installing something a venue published, and worth making knowingly rather than by assuming that a repository named after an exchange came from it.
3. Does my client show me tool inputs before the call? The specification recommends clients “show tool inputs to the user before calling the server”. For an order, the tool inputs are the trade. Seeing them beforehand is the difference between approving a trade and reviewing a receipt.
4. Where do my keys live? In a config file, an environment variable, somewhere else? Does the server log them? Does anything leave the machine? A server that cannot answer these from its README is not one to hand a live key.
5. Have I run it on testnet first? Every parameter mistake you are going to make is cheaper to find there. This is the least interesting item on the list and the one that saves the most money.
A reasonable progression
- Read-only, live account. Real data, no exposure. Most of the value.
- Full tools, testnet. Learn where the mistakes are, on fake money.
- Full tools, live, every order approved. The model drafts, you decide.
- Beyond that — unattended placement — is a different thing with a different risk profile, and it wants limits enforced in code rather than care.
Most people can stop at 1 or 3 and be entirely satisfied.
FAQ
Does Claude place trades by itself?
No. A language model has no access to anything until you connect it to a tool that does. Order placement requires you to install an MCP server, give it your exchange API credentials, and use a key with trading permission. Each of those is a deliberate step. Left alone, the model can talk about markets and nothing else.
Is it safe to connect Claude to my exchange?
Read-only access is low risk and is where most of the usefulness is. Order placement is a different question, and the honest answer is that it depends almost entirely on things other than the model: what the API key is permitted to do, whether the client asks before executing, whether limits are enforced in code, and whether the server holding your keys is trustworthy. Those are the variables worth spending attention on.
What happens if it places the wrong order?
It fills, like any other order. There is no undo and the exchange has no way to distinguish a model-generated request from one you typed — it is signed with your key either way. This asymmetry is the reason approval steps and hard position caps exist, rather than careful prompting.
Do I need to be a programmer to set this up?
Not really, and that is part of the problem. Most servers install with a single command and a config entry. The technical barrier is low; the barrier that matters is understanding what permissions you just granted, and that one is not lowered by the setup being easy.