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

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.

By that test, most of the servers people install do not qualify. A filesystem server in a tool that already reads files. A git wrapper in a tool that already has git. These add tool definitions to every turn and buy nothing.

The categories that survive

Rather than naming a shifting list of packages, here is the shape of the ones that stay connected in the teams we train:

• 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".

Three of those, chosen for the repo you are in, covers almost every team. The fourth is usually somebody's enthusiasm.

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 everyone on the team gets the same tool surface and the agent behaves the same way for all of them.

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. Auto-approving a tool that can post, merge, or deploy is the change we most often ask clients to undo.

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.