What MCP Servers Actually Earn A Permanent Spot In An Agent Session

Published 2026-10-02

Connecting an MCP server to a Claude Code session is a two-minute config change. I run several of them across different projects, and most of them aren't worth having connected for most sessions.

Why More MCP Servers Isn't Automatically More Capability

MCP servers work fine. The real issue is that connecting one doesn't automatically add capability, it adds tool-selection surface area, and if the agent never actually needs that surface area, all it does is make the session slightly noisier.

Every MCP server I connect shows up as a set of tools the agent can choose to call. More tools means more options at every decision point, not just more capability when it's actually needed.

I've watched a session spend a turn considering whether a connected tool applies to the current task, decide it doesn't, and move on. That's wasted reasoning, not a free option sitting in reserve.

A connected-but-unused MCP server still has a real cost. It shows up as friction instead of an error.

This is the actual reason "just connect it, you might need it later" is the wrong default. The server that might be useful someday is competing for attention against the servers doing real work right now.

The Categories That Earn A Permanent Spot

Two kinds of MCP server have stayed connected across every project I work on.

The first: something with no other API surface I can reach directly. A browser-automation MCP server is the clearest example. There's no shortcut for "click this button on a live page" without either driving a real browser or writing custom Playwright code for every single task.

The MCP server is the only practical way in, so it earns its spot by being the only option, not by being marginally more convenient than an alternative.

The second: something used constantly enough that typing the request manually every time would genuinely slow me down. A documentation or project-management connector I touch multiple times per session falls here.

If I'm going to ask for the same kind of thing five times today, the tool call is faster than manually explaining the request in prose each time and waiting for a web search to approximate an answer.

Both categories share the same underlying test: does this remove real friction from something I'm actually doing, not something I might theoretically do.

The scheduling MCP tooling I use to run two separate content pipelines from one session is a good example of the first category. There's no other way to get a prompt to fire again at an exact future moment from inside a live session.

The capability doesn't exist anywhere else I can reach, so the tool earns its spot by being the only door in, not by being a slightly nicer version of something else available.

The Categories That Usually Don't

The MCP servers I've disconnected all failed the same test from the other direction.

Anything duplicating a capability the agent already has natively is the first failure mode. If Claude Code can already read a file, search text, or run a shell command directly, an MCP server wrapping the same operation behind a different interface adds a decision point.

It doesn't add anything new to decide between.

A one-off integration for a single task that never comes up again is the second. I connected a server for a specific data migration once, used it for exactly that task, and left it connected afterward out of habit.

It sat there for weeks, never called again, just adding to the list of tools the agent had to consider and discard on every unrelated task.

Neither of these means the server is badly built. It means the fit between that server and my actual recurring work wasn't there, which is a different problem than the tool being broken.

There's a third failure mode worth naming separately: a server that technically works but produces output the agent can't verify on its own. I've written before about why I don't let an agent trust its own arithmetic without checking it against real code, and the same caution applies here.

An MCP server that returns a number or a count is only as useful as my ability to confirm that number is actually right. A connector with no obvious way to spot-check its own output adds a new place for a wrong answer to slip through unnoticed.

A Concrete Decision Rule

After a week of actually using a newly connected MCP server, I check one thing: did it get called more than once for something I'd otherwise have done by hand or through a worse workaround.

If yes, it stays. If the honest answer is "I connected it, tried it once, and haven't touched it since," it comes out, regardless of how capable the underlying service is.

Unused capability still costs something. It adds a tool the agent has to weigh against the ones I'm actually relying on, every single time it decides what to call next.

That one-week check has been more reliable than trying to predict ahead of time whether something will be useful. The actual pattern of use after a few real sessions tells me more than guessing at connection time ever did.