Dev-Tools MCP Servers
The MCP servers that make Claude Code a full development environment participant — not just a coding assistant. GitHub, Sentry, Docker, Kubernetes, Terraform, and the rest of the dev-workflow surface your team already uses.
Why dev-tools MCPs are the second install after database MCPs
Database MCPs make Claude Code aware of what's stored. Dev-tools MCPs make Claude Code aware of what's happening — the open PRs, the failing tests, the recent errors, the running containers, the deployed state. Once Claude can see all of that natively, it stops asking you to paste error messages, stops needing you to describe the CI failure, and stops guessing at deployment state.
The 12 MCP servers on this page cover the dev-workflow surface most teams have already assembled: version control (GitHub, GitLab), errors and observability (Sentry, Datadog, PostHog), runtime infrastructure (Docker, Kubernetes), infrastructure-as-code (Terraform), CI/CD (GitHub Actions, CircleCI), and secrets (Vault). Install the ones matching your stack and Claude Code moves from coding assistant to full development environment participant.
The prioritization curve
Not every dev-tools MCP is equally valuable, and the difference matters — each MCP server adds startup latency, memory usage, and one more surface to keep credentials for. A practical prioritization:
- Version control MCP (GitHub, GitLab, or Bitbucket — whichever you use). Highest value by far. Enables issue lookup, PR review, code search across repos, and workflow triggering.
- Error observability MCP (Sentry usually). Lets Claude read stack traces directly. Especially high value if your team lives in Sentry for debugging.
- Container/orchestration MCP (Docker, then Kubernetes if applicable). Enables state-aware debugging — Claude can see what's actually running, not what should be running.
- Everything else based on your specific workflow — Terraform if you're heavy on IaC, PostHog if you make product decisions from analytics, CircleCI if that's where CI runs.
Reference config — a solid dev-tools starter set
Three servers — GitHub, Sentry, Docker — cover a huge swath of daily dev work. GitHub reads your PRs and issues, Sentry reads your errors, Docker sees your local containers. Add Kubernetes on top for teams running clusters, Terraform for IaC-heavy teams. Keep the set tight; more servers means more startup time and more credentials to rotate.
The auth-and-secrets story that matters here
Dev-tools MCPs almost always need credentials to services you already have paid accounts for. Two rules keep this manageable:
- Prefer scoped tokens over master credentials. A GitHub PAT scoped to
repoonly can't delete your repo or leak your billing settings. A read-only Sentry API key can't accidentally acknowledge someone else's issues. Match the token's scope to Claude Code's actual needs. - Environment variables, not hardcoded values. Reference secrets via
${GH_TOKEN}insettings.jsonand set them in each developer's shell (or a gitignored.env.local). Never commit the actual secret.
Some MCPs offer OAuth as an alternative (Sentry, Linear, Notion). OAuth is a better security profile — scoped consent, easier revocation, no PAT living in a developer's env forever. Use it when available.
The observability-driven debugging pattern
Once Sentry and GitHub MCPs are installed, a particular workflow becomes possible that used to require significant copy-paste:
- Prompt: "the last deploy has an error spike — look into it".
- Claude uses the Sentry MCP to list recent unresolved issues since the deploy.
- For the top issue, Claude fetches the stack trace and event count.
- Claude uses the GitHub MCP to look at the commits included in that deploy.
- Claude cross-references the stack trace file paths against the deploy diff.
- Claude proposes the commit likely responsible plus a rollback or fix.
Six steps, zero context copy-paste. That's the payoff of dev-tools MCPs installed as a coherent set rather than one at a time.
All 12 dev-tools MCP servers, grouped by workflow domain
Version control, error observability, containers, IaC, and CI/CD — the tools your team already uses, now visible to Claude Code natively.
Which dev-tools MCPs should I install?
The prioritization curve is steep — install the top-tier servers first, others as your workflow demands.
Related sub-categories in MCP Guides
Dev-tools MCPs pair naturally with databases, cloud providers, APIs/SaaS, and communication — the four groups that cover most modern application stacks.
🐛 Hit an error while using these?
Our sister site AI Error Hub covers Claude Code errors, MCP connection failures, and stack traces — cross-referenced with everything on this site.
Frequently asked questions
The questions developers ask most about dev tools.
GitHub (or GitLab/Bitbucket if that's where your code lives). It unlocks:
- PR review
- Issue lookup
- Code search across repos
- Workflow triggering
… all things you'd otherwise copy-paste into Claude. Single highest-value dev-tools MCP by a wide margin.
Fine-grained if you can. Fine-grained PATs let you restrict access to specific repos and specific permissions.
If Claude Code only needs to read PRs and issues, a fine-grained token with:
- Read metadata
- Read code
- Read PRs
- Read issues
… is much safer than a classic PAT with the full repo scope.
Yes. Point it at your self-hosted URL and use an internal integration token.
The MCP protocol is agnostic to whether the Sentry instance is SaaS or self-hosted; the same tool surface (list issues, get event details, resolve/ignore) works against both.
Same is true of self-hosted GitLab and self-hosted Jira.
Docker MCP is fine for local development — it operates on your local Docker daemon.
Kubernetes MCP needs a kubeconfig context; make sure that context points at a read-only ServiceAccount for shared clusters.
Never point a Claude Code Kubernetes MCP at a prod cluster with cluster-admin. Use a read-only namespace-scoped ServiceAccount at minimum.
Different surfaces of the same platform:
- github MCP — repo-facing operations (issues, PRs, code, releases).
- github-actions MCP — workflow runs, job logs, artifacts, cache.
Install both if you use GitHub Actions heavily. If you only ever ask Claude about PRs, just github is enough.
Once GitHub and Sentry are both installed, you can prompt:
"The last deploy has an error spike — look into it."
Claude:
- Fetches recent Sentry issues.
- Gets the top issue's stack trace.
- Cross-references file paths against the GitHub diff of the deploy.
- Proposes the responsible commit.
Six steps of debugging with zero context copy-paste. That's the payoff of a coherent set of dev-tools MCPs installed together.
Not directly — MCP servers read env vars at startup, and by then the Vault MCP isn't running yet.
Use a shell script or dev-environment tool (direnv, doppler run, chamber exec) to fetch secrets from Vault and export them before launching Claude Code.
That way the other MCPs get their credentials from env vars as normal, and Vault stays the source of truth.
Watch startup time. Each MCP server adds a few hundred milliseconds of session-start latency and one more credential to manage.
- 4-5 dev-tools MCPs — comfortable.
- 8 — manageable.
- 12+ — starts feeling heavy.
Prioritize the ones that eliminate the most copy-paste for your actual daily work, and skip the ones that sound useful but you'd rarely reach for.
Yes — MCP is a standard, and every MCP server on this page works with any MCP-compatible client.
That includes Claude Desktop, Cursor, Cline, Windsurf, Continue, and any future MCP client. Investment in the setup pays across every tool you use.
Yes — commit .claude/settings.json to git with env-var references for credentials.
Teammates get the same MCP setup on next pull; each supplies their own credentials in their shell or a gitignored .env.local.
Zero manual onboarding for MCP config, and secrets never touch the repo. Standard pattern for all shared MCP setups.