Best MCP Servers for DevOps in 2026: 7 Official Servers, Read-Only First

I get asked the same question every few weeks now: which MCP servers should a DevOps team actually connect to its coding agents? The honest answer is fewer than you think, and almost all of them should start read-only. This post walks through the best MCP servers for DevOps in late 2026, limited to ones maintained by the vendor that owns the API: GitHub, Kubernetes, AWS, Terraform, Grafana, Sentry and Datadog. For each I cover what it exposes, the current version, the switch that makes it read-only, and where it can still hurt you. If you need the basics of the protocol first, start with what MCP is. If you want the client wiring, the sibling post is how to connect MCP servers to Claude Code, Cursor and VS Code.

What makes an MCP server good for DevOps work?

An MCP server is a thin adapter between an agent and an API. For infrastructure that API usually has blast radius, so I judge servers on four things before I care about tool count.

1. Who maintains it. A server from the vendor tracks API changes and gets security fixes. A weekend wrapper around kubectl from a random npm account does not, and it runs with your credentials.
2. A read-only mode that is enforced server-side. Prompting the model to "only read" is not a control. A flag that stops write tools from being registered at all is.
3. Tool filtering. Every tool definition costs context and gives the model another way to do something surprising. Servers that let you pick toolsets are easier to reason about.
4. Credentials you can scope. OAuth against the vendor, or a token you can mint with narrow permissions, beats a long-lived admin key in a JSON file.

The protocol itself has matured. The current spec revision is 2026-07-28, and servers are starting to depend on it: GitHub's v2.0.0 release on 6 October 2026 added typed output schemas that are only advertised to clients claiming 2026-07-28 support. What has not matured evenly is the ecosystem around the servers, which is the point of my longer MCP security write-up.

The 7 official DevOps MCP servers compared

Versions and star counts below come from the GitHub API on 31 October 2026 (gh api repos/OWNER/REPO/releases/latest), or from the vendor docs where there is no public repo.

Server	Maintainer	Latest release	Transport	Read-only control	Stars
GitHub MCP Server	GitHub	v2.0.3 (21 Oct 2026)	Remote HTTP or local stdio	--read-only, X-MCP-Readonly header, /readonly URL	34,107
awslabs/mcp	AWS	2026.10.20261030201955	stdio only	READ_OPERATIONS_ONLY (API server), read-only default (EKS)	9,853
Grafana MCP	Grafana Labs	v2.1.1 (20 Oct 2026)	stdio or HTTP	--disable-write	3,630
Kubernetes MCP Server	containers org	v0.1.1 (29 Oct 2026)	stdio or HTTP	read_only / disable_destructive in TOML	2,208
Terraform MCP Server	HashiCorp	v1.4.1 (23 Oct 2026)	stdio, HTTP, hosted	ENABLE_TF_OPERATIONS=false (default)	1,556
Sentry MCP	Sentry	npm @sentry/mcp-server 0.42.0	Remote HTTP (OAuth), stdio	skills filter, token scopes	952
Datadog MCP Server	Datadog	Hosted, no public release	Remote HTTP only	mcp_write permission, omit_tools	n/a

GitHub MCP server: the one everyone installs first

GitHub's server is the most used in this list by a wide margin, and it is also the one with the best documented attack. The hosted endpoint is https://api.githubcopilot.com/mcp/, with OAuth or a personal access token. If you pass no toolsets you get the default set: context, repos, issues, pull_requests and users. For DevOps work I add actions (workflow runs and logs) and sometimes code_security and dependabot.

The controls are good. Locally, --read-only registers only read tools, and the README is explicit that read-only wins even if you request a write tool by name. On the remote server you can append /readonly to any toolset URL or send X-MCP-Readonly: true, and choose toolsets with X-MCP-Toolsets, all documented in the remote server guide.

The risk is not writes, it is reads. In May 2025 Invariant Labs showed that a malicious issue in a public repo could steer an agent into copying private repository data into a public pull request. GitHub's answer is lockdown mode (--lockdown-mode or X-MCP-Lockdown), which hides public content from authors without push access. The README says plainly that it is a best-effort content filter and "not an authorization boundary". Treat it as a seatbelt, and keep the token scoped to the repositories the task needs.

Kubernetes MCP server: native client, now configured by TOML

The containers/kubernetes-mcp-server project is the one I point people at for clusters. Its README says it is not a wrapper around kubectl or helm and talks to the API directly. It supports Kubernetes and OpenShift, multiple kubeconfig contexts, and toolsets such as core, config, helm, kubevirt, kiali and observability toolsets for Prometheus, Alertmanager and Loki.

