The MCP servers I actually use every day — and the ones I deleted
An honest inventory of my agent setup: which MCP servers earned a permanent place, which got removed within a week, and the one rule that separates them.
I've been running AI coding agents as my main working environment for a while now, and the part that changed the most isn't the model. It's the plumbing around it — the MCP servers that let an agent touch my actual tools instead of just talking about them.
I've installed a lot of them. Most got removed within a week. This is the honest inventory: what stayed, what went, and the pattern that separates the two.
What stayed
My own note system. Everything I read, watch or figure out ends up in one place through a small MCP server I wrote. This is the one I'd miss most, and not because of the writing — because of the reading. When I start a session about a project I haven't touched for a month, the agent pulls its own context instead of me re-explaining it. That's the whole value.
A personal life-data server. Weight, sleep, meals, subscriptions, domains, net worth. It sounds excessive written down. In practice it means questions like "which domains expire in the next two months" or "what did I actually spend on tools this quarter" get answered in one line instead of a spreadsheet expedition.
Project and task management. My own product/task system, exposed over MCP. The agent can see what a project is, what's blocked, and what the acceptance criteria are. Without this, every session starts with me pasting the same context.
A headless CMS. This is the one that surprised me by how much it gets used. Publishing a blog post from the terminal — including translations into four languages, correctly linked — is a five-minute job instead of an afternoon of copy-paste. Every one of my sites now reads its content from it.
Design and browser access. Figma for pulling real component specs instead of guessing, and browser control for the tasks that only exist behind a login. Both are occasional but irreplaceable when needed.
Accounting. Invoices, expenses, subjects. Very boring. Saves an hour every month, which is the correct kind of boring.
What I deleted
Anything that returned huge blobs. This is the number one killer. A server whose "list" call returns every field of every record will blow through the context window on one call and produce nothing usable. I hit exactly this today: a perfectly good CMS listing call returned 330,000 characters because it included the full body of fifty posts. The tool wasn't wrong, it was just designed without thinking about who reads the output.
Anything with forty tools. Large tool surfaces make the agent worse, not better. It spends its attention choosing between near-identical options. The servers I kept expose somewhere between five and twenty focused tools.
Wrappers around things that already have a good CLI. If a tool works well from the shell, an MCP wrapper mostly adds indirection. git, ffmpeg, yt-dlp — I let the agent run them directly.
Anything requiring interactive auth that expires. A server that needs me to re-authenticate in a browser is a server that will be broken exactly when I'm running something unattended.
The pattern
After enough of these, the rule got simple: an MCP server earns its place when it exposes state the agent cannot otherwise see, in small enough pieces to be read.
Both halves matter.
State the agent can't see means my notes, my projects, my numbers, my customers' content. Not documentation — it can search for that. Not commands — it has a shell.
Small enough to be read means the output is designed for a reader with a limited context window. Summaries by default. Details on request. IDs rather than embedded objects. This is exactly the discipline of a well-designed API, and most MCP servers are written as if the consumer had infinite patience.
What I'd tell someone setting this up
Start with one. Pick the system you paste context from most often — for most people that's their notes or their task tracker — and connect that. Live with it for a week before adding a second.
Then watch for the failure mode. When a session goes badly, check whether the agent had to read something enormous to answer a small question. That's a server design problem, not a model problem, and it's fixable: add a parameter, return less, paginate.
And keep the total small. My working setup is under ten servers, and the sessions that go best are the ones where the agent has exactly the access it needs for that task and nothing else.
The interesting shift isn't that agents can write code. It's that they can now see the same systems I see. The quality of what they see is entirely a design decision — and it's mine to get right.