MCP Servers That Earn Their Place

MCP lets Claude Code talk to things that are not your filesystem — a notes vault, a design tool, a calendar, a database.

The temptation is to connect everything. Resist it, for a reason that is not obvious until you have overdone it: every connected server adds tools, and tools are not free.

The cost nobody mentions

Each MCP tool has a name, a description and a JSON schema. Those definitions occupy context. Connect four servers exposing fifteen tools each and you have spent a meaningful chunk of your window on API documentation before typing a word.

There is a subtler cost. A crowded tool namespace makes selection harder. Given sixty tools with overlapping descriptions, the wrong one gets picked more often — and the failure looks like the assistant being dim rather than the setup being cluttered.

Modern setups mitigate this with deferred loading: tool names are visible, full schemas load on demand. It helps a lot. It does not make the question go away.

The test

Before connecting a server:

Does this let me do something I cannot already do with a shell command or a file read?

Most things fail. A server wrapping a REST API I could curl fails. A server reading files I could read directly fails.

What passes is anything with real state on the other side — an application with its own model of the world, its own auth, its own format. That is where a protocol beats a shell.

What survives

Obsidian. The memory vault. This passes the test on a technicality worth understanding: the notes are plain Markdown I could read directly, but the vault has structure the filesystem does not expose — wiki-link resolution, a tag index, frontmatter as queryable metadata. find_backlinks and manage_tags are not shell commands. That is the difference between a folder and a knowledge base.

A design tool. I use Pencil, which edits .pen files. These are encrypted, so there is no shell fallback — reading a design means going through the tool or not at all. Clearest possible pass: strictly impossible otherwise.

A memory hub. A second, more structured store with explicit graph operations — backlinks, orphan detection, connection suggestions. Overlaps with Obsidian more than I would like, which is honestly a case of having adopted two things that solve the same problem at different times. If I were starting clean I would pick one.

Google Workspace. Drive, Gmail, Calendar. This one is about auth rather than capability. I could hit these APIs with curl, but I would need to manage OAuth tokens, refresh flows and scopes myself. The server does that. Genuinely useful for pulling client-supplied documents into a project without a download-and-move dance.

What did not survive

Patterns rather than specific names, since the specifics date fast.

Wrappers around things with good CLIs. Anything with a mature command-line tool — git, GitHub, package managers, cloud providers — is better used through that CLI. The CLI is more capable, better documented, and its output is already text. An MCP wrapper around gh is strictly worse than gh.

Servers exposing dozens of tools for one job. A server with forty tools where you use two has spent forty tools' worth of context to give you two. Prefer narrow servers.

Anything with production write access. A server that can write to a production database is a server that can drop a production table. I do not connect those. Reading production data through a read-only path is fine; writing is a decision I want to make deliberately, with my own hands, not something a tool call can reach.

The headless caveat

Worth knowing before you build automation on top of this: servers that authenticate interactively may simply not exist in a headless run.

If a server needs a browser login, a scheduled job or CI run that has no browser may find it missing. Automation built assuming a tool is present will fail in ways that look mysterious — the tool is there when you test interactively and gone when it runs at 3am.

Anything scheduled should either avoid interactively-authenticated servers or handle their absence explicitly.

Security, briefly

Two things I would not skip.

An MCP server is code you are running. It runs with your permissions, sees what you point it at, and can talk to the network. Connecting one is closer to npm install than to enabling a setting. Same scrutiny applies.

Content from a server is data, not instructions. Text coming back from a server — a document, a note, a page — is untrusted input. If a fetched document contains something shaped like an instruction, it is still just text in a document. This matters most for servers that read things other people wrote: shared drives, email, web pages.

The practical version: be more careful with servers that read other people's content than with servers that read your own.

Start with one

If you are setting this up from scratch, connect one server, use it for a week, and only then add another.

The value is genuinely high — reaching a notes vault or a design file from the same session where you are writing code removes real friction. But the cost is diffuse and easy to miss, and a setup with eight servers connected "just in case" is measurably worse than one with two that you actually use.

Next: the day I confidently diagnosed the wrong cause of a production outage — and what caught it.