MCP — Model Context Protocol — turned eighteen months old in May 2026. What started as Anthropic’s proposal for a standard way to connect Claude to external tools has settled into the default mental model for “how a coding agent talks to anything that is not the model.”

There are now hundreds of MCP servers. Most of them are not worth installing. Adding an MCP server to your client costs you context window and adds noise to every tool-selection decision the model makes. The more servers you have configured, the worse your agent gets at picking the right tool for any given task.

This post is the short list. What I actually keep installed in May 2026, what I tried and removed, and the meta-pattern for deciding what belongs in your setup.

The Core Stack

These five do most of the work. If you install nothing else, install these.

Filesystem. The boring one. Lets the model read and write files outside the project directory it was launched in. Most coding clients (Claude Code, Cursor, Cline) already have built-in file tools for the working directory — the MCP server matters when you want the agent to touch a different repo, a config file in ~, or anything outside the sandbox.

Git / GitHub. Not just “read this repo” — the real value is browsing PRs, reading issue threads, looking at the diff of a commit on a different branch without checking it out. The gh CLI does most of this already, and an MCP wrapper around gh is genuinely useful because the model picks the right gh invocation more reliably than it remembers the flags.

Playwright (browser). Lets the agent open URLs, click around, fill forms, take screenshots. Essential for any task involving a UI you control — testing your own app, verifying a fix landed in production, reading documentation behind auth. The Playwright MCP became the de facto standard sometime in early 2026 and most clients ship it.

Web fetch + search. A simple HTTP-fetch MCP plus a search-engine MCP (Brave, Exa, or DuckDuckGo). The fetch is more useful than the search — most agent tasks have a specific URL in mind, not a query. The search is useful for “find me docs on X.”

One project-management tool. Linear, Jira, Asana, Azure DevOps — whichever one runs your work. The win is that the agent can read a ticket, understand the context, look at the linked PRs, and write a status update without you copying anything around. Just one — multiple PM MCPs configured at the same time is the worst form of context bloat.

The “Sometimes Useful” Tier

These earn their slot for specific workflows but are not core.

Database (Postgres, MySQL, SQLite). If you do database work, the right MCP lets the agent run schema queries and read-only SELECT against your dev DB. Pair with strict read-only credentials. Worth it if you do schema design or query optimization regularly; skip if you mostly work above the ORM layer.

Slack / Teams. Useful for “draft a status update based on this PR and what I have been working on this week.” The risk is that the agent reads more channels than you wanted it to. Scope the auth tightly.

Notion / Obsidian / Confluence. Knowledge-management MCPs are good if your second brain lives in one of these. They are bad if you have several of them and they overlap. Pick one.

Sentry / Datadog / Grafana. Observability MCPs are the sleeper category. “Look at the error spike at 14:32 yesterday and tell me what changed in the last deploy” is a real workflow that an agent does much better than a human flipping between four browser tabs.

What I Tried and Removed

Email MCPs. I expected to love these. I did not. The agent reads too eagerly, drafts too verbosely, and the workflow of “verify what the agent is about to send” was always slower than just writing the email myself.

Calendar MCPs. Same problem as email — the agent is helpful for “what is on my schedule next Tuesday,” but for that question I already have a calendar app. The agent doesn’t add anything.

Multiple browser MCPs. I tried Playwright, the older Puppeteer-based ones, and a couple of agent-focused alternatives. Playwright is the right pick. Running more than one browser MCP at a time guarantees the model picks the wrong one half the time.

Generic “let me execute any shell command” MCPs. Most coding clients already have a Bash tool. Installing an MCP that does the same thing with worse defaults is a regression.

The Pattern That Hurts You

Every MCP server you add does three things:

  1. Adds tools to the model’s tool list. Each tool’s schema and description sits in the context window.
  2. Adds decisions. When the agent decides which tool to call, more options means more wrong picks.
  3. Adds attack surface. Every MCP server is code running on your machine with whatever permissions you gave it.

The combined effect is non-linear. Going from five to fifteen MCPs feels like a 3x feature increase. In practice the agent gets worse at every individual task because it spends more capacity choosing tools and less capacity using them.

The right move is to start minimal, add a server when you have a specific repeated task you cannot do with what you have, and uninstall anything you have not used in two weeks.

Building Your Own

For consultancy work or internal tools, the high-leverage MCP servers are not the ones on a public registry — they are the ones that talk to your specific legacy system. An MCP server that wraps your client’s bespoke ticket tracker, internal documentation system, or git-but-actually-Perforce setup will make every agent task involving that system 5x faster.

The MCP TypeScript SDK and Python SDK are both mature enough that building a server takes a day, not a week. The hard part is getting the descriptions right so the agent picks the right tool — your first version will be too verbose and the agent will use the wrong one. Iterate the schemas, not the behavior.

For one Tomra Azure DevOps automation I built earlier this year, the MCP server itself was 200 lines of TypeScript. The tool descriptions went through six revisions before the agent stopped misclassifying ticket types. That ratio — short code, careful schemas — is the pattern.

Where MCP Is Heading

Two trends to watch:

Authentication standardization. OAuth flows for MCP servers were a mess through 2025 and most of 2026. The MCP 1.2 spec (still in draft as of May) cleans this up, and once it lands, hosted MCP servers from third parties will get viable. Right now most production MCP setups are self-hosted because the auth story for managed servers is awkward.

Server discovery. There is no good MCP server registry yet. The mcp-discovery and awesome-mcp lists are the de facto registries, and they are GitHub README files. This will change in the next six months — someone will ship a real registry — and it will be a meaningful unlock for adoption.

If you have been ignoring MCP because the ecosystem felt early — May 2026 is the moment it stopped being early. The protocol is stable, the SDKs are mature, and the servers that matter are well-maintained. Pick five. Use them. Skip the rest.