Exchange and broker MCP servers compared

2026-09-28 · updated 2026-09-30

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.

The first thing to establish when choosing an exchange MCP server is not which has the best tools. It is whose code it is — and the answer varies by venue more than people expect.

The official/community split

Venue	What exists	Published by
Alpaca	`alpacahq/alpaca-mcp-server`	The venue
OKX	`okx/agent-trade-kit`	The venue
Interactive Brokers	Hosted connector at `https://api.ibkr.com/v1/api/mcp-public`	The venue
Binance	`AnalyticAce/binance-mcp-server`, `ethancod1ng/binance-mcp-server`	Community
Bybit	`dlwjdtn535/mcp-bybit-server`, `sammcj/bybit-mcp`, `ethancod1ng/bybit-mcp-server`	Community
Hyperliquid	`edkdev/hyperliquid-mcp`, `alekskram/hyperliquid-agent-gateway`, and several others	Community
Multi-venue	`sydowma/crypto_exchange_mcp`, `vkdnjznd/crypto-trading-mcp`	Community

Repositories and vendor offerings change quickly. Treat this as a map of the landscape rather than a catalogue, and check the current state before installing anything. In particular, the absence of a venue from the official rows means we did not find one — not that none exists.

The trust decision differs between the two halves. Installing something a venue published means the venue has some stake in it handling your credentials correctly. Installing community code means trusting an individual maintainer, which people do constantly and reasonably — but it should be a decision rather than an assumption made because a repository is named after an exchange.

IBKR’s is architecturally different from the rest: a hosted connector rather than software you run. You authorise a single account through IBKR’s own login screen and your credentials never reach the AI platform, with access revocable from Client Portal → Settings → Manage Third-Party Consents. It is not available in IN or JP.

IBKR blocks automated retrieval of its own pages, so the details above come from search summaries of IBKR’s material rather than from pages we read directly. Treat them as directionally reliable and confirm on IBKR’s site.

The venue constraints matter more than the server

A server can only be as convenient as the API beneath it, and those differ enormously. This is usually the deciding factor, not tool coverage.

Alpaca is the smoothest. Two headers, APCA-API-KEY-ID and APCA-API-SECRET-KEY, no request signing, and paper trading at a separate hostname with an identical API specification. No signature construction means an entire category of bug simply does not exist.

Binance, Bybit, OKX all require a computed HMAC signature per request. That is a real source of failure — Binance returns -1022 INVALID_SIGNATURE and -1021 INVALID_TIMESTAMP when it goes wrong, and OKX rejects requests whose timestamp differs from server time by more than 30 seconds. OKX additionally needs a passphrase as a fourth credential alongside key, secret and timestamp, which surprises people arriving from other venues.

Hyperliquid has no API key at all. A master account approves an API wallet (agent wallet) to sign on its behalf, and the docs are explicit that “API wallets are only used to sign” — querying account data requires the master’s actual address. Any server or client assuming a key/secret pair needs to have been built for this.

Interactive Brokers is the hardest by a distance, for structural reasons. The TWS API is a socket to a running desktop application — nothing works unless TWS or IB Gateway is open and logged in. The Client Portal Web API is a separate product with its own local gateway, a self-signed certificate warning at login, and a rate limit of 10 requests/second per authenticated username. And IBKR does not support automated authentication: clients must re-authenticate daily.

That last constraint deserves emphasis. Any “fully automated IBKR agent” plan runs into a daily human login. It is not a gap in the MCP server; it is how IBKR works.

What to evaluate in a server

Ordered by how much it tells you.

1. Is trading off by default? The single best signal. Among the Bybit servers, one requires an explicit TRADING_ENABLED=true before any mutating tool functions, provides READONLY_MODE=true to hard-block mutations, and caps estimated order notional with MAX_ORDER_SIZE_USDT (default 100). Another is read-only by construction and tells you in its README to use a read-only key. A server that arrives fully armed is telling you about its priorities.

2. Can you restrict the tool set? Fewer exposed tools is less surface. Alpaca’s official server supports server-side tool filtering via an ALPACA_TOOLSETS environment variable. This is better than hoping the model does not call something.

3. How are credentials handled? Where read from, ever logged, does anything leave the machine. A README that does not say is asking you to assume.

4. Is there a testnet or paper flag? One Binance community server recommends BINANCE_TESTNET=true for development. Configuration you set once beats a URL you have to remember.

5. Is it maintained, and does it version cleanly? Alpaca’s V2 is a FastMCP/OpenAPI rewrite with no backward compatibility with V1 — tool names, parameters and configuration all changed. That is a healthy sign of active development and a reason to pin a version and read the upgrade notes rather than tracking latest.

6. What does it say about risk? Alpaca’s own documentation warns that the server can place real trades and access the portfolio, that API keys are sensitive credentials, and that LLM-proposed actions should be reviewed carefully — especially complex options or multi-leg trades. A project that tells you what can go wrong has thought about it.

Single-venue or multi-venue

Multi-venue servers exist and are convenient. The trade-offs are the usual ones for abstraction layers: one configuration and one tool vocabulary, against a lowest-common-denominator feature set and one component holding credentials for several accounts.

For a read-only setup the convenience usually wins. For anything that places orders, the blast radius of a single compromised component covering several venues is worth weighing against saving a config file.

Which to start with

Want the least friction → Alpaca. Official server, no signing, paper trading that mirrors live exactly.
Already trade on a specific crypto venue → its community server, read-only key first, and read the README’s credential handling before anything else.
On Hyperliquid → understand the agent wallet model before evaluating any server; the usual key-permission advice does not translate.
On IBKR → budget real setup time and accept the daily re-authentication as a design constraint rather than something to engineer around.

Whatever you pick, the permission on the key does more for you than the choice of server does. A read-only credential makes most of this comparison precautionary.

FAQ

Which venues publish their own MCP server?

Among those reviewed here: Alpaca (alpacahq/alpaca-mcp-server), OKX (okx/agent-trade-kit, under OKX’s own GitHub organisation) and Interactive Brokers (a hosted connector rather than software you run). For Binance, Bybit and Hyperliquid we found only community projects — which means we did not find an official one, not that none exists. Check the venue’s own documentation before concluding either way, and note that a repository named after an exchange does not imply the exchange published it.

Should I avoid community MCP servers?

No, but bound what they can do. Several are thoughtfully built — default-off trading, hard read-only modes, notional caps. The practical approach is to pick one with that posture, pin a version, and give it a key whose permissions you would be comfortable with if the code turned out to be wrong.

Why is Interactive Brokers so much harder than the others?

Because its APIs predate this use case and assume a logged-in human. The TWS API talks to a running desktop application over a local socket, and the Client Portal Gateway requires daily re-authentication with no automated path. Neither is something an MCP server can abstract away.

Does a multi-venue server save time?

For read-only use, usually yes — one setup, one vocabulary. For order placement, weigh it against concentration: a single component holding credentials for several accounts has a larger blast radius, and multi-venue abstractions tend to expose the intersection of venue features rather than the union.