AI Strategy

The MCP Servers We Actually Use with Claude Code (and the Ones We Turned Off)

September 04, 2026 · 8 min read | AI Strategy

Out of the box, Claude Code sees your repository. What makes it feel like a senior engineer is what else it can see — and, just as much, what it can’t.

We build client products with Claude Code daily — the lessons from that are documented — and the single biggest upgrade since adopting it hasn’t been a model release. It has been wiring the right MCP servers into it, so the agent stops asking us to paste things and starts checking them itself. This post is our current working setup: the categories that earn a place, how we configure them per project, and the pruning rule we learned the expensive way.

A scoping note: this is the coding-workflow view of MCP. For choosing servers in general, our vetting guide covers the ecosystem; for the business case, start with MCP Explained.

The five categories that earn their context

Source control and CI — the non-negotiable

The official GitHub server (or your forge’s equivalent) turns “why is CI red?” from a copy-paste session into a question Claude Code answers itself: it reads the failing run, finds the diff that broke it, and proposes the fix in one loop. PR review context — reading comments, checking linked issues — is the other daily win.

A read-only window into the database

A database server pointed at a development or replica instance, read-only, lets the agent check the actual schema and the actual data shape instead of inferring them from ORM models — which is where a surprising share of its wrong guesses used to come from. Read-only is doing heavy lifting in that sentence; we never point write-capable tools at anything shared.

Errors and logs from the running system

Error-tracker and log-platform servers close the loop on “it works on my machine”: the agent reads the production stack trace, correlates it with the release, and starts the fix from evidence. This is the category that most changes debugging sessions.

The project tracker

Ticket context — acceptance criteria, linked discussions, who asked for what — read directly rather than summarised into the prompt by a human. We keep write access (moving tickets, posting comments) behind approval, but read access alone removes a whole class of “built the wrong thing” errors.

A browser for verification

A browser-automation server lets the agent open the app it just changed, click through the flow, and screenshot the result — turning “I believe this works” into “here is it working.” For frontend work this is the difference between generated code and verified code, a distinction we care about a lot in our shipping workflow.

Configuration: per project, checked in, least privilege

Three habits make this manageable across many client projects. First, project-scoped configuration: each repository carries its own MCP server list in a checked-in config file, so every engineer — and every fresh Claude Code session — gets the same connections without personal setup drift. Second, credentials stay out of the config: servers authenticate via OAuth or environment-injected tokens, never keys committed to the repo. Third, client work gets client boundaries: a project’s configuration reaches that client’s systems only — no shared servers that could let context bleed between engagements. None of this is exotic; it is the same hygiene as any credentials management, applied to a new kind of consumer.

The pruning rule: we’ve removed more than we’ve added

Every connected server spends two budgets: the model’s attention and your security surface. A server that isn’t earning against both is a cost wearing a feature’s clothes.

Our honest experience this year: the failure mode wasn’t missing servers, it was accumulating them. Somewhere past a dozen active servers, sessions got slower and tool choice got visibly worse — the agent would reach for a plausible-but-wrong tool simply because it was there. The fix was embarrassing in its simplicity: we audited which servers’ tools actually appeared in a month of session logs and turned off half of them. Nothing got worse. Several things got faster.

📉

Default off, not default on

A new server joins a project’s config when a recurring task needs it — not because it might be useful someday. Someday can enable it someday.

🔬

Audit by usage, quarterly

If a server’s tools haven’t been called in a month of real work, it’s out. Re-adding a server takes one line; carrying dead weight costs every session.

🧯

Write access is per-project, argued for

Read-only is the default posture everywhere. A write scope gets added for a named recurring need, with Claude Code’s approval prompts left on for it.

🧪

New servers get a sandbox week

Anything community-built runs against non-client scratch projects first — the vetting checklist from our registry guide, applied in practice.

The meta-lesson mirrors everything else we’ve learned about AI-assisted development: leverage comes from deliberate constraints, not maximal capability. Claude Code with five well-chosen, well-scoped servers outperforms Claude Code with twenty — the same way a tightly-scoped MVP outships an ambitious one. Connect what the work needs. Turn off the rest.

Want your team’s AI coding setup tuned like this?

We set up Claude Code workflows for engineering teams — the right MCP servers, scoped and secured, with the config patterns that keep ten projects manageable.

Talk to Our Team →

The MCP Servers We Actually Use with Claude Code (and the Ones We Turned Off)

The five categories that earn their context

Configuration: per project, checked in, least privilege

The pruning rule: we’ve removed more than we’ve added

Want your team’s AI coding setup tuned like this?

Latest from Syntaxa Studio.