The best MCP servers for Claude Code are the few you keep

This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.

A server is worth connecting when it removes copy-paste from your day. That is the test. If the alternative to the server is you switching windows, copying text, and pasting it into the session, connect it. If the alternative is the agent running a command it already has a shell for, skip it.

Check whether a proposed server duplicates a capability already available in the client. A filesystem server in a tool that already reads files. A git wrapper in a tool that already has git. They may be redundant, although a server can still be useful if it provides narrower permissions or a better interface than shell access.

The categories that survive

Rather than naming a shifting list of packages, evaluate these task-specific categories:

• Issue tracker or project tool. The agent reads the ticket itself instead of you summarising it badly.
• Browser control, when you work on a UI. Being able to load the page and read the console closes the loop between a change and its effect.
• A read-only database or schema server, when your code is shaped by tables the agent otherwise cannot see.
• Documentation retrieval for a framework you use heavily, when the model's knowledge of it is stale.
• Your error tracker, if the workflow is genuinely "here is an exception, find the cause".

Keep only the categories justified by the current repository and task. There is no universal number of servers that fits every team.

Install per project and commit the config

Register servers at project scope so a docs repo does not carry your database tooling. Put the config in a committed .mcp.json at the repo root, so teammates can review the intended setup. Keep credentials out of the committed file, and verify each account’s actual permissions; shared configuration does not guarantee identical access or behavior.

Then verify. Run claude mcp list and read the status. A server that fails to connect on startup is a common and silent problem, usually a missing environment variable or an expired token. Nobody notices because the agent simply stops using that capability and never says why.

Permissions deserve more thought than choice

The interesting risk is not a bad server. It is a good server with a credential wider than the job. Give each one the narrowest token that works, read-only wherever the workflow allows, scoped to one repository or one database rather than the whole account.

Anything that can write to a system other people depend on should require confirmation every single time. A tool that can post, merge, or deploy needs an explicit authorization boundary and a record of the resulting action.

What to do this week

Open your config and delete every server you cannot connect to a task from the last two weeks. Work without them for a sprint. Then add back only what you actually missed, committing each one to the repo with a one-line comment on why it is there. A short list chosen deliberately beats a long list assembled by curiosity.

If you want help putting this into practice, talk to us.