The MCP Servers I Actually Keep Installed (2026 Field Log)

Quick Answer (2026): The best MCP servers in 2026 are the boring, high-frequency ones you forget are even running: a filesystem server, git, the GitHub server, a database server pointed at your dev DB, and Playwright for anything browser-shaped. After three months of leaving Model Context Protocol servers wired into my coding agent every single day, those five earned permanent slots. The flashy ones (broad web search, general scraping, anything that asked for wide write access) got uninstalled. Fewer, more trusted servers beat a long list, because every connected server costs you context and a little bit of trust.

I write when something breaks, and what broke this time was my own setup.

Three months ago I did the thing everyone does: I read a "top 20 MCP servers" list, installed most of them in an afternoon, and felt very productive. Two weeks later my agent runs were slower, more expensive, and occasionally doing things I did not ask for. So I ripped the whole config out and rebuilt it one server at a time, only re-adding a server after it actually earned a week of daily use.

This is the list that survived. It is short on purpose.

What MCP actually is, in one paragraph

The Model Context Protocol is an open standard from Anthropic for connecting an AI model to tools and data through a common interface, so your coding agent can read files, query a database, or open a browser without you gluing each integration by hand. Anthropic's own MCP documentation (2026) is the canonical reference, and the official server list lives in the modelcontextprotocol/servers repo (2026). The protocol is the good part. The trap is treating "install more servers" as a strategy.

The five that earned a permanent slot

Here is the whole kept list, each with the one-line verdict I would give a friend.

Filesystem. The reference filesystem server is the one I would keep if I could only keep one. It scopes the agent to a directory and lets it read and write files there. Verdict: invisible, essential, keep it scoped tight to the repo and nothing above it.

Git. Local git operations without shelling out for every status and diff. Verdict: pairs with filesystem, saves a hundred tiny commands a day, keep.

GitHub. The GitHub server reads issues and pull requests and can open them. This is the first server where I got nervous about scope, so I run it with a fine-grained token limited to the two repos I actually touch. Verdict: high value, but scope the token, do not hand it your whole account.

A database server. I point a Postgres MCP server at my dev database, read-only, and let the agent answer "what does the schema look like" without me pasting DDL. Verdict: enormous for the schema questions, and read-only against a dev copy is the only sane way to run it.

Playwright. Microsoft's Playwright MCP (2026) drives a real browser through the accessibility tree, so the agent can click through a flow and tell me what actually rendered. Verdict: the one "impressive demo" server that also survived contact with real work, keep it but launch it only when a task needs a browser.

Notice the pattern. Every survivor is high frequency, narrowly scoped, and mostly read-oriented. That is not a coincidence, it is the whole selection rule.

The ones I uninstalled, and why

The drop list is more useful than the keep list, so here it is honestly.

A general web-search server went first. My agent already had a search path, so a second one just added tool definitions and ambiguity. It was not bad, it was redundant.

A scraping server went next. It wanted network access plus write access, it was flaky on sites with any bot protection, and the risk-to-reward on a server that browses arbitrary URLs with broad permissions was not worth it. This is exactly the "use them safely" warning that Red Hat wrote up in 3 MCP servers you should be using (safely) (2025), and living it for a month made me believe it.

An "everything in one" mega-server went too. One server exposing forty tools sounds efficient until you realize all forty tool definitions get injected into context on every request, whether you use them or not.

And a note-taking integration got dropped for the most boring reason: I kept forgetting it was there. Nothing was wrong with it. It just never fit my loop, and a server you never reach for is pure overhead.

The two costs nobody puts on the listicle

Every "best MCP servers" roundup lists capabilities. Almost none of them list the two things that actually made me cut my config in half.

The first cost is context. Every connected server injects its tool definitions into the model's context on every request. Ten servers means a fat system prompt sitting in front of every prompt you type, which is slower and, on a metered model, quietly more expensive. I did not have a spreadsheet, but the per-run cost visibly crept up as the list grew, and dropped again when I trimmed it. Servers are not free just because they are idle.

The second cost is trust. An MCP server runs with whatever access you grant it, inside your agent's loop, and a compromised or badly-scoped server is a real security surface. My rule after three months: default to read-only, scope every token to the minimum, and never leave a broad-write server connected "just in case." If a server needs the keys to everything, it does not get a permanent slot.

How I decide what earns a slot now

The rule is three questions, and a server has to pass all three.

Do I reach for it at least weekly? If not, it is overhead, not a tool.

Can I scope it down (read-only, one repo, one directory, one dev database)? If it only works with broad access, that is a strong signal to leave it out.

Is it worth the context it costs on every request? A server I use twice a month is not worth carrying in every prompt.

That filter is why my list is five and not twenty-five. If you want the longer story of how I picked the actual coding agent underneath all this, I wrote up the AI coding agents I actually reach for, and a companion field log on running Claude Code headless in CI where scoped tool access matters even more, because there is no human to approve a prompt.