MCP Directory

Best MCP servers for DevOps & infrastructure

Close-up of tower servers in a data center with blue and red lighting.
Photo: panumas nikhomkhai / Pexels

Short answer

Pick the official server for your stack — GitHub for CI, Kubernetes for clusters, Terraform for IaC, your cloud's own server (AWS) for everything else. But the pick matters less than the discipline: never point an agent at prod, and gate anything irreversible (an apply, a delete, a deploy) behind explicit human approval.

DevOps is where 'the model did something irreversible' stops being a funny story. People wire an agent straight to production because the sandbox is annoying to set up — that's the actual risk, not the server choice. So my recommendations come with a non-negotiable: every infra server runs against a sandbox/staging context by default, and irreversible actions are human-gated. Pick official servers here specifically because they tend to ship the safety rails community ones skip.

The picks

1

GitHub MCP Server

31k· stdio· apikey

The backbone of most pipelines. Official, handles repos/Actions/issues, and it's the safest CI surface to give an agent.

Config & setup
2

Kubernetes MCP Server

1.4k· stdio· no auth

For cluster operations. Start it read-only / against a non-prod context; let the agent diagnose before it ever touches a live cluster.

Config & setup
3

Terraform MCP Server

1.4k· stdio· no auth

HashiCorp's own, for infrastructure-as-code. Let the agent plan freely, but gate `apply` behind a human every time.

Config & setup
4

AWS API MCP Server

9.3k· stdio· apikey

AWS Labs' official server — covers the long tail of AWS via the CLI surface. Scope its IAM tightly; broad cloud creds in an agent is the scariest combination there is.

Config & setup
5

Docker Hub MCP Server

250· stdio· apikey

Official Docker Hub server for image workflows. Useful and low-risk compared to the cluster/cloud servers above.

Config & setup

What to skip

Avoid handing an agent production credentials to skip sandbox setup — that's the single biggest DevOps MCP mistake. Avoid broad-scope cloud keys; create a narrowly-scoped role. And avoid community infra servers that don't support a read-only/dry-run mode — for infrastructure, that's a dealbreaker.

FAQ

Is it safe to let an AI agent manage my infrastructure via MCP?

Only with guardrails: run against staging by default, use narrowly-scoped credentials, and gate every irreversible action (terraform apply, kubectl delete, deploys) behind explicit human approval. Prefer official servers — they tend to ship these rails.

What's the best MCP server for Kubernetes?

A Kubernetes MCP server run read-only against a non-production context first, so the agent can diagnose before it can change anything. Promote to write access only once you've watched it behave.