DevOps is where MCP servers get serious. These aren’t read-only tools querying documentation or fetching search results — they manage infrastructure, deploy containers, modify cloud resources, and trigger CI/CD pipelines. One bad tool call can take down production.
That risk is also why DevOps MCP servers add the most value. Infrastructure management involves remembering exact CLI flags, translating between YAML dialects, and context-switching between cloud consoles. An AI agent with direct access to your infrastructure APIs can handle the tedious parts while you focus on architecture decisions.
The category has matured fast. Docker, HashiCorp, AWS, Microsoft, Cloudflare, and the Kubernetes community all ship official MCP servers now. We’ve reviewed the GitHub MCP server (4.5/5), Cloudflare MCP server (4.5/5), Docker MCP server (3.5/5), AWS MCP servers (4/5), Kubernetes MCP server (4/5), Terraform MCP server (4/5), and Pulumi MCP server (3.5/5). Here’s how the rest of the DevOps landscape compares.
The Contenders
| Server | Domain | Maintainer | Transport | Auth Model | Tools | Free Tier | Best For |
|---|---|---|---|---|---|---|---|
| Cloudflare MCP | Cloud infra | Cloudflare (official) | Remote (Streamable HTTP) | OAuth / API token | 2 (Code Mode) + 16 servers | Yes (Workers free) | Cloudflare platform management |
| Docker MCP | Containers | Docker (official) | Local (Desktop) | Docker Desktop | Catalog (300+) | Yes (Desktop) | Container management + MCP server discovery |
| Kubernetes MCP | Cluster mgmt | Red Hat / Community | stdio, SSE, HTTP | kubeconfig | 15+ (6 toolsets) | Yes (any cluster) | Kubernetes operations |
| Terraform MCP | IaC | HashiCorp (official) | Both (stdio + HTTP) | HCP token | 35+ | Yes (registry) | Infrastructure as code (docs) |
| Pulumi MCP | IaC | Pulumi (official) | Both (stdio + HTTP) | OAuth / Pulumi token | 11+ | Yes (registry/CLI) | Infrastructure as code (execution) |
| AWS MCP | Cloud infra | AWS Labs (official) | Local (stdio) + Remote (Knowledge, preview) | AWS credentials | 66 servers | Yes (free tier) | AWS resource management |
| Azure DevOps MCP | DevOps platform | Microsoft (official) | Local + Remote (planned) | OAuth / PAT | 30+ | Yes (5 users) | Azure DevOps workflows |
Also relevant: Our GitHub MCP server review (4.5/5) covers Actions-based CI/CD, pull request automation, and repository management. GitHub’s MCP server is the strongest CI/CD option in the ecosystem.
Three DevOps Layers
DevOps MCP servers operate at different layers of the stack. Understanding which layer you need matters more than comparing tool counts.
1. Container & Orchestration (Docker, Kubernetes)
These servers manage the runtime environment — building images, running containers, managing pods, scaling deployments. Docker handles single-machine containers; Kubernetes handles cluster orchestration.
When to use this layer: You’re debugging a failing container, scaling a deployment, checking pod logs, or managing Docker images. Your agent interacts with the runtime directly.
2. Infrastructure as Code (Terraform, AWS)
These servers manage the infrastructure itself — provisioning cloud resources, writing IaC configurations, querying provider documentation. Terraform works across clouds; AWS MCP is AWS-specific but deeper.
When to use this layer: You’re provisioning new infrastructure, looking up Terraform provider docs, managing AWS resources, or writing IaC modules. Your agent helps you define and modify infrastructure declarations.
3. DevOps Platform (Azure DevOps, GitHub)
These servers manage the development workflow — work items, pipelines, pull requests, builds. They’re the orchestration layer that ties code changes to deployments.
When to use this layer: You’re managing sprints, triggering CI/CD pipelines, reviewing build failures, or coordinating releases. Your agent manages the software delivery process.
The Servers in Detail
Docker MCP — The Container & Discovery Platform
Docker MCP Catalog and Toolkit | Official
Docker’s MCP play is bigger than a single server — it’s an entire ecosystem. The MCP Catalog hosts 300+ verified MCP server images on Docker Hub, each containerized, signed, and shipped with an SBOM. The MCP Toolkit is a management layer inside Docker Desktop that lets you browse, install, configure, and run MCP servers in sandboxed containers.
The standout feature is Dynamic MCP: AI agents can search the catalog and add new MCP servers mid-conversation. Instead of pre-configuring every tool, your agent discovers and installs the tools it needs on the fly. Each server runs in a container limited to 2GB memory with no host filesystem access by default.
For container management itself, Docker’s MCP server handles image building, container lifecycle, network management, and volume operations — the standard Docker workflow exposed as MCP tools.
Strengths: 300+ verified server catalog, Dynamic MCP for on-demand tool discovery, containerized sandboxing (2GB memory limit, no host access), signed images with SBOMs, profile-based organization for different projects.
Weaknesses: Requires Docker Desktop (not available on servers/CI), catalog is a discovery layer rather than a deep management tool, Dynamic MCP adds setup latency, desktop-only means no headless automation.
Best for: Developers who use Docker Desktop and want a curated, secure way to discover and manage MCP servers alongside container operations.
Kubernetes MCP — Cluster Operations via Natural Language
containers/kubernetes-mcp-server | Red Hat / Community | Full review (4/5)
The Kubernetes MCP ecosystem is fragmented — there are at least six implementations on GitHub. The most mature is Red Hat’s containers/kubernetes-mcp-server, a Go-native binary that talks directly to the Kubernetes API server (not just wrapping kubectl). 1,300 stars, 285 forks, 747 commits, 58 releases. Other notable options include Flux159/mcp-server-kubernetes (1,300 stars, TypeScript, kubectl wrapper), rohitg00/kubectl-mcp-server (821 stars, 235+ tools including non-K8s features), and strowk/mcp-k8s-go (440 stars, resource-focused).
Red Hat’s implementation organizes capabilities into 6 modular toolsets: core (pods, resources, events, nodes, metrics), config (kubeconfig, context switching), Helm (chart install/uninstall/list), KubeVirt (VM management), Kiali (service mesh observability), and KCP (multi-tenant workspaces). Enable only what you need with --toolsets core,config,helm.
The safety model is the strongest in the Kubernetes MCP space: --read-only prevents all writes, --disable-destructive blocks deletes/updates while allowing creates, denied resource lists block access to sensitive types like Secrets, and automatic redaction strips tokens and credentials from output. Supports stdio, SSE, and Streamable HTTP transports. Distributed as native binary, npm, pip, and Docker image.
Strengths: Native Go binary (fast, no runtime dependencies), direct K8s API interaction, 6 modular toolsets, multi-cluster support, read-only and non-destructive modes, automatic secret redaction, TOML config with drop-in directory and SIGHUP reload, OpenTelemetry tracing, supports any K8s/OpenShift resource including CRDs, pod exec capability.
Weaknesses: Still v0.0.x (58 releases, API unstable), 48 open issues including a security audit with 2 findings, panic bug in pods_log, no granular read-only permissions (#568), no dedicated Job/CronJob tools (#370), OpenShift in developer preview, KubeVirt eval failures (#838).
Best for: Platform engineers who want AI-assisted Kubernetes operations with real safety controls. The modular architecture lets you start small (core + config) and add capabilities as needed.
Terraform MCP — Infrastructure as Code Intelligence
hashicorp/terraform-mcp-server | Official, Beta | Full review (4/5)
HashiCorp’s Terraform MCP server is focused on making AI agents write better Terraform configurations. Rather than managing infrastructure directly, it gives agents real-time access to the Terraform Registry — provider documentation, module specifications, Sentinel policies, and version information. 1,300 stars, 134 forks, 323 commits, 10 releases since May 2025, Go.
35+ tools across six functional areas: registry (8 tools for searching providers, modules, and policies with full documentation retrieval), HCP Terraform workspace management (12 tools for creating/updating/deleting workspaces, managing runs, and checking token permissions), private registry (4 tools for organization-specific modules and providers), variable management (9 tools for variable sets and workspace variables), policy and tags (4 tools for governance), and Stacks (2 tools for multi-component deployments).
The server includes MCP resources for the Terraform Style Guide, Module Development Guide, and dynamic provider documentation — giving agents reference material beyond just tool calls.
Setup is straightforward: Docker image (hashicorp/terraform-mcp-server:0.4.0), Go install, or one-click installers for VS Code, Cursor, Claude Desktop, and Claude Code. Registry lookups work immediately with no auth; HCP Terraform features require a TFE_TOKEN. Tool filtering via --toolsets and --tools flags controls the attack surface. Built-in rate limiting (global and per-session) protects APIs from overuse.
Strengths: Real-time provider documentation eliminates hallucinated resource arguments, comprehensive module discovery with full specs (inputs, outputs, examples, submodules), deliberate safety by design (no terraform plan/apply), tool filtering for attack surface reduction, dual transport (stdio + Streamable HTTP) with health checks and CORS, full workspace lifecycle management, Stacks support for complex deployments, rate limiting.
Weaknesses: Still beta (HashiCorp warns against production use), security audit findings (#288 — insecure TLS, unverified CI binary downloads), Terraform-only ecosystem (no OpenTofu or Pulumi), provider search returning community instead of official versions (#178), proxy/networking issues behind nginx (#267), workspace tools require HCP Terraform (no local state support), no terraform plan/apply execution (by design but limits the loop).
Best for: Teams writing Terraform configurations who want AI agents that reference current provider docs and module specifications instead of hallucinating resource arguments. Platform engineers managing HCP Terraform workspaces, variables, and policies.
Pulumi MCP — Infrastructure Execution + Neo Agent Delegation
pulumi/mcp-server | Official, v1.0.0 | Full review (3.5/5)
Where Terraform MCP stops at documentation, Pulumi’s MCP server keeps going — all the way to deployment. It connects AI assistants to the Pulumi ecosystem: registry lookups for resource schemas and code examples in real programming languages (TypeScript, Python, Go, C#, Java, YAML), CLI execution for previewing and deploying infrastructure, cross-cloud resource search, and delegation to Pulumi Neo for autonomous multi-step infrastructure tasks. 66 stars, TypeScript, Apache 2.0, v1.0.0.
11+ tools in local mode: 5 registry tools (list/get resources, functions, types), 4 CLI tools (preview, up, stack-output, refresh), resource search, and Neo task launcher. The remote endpoint at mcp.ai.pulumi.com/mcp adds cloud-specific tools: get-stacks, get-policy-violations, get-users, deploy-to-aws, plus Neo management tools (neo-bridge, neo-get-tasks, neo-continue-task, neo-reset-conversation).
Setup is minimal for remote mode — just add the HTTP endpoint and authenticate via OAuth. Local mode requires Node.js and the Pulumi CLI. The killer feature is Neo delegation: instead of your AI assistant managing individual tool calls, it can hand off complex infrastructure tasks to Pulumi Neo, which plans, generates code, tests, and creates PRs autonomously.
Strengths: Full IaC lifecycle (preview → deploy → outputs), code examples in real programming languages (not HCL), cross-cloud resource search with Lucene queries, Neo agent delegation for autonomous infrastructure tasks, dual local/remote architecture, 170+ cloud providers, policy violation detection, Terraform migration prompts.
Weaknesses: Only 66 stars (vs. Terraform’s 1,300), Neo requires Pulumi Cloud subscription, Pulumi ecosystem lock-in, AI hallucination on complex scenarios, SDK maturity varies by language, documentation gaps, deploy-to-aws prompt only covers AWS despite multi-cloud support, steep learning curve for non-Pulumi users.
Best for: Teams already using Pulumi who want AI agents with full execution capabilities. Teams that want autonomous infrastructure provisioning via Neo. Teams that prefer writing IaC in general-purpose programming languages instead of HCL.
AWS MCP — The Cloud Infrastructure Suite
awslabs/mcp | Official, Open Source | Full review (4/5)
AWS doesn’t ship one MCP server — it ships a suite of 66 specialized servers covering the breadth of AWS services. 8,500 stars, 1,400 forks, 190+ releases with daily automated CI/CD. The flagship is the AWS MCP Server (preview), a managed remote server that provides authenticated access to AWS APIs with CloudTrail audit logging and IAM-based permissions.
The Core MCP Server (~80K monthly PyPI downloads) acts as an orchestration layer, dynamically importing and proxying other servers via 16 role-based configurations (solutions-architect, dev-tools, finops, etc.). The API server provides call_aws, suggest_aws_commands, and get_execution_plan tools with READ_OPERATIONS_ONLY and REQUIRE_MUTATION_CONSENT safety controls. The Cloud Control API server enables CRUDL on any AWS resource via natural language.
The Knowledge MCP Server is the easiest entry point — a free managed endpoint at knowledge-mcp.global.api.aws with Streamable HTTP, no auth required, indexing AWS docs, blog posts, What’s New, API references, and Well-Architected guidance.
Strengths: Broadest coverage of any MCP server suite (66 servers), covers infrastructure, compute, data, AI/ML, security, cost analysis, healthcare, and more, official AWS maintenance, role-based orchestration via Core MCP, managed Knowledge endpoint, CloudTrail audit logging, Apache 2.0.
Weaknesses: Overwhelming complexity (66 servers), EKS exposes K8s secrets in plain text (#2588), 125 open issues, stdio-only on most servers (SSE removed May 2025), Cost Explorer incompatible with Bedrock AgentCore (#2442), deprecation churn (CDK, Terraform, Diagram servers deprecated), requires Python 3.12+ and uv.
Best for: Teams building on AWS who want AI agents with deep access to AWS services, documentation, and infrastructure management. Start with the Knowledge server, add specific servers as needs arise.
Azure DevOps MCP — The DevOps Workflow Hub
microsoft/azure-devops-mcp | Official, GA
Microsoft’s Azure DevOps MCP Server connects AI agents to the Azure DevOps platform — work items, pull requests, builds, pipelines, test plans, and wikis. It reached General Availability in late 2025, making it one of the most mature DevOps MCP servers.
The GA release brought improved authentication (OAuth and PAT), domain-scoping for tool management, and refined internal APIs based on preview feedback. Azure DevOps MCP is now built into Visual Studio 2026 out-of-the-box, meaning Azure users get MCP integration without any setup.
A Remote MCP Server is on the 2026 roadmap — a hosted version that eliminates the need to run a local server. The initial release will focus on core platform capabilities and work item management.
Microsoft also ships a separate Azure MCP Server for Azure cloud resources (compute, storage, databases, etc.), which is distinct from the DevOps server. Together, they cover both the development workflow and the cloud infrastructure.
Strengths: GA status (most mature in this comparison), built into Visual Studio 2026, covers work items, PRs, builds, pipelines, tests, and wikis, OAuth authentication, remote server coming in 2026, backed by Microsoft.
Weaknesses: Azure DevOps-specific (doesn’t help GitHub/GitLab users), local-only transport currently, separate from Azure cloud resource management, enterprise-focused (less relevant for small teams or startups).
Best for: Teams using Azure DevOps for project management and CI/CD who want AI-assisted workflow management directly in their IDE.
Feature Comparison
| Feature | Docker MCP | Kubernetes MCP | Terraform MCP | Pulumi MCP | AWS MCP | Azure DevOps MCP |
|---|---|---|---|---|---|---|
| Container mgmt | Deep | Via pods | No | No | Via ECS/EKS | No |
| Cluster ops | No | Deep | No | No | Via EKS | No |
| IaC | No | No | Deep (35+ tools, docs only) | Deep (11+ tools, execution) | Via CDK/CFn | No |
| Cloud resources | No | No | HCP workspaces | Resource search (all clouds) | Deep (60+ servers) | Azure resources (separate server) |
| CI/CD | No | No | No | No | Via CodePipeline | Deep (pipelines + builds) |
| Work items | No | No | No | No | No | Deep |
| Documentation | Catalog | No | Registry docs | Registry docs + code examples | Knowledge server | Wiki |
| AI agent delegation | No | No | No | Yes (Neo) | No | No |
| Auth model | Docker Desktop | kubeconfig | HCP token | OAuth / Pulumi token | AWS credentials | OAuth / PAT |
| Transport | Local | Local (stdio) | Both | Both | Local (stdio) | Local (remote planned) |
| Status | GA | Active | Beta | v1.0.0 | Active | GA |
| Open source | Partial | Yes | Yes | Yes (Apache 2.0) | Yes | Yes |
How to Choose
Start with your existing stack. DevOps MCP servers are tightly coupled to their platforms. There’s no point installing the Terraform MCP server if you use Pulumi, or the Azure DevOps server if you’re on GitHub.
Decision Flowchart
“I write Terraform all day” → Terraform MCP (4/5). Your agent references current provider docs instead of hallucinating resource arguments. Pair with AWS MCP or Azure MCP for direct resource management.
“I use Pulumi and want autonomous infrastructure” → Pulumi MCP (3.5/5). Registry lookups, CLI execution, and Neo agent delegation. The only IaC MCP server that can actually deploy infrastructure.
“I manage Kubernetes clusters” → Kubernetes MCP (Red Hat’s containers/kubernetes-mcp-server). Start in read-only mode for safety. Add k8s-mcp-server if you need Helm and ArgoCD.
“I’m all-in on AWS” → AWS MCP suite. Start with the Knowledge server (documentation) and Cloud Control API (resource management). Add specialized servers as needed.
“I use Azure DevOps for project management” → Azure DevOps MCP. GA, built into VS 2026, covers the full DevOps workflow. Add Azure MCP Server for cloud resource management.
“I want to discover and manage MCP servers themselves” → Docker MCP Toolkit. The catalog and Dynamic MCP features are unique — no other tool lets agents discover and install MCP servers on the fly.
“I need CI/CD automation” → GitHub MCP Server (4.5/5). It’s the strongest CI/CD option in the ecosystem, covering Actions workflows, build logs, and deployment management.
The Stack We’d Recommend
Most DevOps teams need servers at two layers:
- An infrastructure server — Terraform MCP (multi-cloud IaC docs), Pulumi MCP (multi-cloud IaC execution), AWS MCP (AWS-specific), or Azure MCP (Azure-specific)
- A workflow server — GitHub MCP (CI/CD + code), Azure DevOps MCP (enterprise DevOps), or Kubernetes MCP (cluster ops)
Add Docker MCP Toolkit if you want managed, sandboxed MCP server discovery. It’s more of a meta-tool than a DevOps tool, but it solves a real problem — securely running MCP servers without trusting random npm packages.
Safety Warning
DevOps MCP servers can modify production infrastructure. Before connecting any of these to a real environment:
- Use read-only modes where available (Kubernetes MCP supports this)
- Scope credentials tightly — least-privilege IAM roles for AWS, read-only PATs for Azure DevOps
- Start with non-production — connect to staging clusters and dev accounts first
- Review before applying — Terraform MCP deliberately doesn’t run
terraform applyfor this reason
The most dangerous MCP server is one with broad write access to production infrastructure and no human review step. Don’t be that team.
The Bigger Picture
DevOps is the fastest-growing MCP server category. A year ago, none of these servers existed. Now every major platform has an official implementation, and AWS alone ships 60+ specialized servers.
The trend we’re watching: the split between documentation-first and execution-first IaC servers. Terraform MCP and AWS Knowledge MCP focus on helping agents write correct configurations rather than executing changes directly — a deliberate safety choice. Pulumi MCP takes the opposite approach with pulumi up and Neo agent delegation, betting that AI-driven execution with proper guardrails (review modes, policy enforcement) is the future. Both approaches have merit — the industry is still learning which failure mode is more costly: agents that can’t close the loop, or agents that close it too aggressively.
Kubernetes MCP splits the difference with execution-capable servers that offer read-only and non-destructive safety modes. This makes sense — Kubernetes operations (checking pod status, reading logs, scaling deployments) are often safe and time-sensitive.
For related tools, see our reviews of the GitHub MCP server (4.5/5) for CI/CD, and our comparison guides for databases, observability, and productivity.