One thing changed this week that will break copied configs. Version 0.1.0 shipped on 29 October 2026 and the CLI no longer accepts runtime flags: --read-only became read_only in TOML, --disable-destructive became disable_destructive, and --port became port. Old README snippets with --read-only in args will fail. The TOML file also supports denied_resources, which I use to block Secrets outright.

Two cautions. The server acts with whatever your kubeconfig context can do, so the real control is a dedicated ServiceAccount with a read-only ClusterRole, which I cover in Kubernetes RBAC explained. And the config toolset includes configuration_view, which returns kubeconfig content. Leave that toolset off unless you need context switching.

AWS MCP servers: awslabs/mcp and the managed AWS MCP Server

AWS publishes a monorepo, awslabs/mcp, whose src/ directory had 63 entries when I listed it. The README states these servers support stdio only, and that SSE was removed from their latest major versions on 26 May 2025. Two of them have been marked deprecated: the Cloud Control API server (replaced by the AWS IaC MCP server) and the IAM server. AWS also lists a remote, managed AWS MCP Server, labelled "in preview" in the repo, which combines API access with documentation and IAM-based permissions. I could not load its documentation page while writing, so I have not verified its pricing or region list.

For day-to-day DevOps the useful ones are:

• AWS API MCP Server (PyPI awslabs.aws-api-mcp-server 1.6.0). It runs validated AWS CLI commands. Set READ_OPERATIONS_ONLY=true to allow only commands on a known read-only list, or REQUIRE_MUTATION_CONSENT=true to make the server ask before any write through MCP elicitation. Its README warns that some read-only AWS operations can still return credentials, and that the server has no sandbox: file access is confined to a working directory by default, but only for paths passed directly in a command.
• Amazon EKS MCP Server. Read-only by default. --allow-write enables mutations and --allow-sensitive-data-access enables logs, events and Secrets.
• CloudWatch, Managed Prometheus, Pricing and Billing servers for the observability and FinOps questions agents are actually good at.

The real permission boundary is IAM, not the flag. Run these with a profile that assumes a ReadOnlyAccess-style role, as described in AWS IAM explained.

Terraform MCP server: registry docs by default, workspace ops on request

HashiCorp's Terraform MCP Server is useful even with no credentials. Without a token it reads the public Terraform Registry: providers, modules and policies. That alone fixes the most common failure of agents writing HCL, which is inventing arguments for a provider version that does not have them.

With TFE_TOKEN it can manage HCP Terraform and Terraform Enterprise workspaces, variables, tags and runs. Tools that need explicit approval stay off until you set ENABLE_TF_OPERATIONS=true; the default is false. HashiCorp also runs a hosted endpoint at https://mcp.terraform.io/mcp, and for self-hosted HTTP deployments there is MCP_ORGANIZATION_ALLOWLIST to restrict which HCP Terraform organisations can be reached. The server is MPL-2.0. Note the README's own warning: the server can expose Terraform data to the LLM, so do not use it with untrusted clients.

Observability MCP servers: Grafana, Sentry and Datadog

This is where MCP pays for itself during incidents, because the questions are reads: what changed, which query spikes, which error started at 14:02.

Grafana. mcp-grafana v2.1.1 covers dashboards, PromQL and LogQL queries, Loki patterns, alert rules, Grafana Incident and OnCall. Many tool groups (SQL, CloudWatch, Elasticsearch, admin) are off by default. --disable-write gives a read-only server, and --disable-<category> drops whole groups. Authenticate with a service account token. The README suggests the built-in Editor role for convenience; I would rather grant datasources:query on the two datasources the agent needs.

Sentry. The Sentry MCP server (its repository was recently renamed from getsentry/sentry-mcp to getsentry/toolkit) is primarily a hosted service at https://mcp.sentry.dev/mcp using OAuth, and Sentry says it is designed for human-in-the-loop coding agents rather than as a general Sentry API. You can narrow it with ?skills=inspect,triage or ?disable-skills=seer. The stdio mode for self-hosted Sentry needs a user token, and the scopes it documents include project:write, team:write and event:write, so it is not read-only by construction.

Datadog. The Datadog MCP Server is remote only, at https://mcp.datadoghq.com/v1/mcp for US1 (EU1 uses mcp.datadoghq.eu). Toolsets are chosen with ?toolsets=, with core as the default and all meaning every generally available toolset. Write tools require the mcp_write permission plus the matching resource permission (such as monitors_write), an org admin can disable MCP write access entirely, and every call lands in Audit Trail. Datadog documents fair-use limits of 50 requests per 10 seconds and 100,000 tool calls per month, and still describes the server as "under significant development".

