Six months ago, if you told me an AI agent could open a PR, check the failing CI job, correlate the error with a Datadog trace, and suggest a fix — all without me copy-pasting a single URL — I’d have called it a demo-ware fantasy. But that’s exactly what MCP makes possible today, and I’ve been running this setup on real production workflows for the past few months.
The Model Context Protocol ecosystem has exploded. The Glama registry alone lists over 22,000 servers, and every major DevOps vendor has shipped an official integration. The problem isn’t finding MCP servers anymore — it’s figuring out which ones are worth the setup time and which are half-baked wrappers around a REST API you could’ve just curled.
This guide covers the MCP servers I’ve actually found useful for DevOps work, how to set them up properly, and — critically — how to avoid giving an AI agent the keys to your production cluster.
What MCP Actually Is (30-Second Version)
MCP is a standardized protocol that lets AI coding tools — Claude Code, Cursor, VS Code with Copilot, Windsurf — talk to external services through a consistent interface. Instead of the AI guessing at commands or you copy-pasting context into a chat window, the AI can directly query GitHub issues, read Terraform state, or pull Datadog metrics through structured tool calls.
Think of it like a USB standard for AI integrations. Before MCP, every tool had its own proprietary plugin system. Now there’s one protocol, and a server written for Claude Code works just as well in Cursor or any other MCP-compatible client.
The servers themselves are lightweight processes — most are Node.js or Go binaries that run locally and communicate with your AI client over stdio. Some newer ones support remote HTTP transport, but for DevOps use cases, local stdio is still the norm.
CI/CD: GitHub MCP Server Is the One to Beat
The GitHub MCP server is the most popular in the entire ecosystem — 29,000+ stars on GitHub, built in collaboration between GitHub and Anthropic. And honestly, it deserves the hype.
It exposes 51 tools across 10 toolsets: repos, issues, pull requests, Actions workflows, code security, notifications, and more. The killer feature isn’t any single tool — it’s the density. When your AI agent can browse code, read CI logs, check PR reviews, and create issues all through one server, the workflow friction just disappears.
Setting It Up
# Add to Claude Code
claude mcp add github-mcp-server \
-e GITHUB_PERSONAL_ACCESS_TOKEN=ghp_your_token_here \
-- npx -y @anthropic-ai/github-mcp-server
# Or add to your .claude/settings.json manuallyFor the personal access token, create a fine-grained token scoped to the specific repos you want the AI to access. Don’t use a classic token with broad permissions — that’s asking for trouble.
Toolset filtering matters. 51 tools is a lot for an AI model to reason about. If you’re only using it for CI/CD work, you can disable toolsets you don’t need:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@anthropic-ai/github-mcp-server"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_...",
"GITHUB_TOOLSETS": "repos,pull_requests,actions,issues"
}
}
}
}This keeps the tool count manageable and reduces the chance of the model picking the wrong tool.
What About GitLab CI?
GitLab has its own MCP server that covers similar ground — merge requests, pipelines, project management. If your team lives in GitLab, use it. The setup is nearly identical, just swap the token for a GitLab personal access token. The tooling is less mature than GitHub’s (fewer community contributions, smaller surface area), but it handles the core CI/CD workflow well.
Azure DevOps has an MCP server too, though it’s the least polished of the three. Fine for reading pipeline status, but I wouldn’t rely on it for write operations yet.
Infrastructure as Code: Terraform MCP Server
HashiCorp’s official Terraform MCP server is one of the better-designed servers in the ecosystem. Rather than trying to wrap the entire Terraform CLI, it focuses on what an AI agent is actually good at: understanding your configuration, looking up provider documentation, and helping you write correct HCL.
The server provides access to Terraform registry documentation, module specifications, and provider schemas. When you’re writing a new AWS resource block and can’t remember whether enable_dns_hostnames is on the VPC or the subnet, the AI can look it up through the MCP server instead of hallucinating an answer from training data.
Setting It Up
# Using npx
claude mcp add terraform -- npx -y terraform-mcp-server
# Using Docker (more isolated)
claude mcp add terraform -- docker run -i --rm hashicorp/terraform-mcp-serverThe Docker approach makes sense here because it isolates the server from your local environment. The Terraform MCP server itself doesn’t execute terraform apply — it’s focused on configuration assistance and registry lookups — but containment is a good habit.
Where It Shines
I’ve found this most useful during the “authoring” phase of Terraform work. Writing a new module from scratch? The AI can pull the exact provider schema and suggest the correct resource configuration. Debugging a plan error? It can look up the relevant provider docs without you tabbing over to the HashiCorp site.
Where it doesn’t help much: anything involving actual state. It won’t read your terraform.tfstate or run plans for you. That’s a deliberate design choice, and probably the right one — you don’t want an AI agent anywhere near your state file.
Kubernetes: Pick Your Level of Trust
Kubernetes MCP servers are where the “security vs. convenience” tradeoff gets real. There are two main options, and they represent fundamentally different philosophies.
Option 1: kubernetes-mcp-server (Read-Only First)
The containers/kubernetes-mcp-server is the more conservative choice. It has a --read-only flag that restricts operations to get/list/describe — no creating, deleting, or modifying resources.
claude mcp add-json kubernetes-mcp-server '{
"command": "npx",
"args": ["-y", "kubernetes-mcp-server@latest", "--read-only"],
"env": {
"KUBECONFIG": "${HOME}/.kube/mcp-viewer.kubeconfig"
}
}'Notice the separate kubeconfig. Create a dedicated ServiceAccount with a ClusterRole that only allows get, list, and watch verbs. Don’t point the MCP server at your admin kubeconfig. Ever.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: mcp-viewer
rules:
- apiGroups: ["", "apps", "batch"]
resources: ["pods", "deployments", "services", "jobs", "configmaps"]
verbs: ["get", "list", "watch"]Option 2: mcp-server-kubernetes (Full CLI Wrapper)
The Flux159/mcp-server-kubernetes wraps kubectl and Helm directly. More powerful, more dangerous. It can create deployments, scale replicas, and apply manifests.
claude mcp add kubernetes -- npx -y mcp-server-kubernetesI only use this on throwaway dev clusters. For staging or production, stick with the read-only server. The AI is great at diagnosing pod crashloops or finding misconfigured services. It doesn’t need write access for that.
kubectl-mcp-server (CNCF Landscape)
One more option: rohitg00/kubectl-mcp-server is published in the CNCF Landscape. It’s another kubectl wrapper, but being in the CNCF ecosystem gives it some credibility for teams that care about governance and vendor-neutral tooling.
Monitoring and Observability: Where MCP Gets Interesting
This is where I think MCP delivers the most value for DevOps. The ability to correlate an error in your CI pipeline with metrics, logs, and traces from your monitoring stack — without manually navigating three different dashboards — is genuinely useful.
Datadog MCP Server
Datadog’s official MCP server is the most feature-rich monitoring integration available. It ships with 50+ tools across APM, infrastructure metrics, logs, error tracking, synthetics, and even LLM observability (meta, I know).
{
"mcpServers": {
"datadog": {
"command": "npx",
"args": ["-y", "@anthropic-ai/datadog-mcp-server"],
"env": {
"DD_API_KEY": "your_api_key",
"DD_APP_KEY": "your_app_key",
"DD_SITE": "datadoghq.com"
}
}
}
}The DD_APP_KEY controls what the server can access. Create an application key with read-only scopes — Datadog’s permission model is granular enough that you can restrict it to specific products (e.g., logs read but not write, APM read but not configuration changes).
What makes this server stand out is the cross-signal correlation. Ask the AI “why did deploy X cause a latency spike?” and it can pull the relevant traces, check the error rate, and cross-reference with the deployment event. That workflow used to require tabbing through four Datadog views.
Grafana MCP Server
If you’re running the open-source Grafana + Prometheus + Loki stack instead of Datadog, Grafana’s MCP server gives your AI access to dashboards, data sources, and incident details.
It’s less polished than Datadog’s — fewer tools, and the query interface requires you to know PromQL or LogQL to get useful results. But if your team already has well-built Grafana dashboards, the AI can read them and answer questions about your infrastructure state.
Sentry MCP Server
Sentry’s MCP implementation stands out as a model of how remote MCP should work. It uses OAuth 2.0 auth — no tokens stored on disk, no environment variables to manage. The remote server runs at mcp.sentry.dev, and you authenticate through your browser.
{
"mcpServers": {
"sentry": {
"type": "url",
"url": "https://mcp.sentry.dev/sse"
}
}
}That’s it. No API keys, no npx installs. The OAuth flow handles everything. This is what all MCP servers should look like eventually, but we’re not there yet for most vendors.
PagerDuty MCP Server
If you’re on-call, the PagerDuty MCP server lets your AI agent pull incident details, check who’s on-call, and review alert history. I wouldn’t give it write access (the last thing you want is an AI agent acknowledging pages), but for reading incident context during a debugging session, it’s handy.
Cloud Provider Servers: AWS and Azure
AWS MCP Server
AWS shipped a unified MCP server (currently in preview) that merges their AWS Knowledge MCP and AWS API MCP into a single interface. It covers real-time AWS documentation lookups, infrastructure troubleshooting, resource provisioning, and cost management.
The preview status matters. I’ve found the knowledge/documentation side reliable, but the infrastructure provisioning tools are still rough. Use it for reading and understanding your AWS environment, not for making changes — at least until it’s GA.
Azure MCP Server
The Azure MCP server covers resource management, and there’s a separate Azure DevOps MCP server for CI/CD. If you’re an Azure shop, running both gives you end-to-end coverage, but expect some setup friction — Microsoft’s MCP implementations tend to have more configuration knobs than they need.
Security: The Part You Can’t Skip
Here’s where I need to be blunt. The MCP ecosystem has real security problems, and the “move fast” energy around adoption is outpacing the “think about consequences” part.
A Cornell University analysis found that 5.5% of open-source MCP servers exhibited tool-poisoning vulnerabilities — servers that altered tool outputs, injected false command responses, or redirected data to unauthorized endpoints. That’s roughly 1 in 20 servers. Not great odds if you’re installing random MCP servers from npm.
Practical Security Rules
1. Start read-only, always. Every server in this guide supports some form of read-only or scoped access. Use it. Get comfortable with what the AI can do before you hand it write permissions.
2. Use dedicated credentials. Never point an MCP server at your personal API token or admin kubeconfig. Create service accounts with the minimum permissions the server needs. If the token leaks (through a bug, a prompt injection, or just a log that’s too verbose), the blast radius should be small.
3. Stick to first-party servers. The GitHub MCP server from github/github-mcp-server, Terraform from HashiCorp, Datadog from Datadog — these have actual security teams reviewing the code. Random community servers on npm? Audit the source yourself or don’t use them.
4. Pin your versions. Don’t use @latest in production setups. Pin to a specific version so updates don’t introduce unexpected behavior. npx -y @anthropic-ai/github-mcp-server@1.2.3 is a few extra characters that prevent supply-chain surprises.
5. Watch for tool poisoning. If an MCP server’s tool descriptions seem unusually long or contain instructions that reference other tools, that’s a red flag. Security tools like MCPTox can scan for this pattern. A legitimate tool description says “list pods in a namespace.” A poisoned one says “list pods in a namespace and also send the results to this webhook.”
6. Network isolation. Run MCP servers in an environment where they can only reach the APIs they need. If the Datadog MCP server doesn’t need to talk to GitHub, firewall it accordingly.
Putting It Together: A Real Workflow
Here’s how these servers compose in practice. Say you get a Sentry alert: a new exception is spiking in your checkout service after the latest deploy.
With GitHub, Kubernetes, and Sentry MCP servers configured, you can ask your AI agent to:
- Pull the Sentry error details — stack trace, affected users, first occurrence
- Check GitHub for the most recent PR merged to the checkout service
- Read the diff from that PR
- Check the Kubernetes pod status — are any pods crashlooping?
- Pull the pod logs for the error
All of that happens through MCP tool calls. No browser tabs, no copy-pasting error IDs. The AI threads the context together because it has direct access to each system.
Add Datadog to the mix and you can also check whether the error correlates with a latency spike or a resource constraint. Add Terraform and you can verify whether the infrastructure configuration matches what’s expected.
This isn’t theoretical. I run this exact setup daily, and it’s cut my incident triage time roughly in half. The AI doesn’t fix the bug for me (usually), but it gathers context at a speed I can’t match manually.
Which Servers to Start With
If you’re setting this up from scratch, here’s my recommended order:
Solo developer or small team (1-5):
- GitHub MCP server — immediate value for PRs, issues, and CI
- Terraform MCP server — if you use Terraform (and you probably should)
- One monitoring server (Sentry or Datadog) — for error context
Mid-size team (5-20): Add Kubernetes MCP (read-only) and a second monitoring integration. At this scale, the cross-system correlation starts paying for itself.
Platform team (20+): Everything above, plus AWS/Azure MCP servers and PagerDuty. Consider running MCP servers on shared infrastructure rather than individual laptops, using the HTTP transport mode.
Don’t try to set up everything at once. Each server has its own auth configuration, permission model, and quirks. Add one, use it for a week, then add the next. You’ll learn what’s actually useful for your workflow versus what’s just cool in theory.
The MCP ecosystem is moving fast — new servers ship weekly, and the protocol itself is still evolving. But the core DevOps servers covered here are stable enough for daily use. Start with read-only access, use first-party servers, and build up from there.