An MCP servers list worth keeping: the eight I leave connected, and what gets removed
- mcp
- agent-tools
- context-engineering
Every MCP servers list you can find online has the same problem: it is a directory, and a directory answers a question nobody has. You do not need to know that four hundred servers exist. You need to know which three belong in your setup this week, and what it costs you to keep the fourth one connected.
- Directories optimize for length. A list of everything is a list of nothing. The useful list is the one somebody stopped adding to.
- Eight is where mine sits. Data, email, docs, hosting, design, calendar, browser, component reference. That is the whole thing.
- Connected is not free. Every server's tools sit in the model's context on every call, whether or not the job needs them.
- Removal is the discipline. Servers get added on enthusiasm and stay on inertia. A list without a removal rule becomes a directory again.
- The client matters as much as the server. One connection per server, held by the host, is the part that decides what your agent can reach.
The category verdict, and how the protocol works underneath, is in the MCP servers review.
Why a public MCP servers list will not help you
Public directories sort by what is easy to count: stars, recency, category. None of those tell you the only thing that matters, which is whether the server survives contact with your work. A server with two thousand stars that returns unhelpful errors will waste more of your day than an obscure one that fails cleanly.
There is a second problem, and it is structural. A directory has no reason to stop growing. Its incentive is coverage, so it lists the abandoned alongside the maintained, the demo alongside the thing somebody runs in production. The reader is left doing the filtering, which was the job they came to outsource.
So treat any list, including this one, as somebody's stack rather than a ranking. The transferable part is never the names. It is the rule they used to keep it short.
The eight MCP servers I keep connected
Grouped by what job they do, not by vendor.
| Job | What the server gives the agent |
|---|---|
| Search data | Keyword, backlink and ranking data, so analysis runs on numbers instead of guesses |
| Email platform | Contacts, lists and sending, for checking state rather than blasting messages |
| Docs and notes | Reading and writing structured pages, which is where most working context lives |
| Hosting and domains | Domain, DNS and plan data, so infrastructure questions get answered from the panel |
| Design files | Reading a design file directly, which turns a screenshot into a specification |
| Calendar | Read-only availability, which makes scheduling answers real instead of hedged |
| Browser control | Driving a real browser when there is no API and the answer only exists on a page |
| Component reference | Documentation for a component library, so generated code matches the real API |
Two things stand out when it is written down like that. Most of them are read paths. And almost all of them replace a tab I used to open by hand, which is the honest test of whether a server earned its slot.
What is not on the list is as informative. No database server in the write path, for reasons I went through in the database post. No server that duplicates something a five-line script already does. No server I connected once for a demo, which is the category that quietly makes most lists long.
What gets an MCP server onto the list
Four questions, in the order I ask them.
Does it replace recurring manual work? Not "could it be useful" but "which tab does this close". A server that saves ten minutes once is a bookmark. A server that saves two minutes every day is infrastructure.
Is the data live? The reason to connect a server rather than paste an export is freshness. If the numbers change slowly enough that a monthly CSV works, use the CSV and keep the context.
Does it fail in a way an agent can read? This is underrated. A server that returns "error" teaches the agent nothing, so the agent retries the same call. A server that returns "no rows for that date range, valid range is X to Y" gets a correct second attempt.
Is the blast radius acceptable? Any server that can spend money, send messages to people, or change production gets treated as a different class of thing. Connected, if at all, with a human in the path.
What gets a server removed
The rule I use is dull on purpose: if I have not used it in a month, it comes out. Not archived, not disabled with a note to revisit. Removed from the config. It takes ninety seconds to put back, and that asymmetry is the entire point.
Two patterns fail this test regularly. The first is the server connected for one project that ended. The second is the server whose job turned out to be better served by a script, which happens more often than the ecosystem likes to admit. If the same three calls happen in the same order every time, that is a workflow, not a conversation, and something like n8n or a scheduled script will do it cheaper and more predictably.
Removal also has a security dimension. Every connected server is a credential sitting in a config file waiting to be relevant. The smallest list is also the smallest attack surface, and unlike most security advice this one makes your setup faster at the same time.
MCP clients and hosts: the part the list leaves out
A list of servers describes half the picture. The other half is the host, which is the application the agent runs in, and the clients it creates. The host holds one client per server, and each client keeps its own dedicated connection. Five servers means five connections managed by the host, not one shared pipe.
That matters practically. Your servers are not portable state, they are configuration belonging to a host. Move to a different agent application and you move the config, the credentials, and the assumptions about what is allowed. Which is why the host you pick is a bigger commitment than any individual server on the list. Mine is written up in the Claude Code review.
If the roles are still fuzzy, the walkthrough is in what an MCP server is.
How many MCP servers is too many?
The limit is not a number, it is the context they consume. Every connected server advertises its tools to the model so it can decide what to call, and those descriptions are paid for on every request. Connect enough servers and a meaningful slice of the window is a menu the agent will not use on this task.
There is a quality effect too, and it arrives before the cost does. A model choosing from a large menu makes worse choices than one choosing from a short one, in the same way a person does. Wrong tool calls are slower to spot than wrong answers, because the output still looks confident.
Some hosts now load tool definitions on demand instead of upfront, which raises the ceiling. It does not change the direction of the advice. Short list, loaded when needed, beats long list held permanently.
How to audit your own MCP servers list this week
Open your config and write one sentence per server: the last real task it did. Not what it could do, what it did. Servers that get a vague sentence are the ones to cut, and you usually know which they are before you finish writing.
Then check the credential behind each one. Scope it down if it is broader than the job. Anything that can write, spend or send belongs behind an approval you control, and that rule does not bend for convenience.
Whatever survives is your list. It should be shorter than you expect and shorter than any directory would suggest, and that is the point. The short list of what I keep for everything else is on the tools page.