Why MCPs Don't Scale with Heavy Agent Herding
How I'm getting fewer interrupted Claude Code sessions
Published 2026-05-16 by Fredrik Wollsén
MCP is my biggest headache with Claude Code right now. I have several MCP servers wired up for various integrations, and I'm planning to remove most of them.
Here's why.
The disconnect
Something goes wrong with the underlying process, or the network, or whatever — and the MCP server disconnects. Claude Code can't auto-recover. The only way to get it back is to open the /mcp menu and reconnect manually, or restart Claude Code entirely.
That's a buzzkill for every automated session.
It happens a lot. The worst offender is browser automation. A close second is a custom MCP server I built for work. Both of them disconnect often enough that I can't trust them to be there across a long agentic run.
Per-tab process spawning
It gets worse when I have many Claude Code tabs open. From what I can tell, each tab spawns its own copy of every MCP server I've configured. So if I'm running ten sessions in parallel, that's ten copies of each MCP server running. For browser automation that means ten browser stacks, ten user-data directories, ten places for state to get weird. It compounds the disconnect problem rather than solving it.
The restart-to-clear-cache loop
Two more restart triggers:
- Tool cache. Tools are read at session start. If I edit a tool definition mid-session, the running Claude Code instances are still using the old one. Restart.
- Settings cache. Same for configuration changes. Restart.
Each restart kills whatever work the agent was in the middle of. Across many parallel tabs, the cumulative friction is significant.
The plan: rewrite integrations as simple CLIs
What I'm doing instead is rewriting my custom integrations as plain CLI tools. No MCP server. Claude Code runs them through the Bash tool it already has.
I already use this pattern for cctabs, my own CLI for managing parallel Claude Code sessions across terminal tabs. It never crashes. There's no MCP server to disconnect because there's no MCP server. Claude just runs cctabs list or cctabs send like any other shell command, gets stdout, and moves on.
To prove the point I rewrote my generativereality/browser-automation Claude Code plugin to be MCP-free, and it works great. It now drives @playwright/cli — Microsoft's official command-line companion to Playwright MCP — via a Claude Code skill, no MCP server in the loop.
Functionality is the same — same Playwright underneath, same browser, same automation. What's different is what happens when something goes wrong. A CLI call that hits a network blip just fails like any shell command; the agent reads stderr and retries, or works around it. No /mcp menu, no manual reconnect, no Claude Code restart, no human-in-the-loop reconnection gymnastics. The interruption disappears, not just the protocol layer.
The same pattern is next up for the custom MCP servers I built for work.
The CLIs that already prove the point
Look at the CLIs that don't have a popular MCP server and don't need one:
gh— there isn't a serious GitHub MCP server, andghis much better than one would be. Every git operation Claude does on my machine goes through it.- Stripe CLI.
- Hugging Face CLI.
- Wrangler (Cloudflare's CLI).
All of these work great. None of them need to be registered or configured as MCP servers. They authenticate once, interactively, with the standard one-time login flow most of them already have. Claude can even drive that login itself — it opens a browser tab, I complete the auth, the CLI writes a token to disk, and from that point on every operation is just a shell call.
No /mcp menu. No restart-to-clear-tool-cache. No restart-to-pick-up-settings. The lifecycle is the OS lifecycle: start, do the thing, exit.
The pattern: a skill + a CLI
The replacement pattern is two pieces:
- A Claude Code skill — a markdown file in
.claude/skills/that captures the workflow. When to use the tool. What the inputs and outputs mean. What to do with the result. It updates when I edit the file. No restart. - A CLI — does the actual work. One job.
--helpdocuments itself. Auth via a one-time interactive login. No long-lived process to babysit.
Together, the skill is the what and when; the CLI is the how. Claude Code already has everything it needs to call CLIs. It doesn't need a new tool surface registered in its system prompt. It doesn't need a new process to keep alive.
What I'm keeping
There is a category of MCP that earns its keep: company-wide MCP servers with SSO auth.
If your employer ships MCP access to Microsoft 365, Slack, internal HR — handled by central IT, with SSO and auto-updates — that's a different beast. The auth handshake is solid. Updates happen without you. The lifecycle is managed. The whole point of having an MCP server there is that everyone in the company gets a consistent way to access shared resources without each person reinventing it.
Those stay. They're stable. They do exactly what MCP is good at.
What I'm pruning is the other category: the custom MCP servers I wrote myself, the npm-wrapped ones for things that would be easier as a CLI, and the browser automation. The ones where I'm the IT department for my own integration and the lifecycle work isn't worth the value the MCP layer adds.
The takeaway
If you're staring at your own .mcp.json and wondering which entries are quietly costing you flow, here's the question to ask of each one:
Could this be a skill plus a CLI?
Don't reach for "we need an MCP server for this" as the default. First think about what the workflow actually needs. Most of the time a Claude Code skill coupled with a custom CLI is a smoother ride.
Less to disconnect. Less to restart. Less buzzkill.
I'm going to remove a lot of MCP servers, and a lot of pain, this way.
If you've moved an integration off MCP onto a skill + CLI — or if you're a tool-builder thinking about which surface to ship — find me on LinkedIn.