AWS, Azure & Cloud MCP Servers
MCP servers and Skills that connect your agent to cloud platforms and infrastructure - AWS, Azure, GCP, Docker, Kubernetes, and Terraform.
What is a cloud & infrastructure MCP server?
Cloud & Infrastructure MCP servers connect an agent to cloud platforms (AWS, Azure, GCP), container tooling (Docker), orchestration (Kubernetes), and infrastructure-as-code (Terraform) — giving it visibility into real infrastructure state and, in some cases, the ability to propose or apply changes. Depending on the specific server, this ranges from purely descriptive tools (list resources, describe current state, show a Terraform plan) to tools that can actually apply a change — provisioning, scaling, or tearing down real infrastructure — which is why checking a listing's read/write posture matters more here than in most other categories.
Why give your agent cloud & infrastructure access?
Infrastructure work involves a lot of context an agent can't get from a chat message alone: what's actually running, what a Terraform plan will change, what a Kubernetes cluster's current state looks like. A Cloud & Infrastructure MCP server gives an agent that live visibility, which is what makes it useful for things like debugging a failing deployment or reviewing an infrastructure change before it ships, rather than working from a stale description. Concretely, this means an agent debugging a failing deployment can check the actual pod status and recent events in Kubernetes rather than working from a description of the symptoms, or review exactly what a Terraform plan will change before anyone runs apply, catching an unintended resource deletion before it happens rather than after.
What to check before you install one
Infrastructure access is high-stakes almost by definition, so scope matters more here than in most categories. Check whether a server defaults to read-only (inspecting state, listing resources) versus having apply/write access to real infrastructure, and prefer servers that require explicit confirmation before anything that could take down a running service. Authentication is usually via your cloud provider's own credentials (an AWS IAM role, an Azure service principal) — use the most restricted-scope credential that still does the job. It's also worth checking whether a server supports scoping to a specific resource group, project, or namespace rather than your entire account — the ability to limit an agent to one environment (staging, not production) is a meaningful safety boundary worth confirming before connecting it to anything live. Given the stakes involved, it's worth treating the read/write decision as something to revisit, not a one-time setting — many teams start read-only while building trust in an agent's behavior, then selectively enable write access once they've seen how it actually performs.
Which of the 5 listed cloud & infrastructure servers should you use?
AWS MCP Servers and Azure MCP Server are both official, platform-specific servers — pick based on which cloud you actually run on, since neither covers the other's platform. AWS MCP Servers is technically a collection of specialized servers (core, plus service-specific ones like documentation and cost tools) rather than one monolithic server, so you can install only the pieces you need. Terraform MCP Server is different in kind — it's not about a specific cloud provider, but about the Terraform Registry and Terraform Cloud/Enterprise data, useful regardless of which cloud your Terraform code actually targets. Kubernetes MCP Server is similarly cloud-agnostic — it talks to the Kubernetes API directly rather than shelling out to kubectl, so it works the same whether your cluster runs on AWS, Azure, GCP, or on-premises. Docker MCP Gateway solves a different problem entirely: instead of connecting an agent to infrastructure, it runs other MCP servers as isolated Docker containers rather than directly on your host, worth adding specifically if you're running third-party or less-trusted MCP servers and want container isolation between them and your machine. Most infrastructure work will combine two or three of these — a cloud-specific server for the platform itself, plus Terraform or Kubernetes for the infrastructure layer on top. If you're managing infrastructure across more than one cloud, expect to run the platform-specific server for each one you use, plus Terraform or Kubernetes if your infrastructure-as-code or orchestration layer spans across them.