The MCP servers worth installing in Claude Code
Every list of these is ranked, numbered, and about thirty entries long. That shape is wrong for the decision you are making, because you are not going to install thirty. Most people run between two and seven.
So here it is by category instead, with the thing the ranked lists leave out: what each one costs you.
First, the cost nobody mentions
Every MCP server you connect adds its tool definitions to the context of every single turn, before you have typed anything. A server with fifteen tools and verbose descriptions is a standing tax on every request, whether or not you use it that day.
This is why "install the top ten" is bad advice. Three servers you use daily beat ten you forgot you connected, and the ten will make the model slower and more distractible at everything else.
Add them one at a time, and remove the ones you stop using. That single habit matters more than which ones you pick.
1. Docs that are not eighteen months old
The highest-value first install for most people, because it fixes the failure you hit constantly: the model confidently writing an API that was deprecated two versions ago. Context7 is the common choice here — it fetches version-specific documentation on demand.
Install this first if you work with libraries that move fast. The failure it fixes is the one you are most likely to ship without noticing.
2. Your issue tracker and your repo
GitHub's own MCP server for PRs, issues and code search; Linear and Sentry both run official hosted servers if you use them.
These are worth it when the alternative is you copy-pasting issue descriptions into the chat, which is most teams. The cost is that these are large servers — GitHub's in particular exposes a lot of tools — so this is the category where you most want to check whether you are paying for tools you never call.
3. A browser
Playwright MCP from Microsoft, for driving a real browser: testing a flow, scraping a page, taking a screenshot of what you just built.
Worth it the moment you are doing frontend work and describing what you see to the model in prose. Let it look.
4. Filesystem and databases
The filesystem reference server is the most foundational one, though Claude Code already reads and writes files natively, so it earns its place mainly when you need access outside the project directory.
Database servers — Postgres and friends — are genuinely useful and are the category to be most careful with. Use a read-only connection unless you have a specific reason not to, and do not point one at production because it was convenient.
5. Memory, which is the one that fails quietly
This is the category with the widest gap between what is advertised and what you get, so it is worth being specific about how to judge one.
Almost every memory server works the same way: the agent is told it may call
add_memory when something matters. That is advice, and a model in the middle
of a refactor ignores advice. The result is a memory that is far emptier than
its owner assumes — not because storage failed, but because nothing ever asked
it to store anything.
The honest test: install one, use it for a week, then go and look at what is actually in it. Most people are surprised, and not pleasantly.
The second thing to check is what the memory is scoped to. Most are scoped to you — they learn your preferences and follow you between projects, which is right if what your agent keeps forgetting is you. A few are scoped to the project, so everyone working on it shares one and a colleague who joins on Thursday reads what was decided on Monday. Those are different products, and which you want depends on whether the thing going stale is about you or about the work.
We build one of the second kind (Kika), and the design decision we would defend hardest is that it does not rely on the agent choosing to save anything — Claude Code fires an event when a turn ends, and the server decides for itself. That is the difference between a memory that fills and one that does not.
What we would not bother with
- Servers that wrap an API you could just
curl. The model can already make an HTTP request. A wrapper earns its context budget when it does something more than translate the call. - Anything you installed for one task three weeks ago. Go and look at your list now; there is probably something on it you have not thought about since.
- A second server in a category you already have covered. Two overlapping tools is worse than one, because now the model has to choose.
The actual answer
For most developers: docs, your issue tracker, and a browser. Add memory when you notice you are re-explaining the same decisions, and pick its type based on whether what keeps going stale is about you or about the project.
Then stop, and remove one every time you add one.
Kika is the project-scoped kind, and it is free:
claude plugin marketplace add usekika/kika-plugin
claude plugin install kika@kika