$ cat my-build-buy-or-skip-rules-for-mcps.md
My Build, Buy, or Skip Rules for MCPs

Recently, I built two little AI tools and deleted a third before it existed.
I had a non-technical colleague who needed to pull live customer data into his own AI tool but because our current product has limited RBAC controls (Role-Based Access Control) I needed to provide the safe, read-only slice of it. A couple of days later a tool I used announced their MCP and I could use it if I upgraded. Nope, hard pass. Chances are the MCP offered is bloated and that should be table stakes for customers not upselling (I have opinions, ha ha ha). Thus, I built my own version in 30 minutes. And somewhere in the middle of all this, I caught myself about to wire up yet another connector I'd have used maybe twice.
Three decisions. Same shape. I just hadn't noticed the shape until I'd made it enough times.
Quick context for anyone who hasn't gone down this particular road. An MCP is the thing that lets your AI assistant talk to an outside tool. And yes, tech bros are going to be like MCPs are dead, long live CLIs. They aren't entirely wrong about the CLI but MCPs are necessary for those who aren't doing their AI work in the terminal. Think of the MCP as a little bridge. Your email, your newsletter platform, your customer database, they have context and information you want. The AI assistant stands on one side, the tool stands on the other, and the bridge says (MCP) "here are the things you're allowed to do over there."
Bridges are great. The trouble is they're free to add and invisible to count, so you keep adding them, and one day you look up and your AI is dragging 150 tools behind it like a kid who won't take the backpack off at dinner. Thus this post I wrote not so long ago, I counted my MCP tools and, well, yikes.
The rules I have for MCPs, such as they are, run in order.
first, ask what you can remove, not what you can add
The first question isn't "what should I add." It's "what can I get rid of."
During my initial audit, I had 150 tools loaded. Most of them I'd added for one task months ago and never touched again. And every single one costs you something on every request, because the assistant has to read the whole menu before it can do the one thing you asked. It's like opening a recipe app to scramble an egg and the app insists on reading you every recipe it's ever heard of first, including the one in a language you don't speak and the backstory about Becky's free-range chickens. And Becky LOVES to talk about her free-range chickens.
I cut mine from 150 down to about 60, my context window didn't fill as fast, and my sessions got noticeably longer before they choked. So now, before I add a bridge, I count the ones I'm already carrying.
next, ask build, buy, or skip
Once I actually need the thing, there are only a few honest answers.
Use the official one when it's cheap, well looked after, and you use most of what it offers. No notes. Pay the people who build good software.
Build your own lean version when the official one is bloated (you use five tools out of forty) or when someone wants to charge you for a wrapper around an API you already have access to. That second one is exactly what happened with a subscription I use. Their hosted connector lived behind an upgrade button. The underlying API was sitting right there, included in my plan. So I built a five-tool version in a morning instead. The "I'm not technical" argument is harder to make with today's AI tools.
Build a controlled version when you're handing access to someone who isn't going to be reading the code. This was my colleague. They needed live customer data inside their own AI tools, but I did not want a prompt turning into a write against real customer records because it will happen. I know it will happen because it's happened to me even with strict guardrails. Non-deterministic systems are fun, amirite?
So instead of handing them the keys to everything, I built a bridge that only exposes the safe questions in a read only capacity. Things like search if customer exists, recent signups, who needs a follow-up. They get the data. The blast radius stays tiny.
Skip the MCP entirely when it's a one-off. Sometimes the right move is to drop the connector and just call the API directly. Not everything needs to live inside the assistant.
The difference between those four isn't technical. It's about who's using it, how often, and what happens when it goes wrong.
Whatever I build, I keep it thin.
The vendor ships forty tools because they're selling to everybody. I'm building for one person who uses five, so I ship five. Anything I'm not actually using is just weight the assistant has to carry around. (There's a selfish reason too. If I let a tool become A Whole Thing, I will absolutely spend three hours building a control panel for a workflow I have run zero times. One must protect oneself from control planes.)
The most important line isn't in the code. It's the boundary you draw around it.
The assistant can do everything except the one move I can't undo. It can read my subscriber/customer numbers. It can pull up one reader. It can draft content. It cannot send or delete. The draft tool flat-out refuses to schedule anything.
I do not want a model deciding that 9:03 on a Tuesday is a lovely time to send everyone a random announcement or deleting customers from a production database and when I say delete, I mean hard delete.
Read freely. Write carefully. Never automate the thing you can't unsend.
make it work everywhere, or it's just another silo
A bridge that only works in one AI tool or harness is just another silo and vendor lock-in (ewwww, gross).
I move between AI setups. If these bridges only worked in one of them, I'd be right back to copying things between windows, which is the exact problem I was trying to kill in the first place. So I point every setup at the same code.
It's boring config work. Nobody's putting "updated my config files" in a launch video.
None of this is clever which is the point.
The flashy version of AI at work is the keynote about transforming everything. The real version is a person quietly asking the same four questions every time. Do I need this? Who's it for? What happens if it breaks? And where do I keep my own hands on the wheel?
Go build something small!
$ _
LIKED THIS?
I write about AI in plain English every other Sunday. No hype, no jargon — just the stuff that actually helps.
I'M IN →