When Claude Code MCP servers help, and when they hurt

A Claude Code MCP server hands the agent tools it would not otherwise have: your issue tracker, your schema, your logs. When the agent was previously guessing at the shape of something, that guess becomes a lookup, and the output gets visibly better.

The cost is that every registered tool contributes its name, description, and argument schema to the context on every turn, including the hundreds of turns where it is irrelevant. Connect enough servers and you degrade the thing you were trying to improve. Teams notice this as "it got dumber after we set up integrations", and they are right.

So the question is never "is this server good". It is "does this server change more answers than it costs".

Claude Code MCP servers that pass the test

• Schema access, read-only. The agent stops inventing column names. This is the single highest-value connection for backend work.
• Current library documentation. Removes a whole class of plausible-looking calls to APIs that no longer exist.
• The issue tracker, read-only. "Implement the ticket" stops being a game of copy and paste.
• Observability, read-only. Being able to fetch the actual error rate or the actual trace turns debugging from speculation into reading.
• Your own internal server, exposing three or four operations specific to your platform. Narrow, custom servers outperform broad vendor ones almost every time.

Servers that fail it

Anything exposing dozens of tools for a product your team touches monthly. Anything that duplicates something the agent can already do with a shell command, which is a large share of git integrations. Anything with write access to production that you have not deliberately scoped.

That last one deserves a paragraph. Tool results come back into the model's context as text, and text from an external system is untrusted input. A ticket description or a log line can contain instructions. If the agent has a tool that can delete or deploy, a badly worded page in your wiki becomes an attack surface. Keep destructive tools behind manual approval rather than adding them to an allow list, and prefer servers that expose read-only variants.

Keeping the cost down

Three habits do most of the work.

Register at project scope in .mcp.json only what the whole team needs on this repo. Personal experiments stay in local scope where they do not tax your colleagues.

Push tool-heavy work into a subagent. A subagent runs with its own context, so a research task that needs six tool calls can burn them there and return a summary, leaving the main session clean. This is the most underused lever in the whole setup.

Audit quarterly. Run the list, and for each server ask when it was last actually called:

claude mcp list

If nobody can name a task from the last month where a given server mattered, remove it. Removing is cheap. Re-adding is one command.

What to do next

Pick the thing your agent most often gets wrong through no fault of the model, the fact it simply cannot see. Connect one server that supplies it, use it for a week, and write down two tasks where it changed the answer. If you cannot fill in both lines, take it out and try a different one.

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