How to run DevOps MCP servers read-only

Here is the project-scoped .mcp.json I would start a platform team with. The same mcpServers format works in Claude Code and in VS Code's portable .mcp.json; Cursor uses the same shape in .cursor/mcp.json with ${env:NAME} variables instead. Every server is pinned and read-only, and secrets come from the environment.

{
  "mcpServers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${GITHUB_MCP_PAT}",
        "X-MCP-Toolsets": "repos,issues,pull_requests,actions",
        "X-MCP-Readonly": "true",
        "X-MCP-Lockdown": "true"
      }
    },
    "kubernetes": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "kubernetes-mcp-server@0.1.1", "--config", "${HOME}/.config/k8s-mcp/readonly.toml"]
    },
    "aws": {
      "type": "stdio",
      "command": "uvx",
      "args": ["awslabs.aws-api-mcp-server@1.6.0"],
      "env": {
        "AWS_API_MCP_PROFILE_NAME": "readonly",
        "AWS_REGION": "eu-west-1",
        "READ_OPERATIONS_ONLY": "true"
      }
    },
    "terraform": {
      "type": "stdio",
      "command": "docker",
      "args": ["run", "-i", "--rm", "hashicorp/terraform-mcp-server:1.4.1"]
    },
    "grafana": {
      "type": "stdio",
      "command": "uvx",
      "args": ["mcp-grafana@2.1.1", "--disable-write"],
      "env": {
        "GRAFANA_URL": "${GRAFANA_URL}",
        "GRAFANA_SERVICE_ACCOUNT_TOKEN": "${GRAFANA_SA_TOKEN}"
      }
    },
    "sentry": {
      "type": "http",
      "url": "https://mcp.sentry.dev/mcp?skills=inspect"
    }
  }
}

And the TOML file the Kubernetes server reads, since flags no longer work from v0.1.0:

# ~/.config/k8s-mcp/readonly.toml  (kubernetes-mcp-server 0.1.1)
read_only = true                 # register read tools only
disable_destructive = true       # belt and braces if read_only is ever flipped
toolsets = ["core", "helm"]      # no "config": it can print kubeconfig content

# Never return Secrets, whatever RBAC allows
[[denied_resources]]
group = ""
version = "v1"
kind = "Secret"

The flags are the second line of defence. The first is the identity behind each server: a fine-grained GitHub token for named repos, a Kubernetes ServiceAccount bound to view, an AWS role with read-only policies, a Grafana service account with query rights on specific datasources. If the agent goes wrong, the identity decides how wrong it can go. This is ordinary platform engineering, and it matters more with agents, not less.

FAQ

What is the best MCP server for DevOps?

For most teams it is the GitHub MCP server, because pull requests, issues and Actions logs are where DevOps work already happens. Add the Kubernetes and Grafana servers next for incident work. Run all three read-only until you have a reason not to.

Are official MCP servers safe to use in production?

They are safer than unofficial ones, but none of them is an authorization boundary on its own. The credential you give the server decides what it can do, and prompt injection through data the server reads (issues, logs, alert text) is still possible. Use scoped credentials, read-only modes and toolset filters together.

Does the AWS MCP server support remote HTTP?

The open source servers in awslabs/mcp support stdio only, according to the repository README, and SSE was removed in May 2025. AWS separately offers a managed, remote AWS MCP Server, which the repo lists as in preview. For local use, run the stdio servers with uvx and a read-only AWS profile.

Why did my Kubernetes MCP server stop accepting --read-only?

Version 0.1.0 of containers/kubernetes-mcp-server, released on 29 October 2026, moved runtime settings to TOML. Put read_only = true in a TOML file and pass it with --config (or point MCP_CONFIG_PATH at it); there is no environment variable for read_only itself. Pin the version in your config so the next change does not surprise you.

This quarter I would connect GitHub, Kubernetes and Grafana read-only for the platform team, behind identities created specifically for the agent, and add Terraform for its registry lookups since that needs no credentials at all. I would hold off on write access anywhere until we have audit logs we actually read. I build PandaStack, a microVM cloud for running agent code, so I am biased towards isolation, but the advice above holds whether or not you ever use it.

Related: What Is MCP (Model Context Protocol)? A Plain-English Guide for 2026, MCP Security in 2026: The Protocol Got Hardened. The Ecosystem Didn't. and MCP in 2026: 475M SDK Downloads a Month, 39,492 Servers in a Registry Still in Preview, and 12 Gateways Selling the Same 3 Features.