Build Your Own Brokerage MCP Server, or Use a Product? The Honest Comparison
Last updated August 2026
Short answer
Writing the first version takes an afternoon, and that is what misleads people. The difficulty is not the server, it is the six things that arrive after the demo works: credential storage, token refresh, rate limits, the second broker, deciding what the model may do, and the fact that it never stops needing attention. Build if your broker has a real documented API, you use one account, and read-only is enough. Use a product if you hold accounts at several brokers, your broker has no public API, or you want order placement with guardrails. Walnut is informational and is not an investment adviser.
This is written for someone who can actually build it, so there is no point pretending it is hard. It is not. The comparison that matters is not the first afternoon, it is the distance between something that works on your laptop while you watch it and something you would trust to be right when you are not looking.
Six costs that arrive after the demo works
1. Credentials, stored somewhere real
The prototype keeps an API key in an environment variable, which is fine on your laptop and stops being fine the moment anything runs unattended or anyone else uses it. Encryption at rest, a rotation story, and a revocation path are the actual work, and none of it is interesting.
2. OAuth token refresh
Brokers that use OAuth issue tokens that expire, and the refresh has to happen reliably in the background, survive restarts, and fail in a way you notice. A refresh that silently stops leaves an assistant confidently reporting stale holdings, which is worse than an error.
3. Rate limits and backoff
An assistant will happily call your tools in a loop. Broker APIs will not. You need per-endpoint limits, retry with backoff, and caching of anything that does not change second to second, or you will be throttled at exactly the moment you are demonstrating it to someone.
4. One broker, then the next one
Each broker is its own integration: different auth, different symbols, different position shapes, different pagination, different ideas about what a cost basis is. The second broker costs nearly as much as the first, and the normalisation layer is where the real complexity lives.
5. Deciding what the model is allowed to do
Read-only is a design decision, not a default. If the server can place orders, you need a confirmation step the model cannot forge, limits it cannot argue its way past, and an audit trail. This is the part where a bug is expensive rather than annoying.
6. It never stops
Broker APIs change, tokens get revoked, a symbol format shifts, an endpoint deprecates. A personal integration you maintain is a small permanent tax on your attention, and it fails at the least convenient moment because that is when you are using it.
The fourth is the one that reliably ends these projects. A single-broker server is a clean, satisfying weekend build. A second broker introduces normalisation, and normalisation is where a tidy project becomes a data-modelling exercise about what a position even is, which is considerably less fun than the first afternoon was.
Build it if
| Condition | Why it favours building |
|---|---|
| Your broker has a real, documented API | Alpaca and Interactive Brokers are built for this. Most consumer brokers are not |
| You want tools nobody would ship | A strategy backtest, an internal data source, something specific to how you work |
| It is one account and one broker | The normalisation problem disappears, which is most of the difficulty |
| Read-only is enough | Removes the confirmation, limits and audit work entirely |
| The building is the point | A perfectly good reason, and it should be stated rather than justified on cost |
The last row deserves saying plainly. Wanting to build the thing is a legitimate reason to build it, and it is a better reason than a cost argument that will not survive contact with the maintenance. Projects justified on enjoyment tend to get maintained; projects justified on saving a subscription tend not to.
Get a recommendation for your situation
Walnut is the AI that knows your portfolio: ask anything in plain English, research any fund, and get an honest second opinion. On the broker you already use, read-only, and you approve every trade. Walnut is not a registered investment adviser.
Use a product if
| Condition | Why it favours buying |
|---|---|
| You hold accounts at more than one broker | The normalisation layer is the expensive part and you would be writing it |
| Your broker has no public API | Most consumer brokers do not. An aggregator is the only route in |
| You want it working on your phone | A local server on your laptop is not reachable from anywhere else |
| You want order placement with real guardrails | Confirmation tokens, limits and an audit trail are not weekend work |
| You will not maintain it in six months | The honest question. Most personal integrations decay quietly |
The second row eliminates the choice entirely for most people rather than merely tilting it. Most consumer brokers publish no API at all, so there is nothing to build against, and the only route into those accounts is an aggregator. See connecting a brokerage to an AI assistant.
Side by side
| Dimension | How they differ |
|---|---|
| Time to something working | An afternoon either way. This is not the differentiator anyone thinks it is |
| Time to something you trust unattended | Weeks for DIY, and it is the gap that matters |
| Broker coverage | One per integration you write, versus whatever the aggregator already supports |
| Runs when your laptop is closed | Only if you host it, which is another set of decisions |
| Control over the tools | Total for DIY, and this is the genuine advantage |
| Who fixes it when the broker changes | You, versus someone whose job it is |
Two rows are worth reading together. Time to something working is a tie, and time to something you trust unattended is not close, and almost every comparison of this kind quotes the first while people experience the second.
The split that works
These are not mutually exclusive and treating them as a single decision is the actual mistake. Use a product for the accounts you want available everywhere, including from a phone, and for anything that places an order, because guardrails are the part where a bug costs money rather than time. Then write a small local server for the one broker with a genuinely good API, exposing the unusual tools nobody would ever ship: your own backtest, your own screen, whatever fits how you actually think about your portfolio. That is DIY's real advantage, and it is worth keeping rather than arguing about.
Related: MCP connectors for brokerages compared, and choosing a connector.
FAQ
Should I build my own MCP server for my brokerage?
Build if your broker has a real documented API, you use one account, read-only is enough, and you want tools nobody would ship. Use a product if you hold accounts at several brokers, your broker has no public API, you want it working from your phone, or you want order placement with guardrails.
How hard is it to build a brokerage MCP server?
The first version is genuinely easy, which is what misleads people. An afternoon gets you tools returning positions in a chat window. What takes weeks is everything after the demo: credential storage, token refresh, rate limits, and normalising a second broker that describes positions differently from the first.
What is the hardest part of a DIY brokerage integration?
Normalisation across brokers, and it is why the second one costs nearly as much as the first. Different auth, different symbol conventions, different position shapes, different notions of cost basis. A single-broker server sidesteps this entirely, which is why single-broker projects succeed and multi-broker ones stall.
Can an MCP server place trades?
It can, and that is the point at which a side project acquires real consequences. Doing it responsibly needs a confirmation step the model cannot forge, limits it cannot talk its way past, and an audit trail of what was sent. Read-only removes all of that work and most of the risk.
Which brokers have public APIs for this?
Some brokers are built for programmatic access and document it thoroughly, Alpaca and Interactive Brokers being the usual examples. Most consumer brokers offer nothing public, which is why third-party tools reach them through an aggregator rather than directly, and why a DIY route simply does not exist for those accounts.
Is a DIY MCP server more private?
It can be, since credentials stay on hardware you control and no third party sees your holdings, and that is a real advantage worth weighing. It also means the security of those credentials is entirely your responsibility, which is a meaningful obligation rather than a footnote.
What does a product give me that DIY does not?
Broker coverage you did not have to write, something that runs when your laptop is closed, guardrails around anything that places an order, and someone else fixing it when a broker changes an endpoint. What it does not give you is arbitrary custom tools, which is DIY's genuine advantage.
Can I do both?
Yes, and it is a sensible split. Use a product for the accounts you want visible everywhere and for anything that places an order, and write a small local server for the one broker with a good API where you want unusual tools. The two do not conflict.
Related articles
Walnut is informational and is not an investment adviser, and nothing here is investment advice. Broker API availability and terms change; check the current documentation and terms of service for any broker before building against it.