Using ChatGPT with a trading MCP server
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.
MCP is not a Claude feature. The protocol documentation lists support across Claude, ChatGPT, VS Code, Cursor and others — “build once and integrate everywhere” is the stated design goal, and it largely works.
But there is a structural difference between desktop clients and hosted ones that matters a great deal for trading, and it is not about the model.
Local versus remote servers
Most trading MCP servers are built to run locally. The server process lives on your machine, reads credentials from your environment or a config file, and talks to the exchange from your IP. The client connects to it over a local transport. Nothing is listening on the internet.
This is a genuinely good security posture and most of the advice about trading MCP setups assumes it.
Hosted clients cannot use that. A model running in someone else’s infrastructure cannot reach a process on your laptop, so it needs a remote MCP server — one reachable over the network.
That single change moves the security problem. It is no longer “is this code on my machine trustworthy”. It is “there is a service on the internet that holds exchange credentials and places orders, and the thing standing between it and the world is whatever authentication I put in front of it.”
The warning worth reading twice
Alpaca’s official MCP server documentation addresses this directly:
“This package does not configure remote MCP authentication, so do not expose it directly to the public internet with your Alpaca API keys.”
And notes that Claude Mobile and ChatGPT require remote MCP servers — so the obvious path to using it from a phone is the one it just told you not to take.
This is not Alpaca being unhelpful. It is a local-first tool being honest about the boundary of its design. A server built to run on your laptop does not become safe to host by putting it on a host. The authentication, the transport security, the access logging, the rate limiting against the outside world — none of that is there, and none of it is optional once the thing is reachable.
What a remote setup actually requires
If you are going to do it, the list is longer than people expect:
- Authentication in front of the server. Not obscurity. Not a long URL.
- Transport security, properly terminated.
- Network restriction to the client that should be reaching it.
- Request logging — you now have a component acting on your account that you are not watching.
- Key scope reduced accordingly. A credential on an internet-reachable service should be able to do the minimum the use case needs, and the use case rarely needs order placement.
- Patching and monitoring. It is infrastructure now, with the obligations that come with that.
This is a reasonable amount of work to do well and an easy amount of work to do badly. Done badly, the failure mode is an unauthenticated endpoint that places trades on your account.
The read-only case is different
Most of the above softens considerably if the remote server can only read.
A hosted model that can see your positions and explain them is useful, and a leaked read-only credential is an information disclosure rather than a financial event. If you want ChatGPT looking at your portfolio, this is the version to build: read-only tools, read-only key, and no order path to secure in the first place.
The general principle, which is not specific to ChatGPT: the more remote and less controlled the client, the narrower the credential should be.
Which client asks before it acts
Independent of local versus remote, this is worth establishing per client.
MCP’s specification says:
“For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations.”
SHOULD, not MUST — and the specification explicitly declines to mandate any
interaction model. Whether you get an approval prompt, and whether it shows tool
inputs or only tool names, is a property of the client.
Do not assume it from a different client. Test it with a harmless mutating call on testnet before you assume it from any client.
A reasonable position
- Local client, local server, order tools. Fine, with the usual key permissions and limits.
- Hosted client, remote server, read-only. Reasonable. Narrow the key and keep the order path out of it entirely.
- Hosted client, remote server, order tools. Possible, and it is infrastructure work rather than a config entry. If that framing feels disproportionate to what you were trying to do, that is useful information about whether you want it.
FAQ
Does ChatGPT support MCP?
Yes — MCP’s own documentation lists ChatGPT among the clients that support the protocol, alongside Claude, VS Code and Cursor. The practical constraint is not support but topology: a hosted client needs a remote MCP server, which most trading servers are not built to be.
Can I use a local trading MCP server with ChatGPT?
Generally not, because a hosted model cannot reach a process running on your machine. That is what forces the remote-server question, and with it the authentication and exposure problems that a local setup simply does not have.
Is it safe to host an MCP server with my exchange keys on it?
It can be, with authentication, transport security, network restriction and logging — treated as infrastructure rather than a config entry. What is not safe is taking a server designed to run locally and exposing it as-is. Alpaca’s documentation says outright not to expose its server to the public internet with your API keys, because it ships without remote authentication.
Does the client I use change how safe this is?
Yes, in one specific way: whether an approval step exists, and what it shows. The MCP specification recommends a human be able to deny tool invocations but does not require it, and leaves the interface to implementations. Test your client’s behaviour on testnet rather than assuming it matches another one.