Kubernetes MCP Server: Letting an Agent Inspect a Cluster Safely

A Kubernetes MCP server lets an AI agent list pods, read events and logs, and describe resources in your cluster, and, if you allow it, apply manifests, run commands in pods and delete things. For any cluster, the most complete option is the open-source containers/kubernetes-mcp-server, which talks to the Kubernetes API directly. The three big clouds each have their own: a managed Amazon EKS MCP server in preview, a remote GKE server from Google with a separate read-only endpoint, and Microsoft’s open-source AKS-MCP. Whichever you pick, the safe setup is the same: start read-only, run as a dedicated service account bound to the built-in view role, give the server a kubeconfig with one context in it, and keep destructive tools switched off. The server’s read-only mode stops the model from asking; RBAC stops the cluster from obeying.

The options, as documented today

• Any cluster: the kubernetes-mcp-server project↗ (opens in a new tab) in the containers organization, a Go binary also shipped through npm, PyPI and a container image, for Kubernetes and OpenShift. It calls the API server itself rather than wrapping kubectl, groups its tools into toolsets (core and config on by default; helm, kubevirt, tekton, kiali and others optional) and supports several clusters at once from your kubeconfig.
• Amazon EKS: AWS’s EKS MCP Server getting started guide↗ (opens in a new tab) describes a fully managed server, in preview and subject to change, reached through the mcp-proxy-for-aws proxy, which signs requests with your AWS credentials. IAM decides access, with an AmazonEKSMCPReadOnlyAccess managed policy for read-only tools, and the proxy takes --read-only. The open-source awslabs EKS server still exists and runs read-only by default, with --allow-write and --allow-sensitive-data-access for writes and for logs, events and Secrets.
• Google GKE: a remote server at https://container.googleapis.com/mcp, enabled with the Kubernetes Engine API. Its MCP reference↗ (opens in a new tab) lists three toolset endpoints: /mcp, which reads and also creates, updates, patches and applies manifests; /mcp/read-only; and /mcp/delete-tools, which deletes clusters and node pools. Google’s how-to page describes the server as read access, but the reference shows write tools on the default endpoint, so choose /mcp/read-only on purpose. A separate local server, gke-mcp, is on GitHub.
• Azure AKS: AKS-MCP↗ (opens in a new tab), Microsoft’s open-source server, now supported only as a local stdio process under your own az login. It runs az, kubectl, helm, cilium and hubble commands, and its --access-level is readonly by default, with readwrite and admin above it. The Azure MCP Server also covers AKS among dozens of Azure services, as the Azure MCP server guide explains.

The AKS-MCP README says the quiet part plainly: --access-level is a guardrail against an assistant that misreads a request, not a security boundary, and anyone who can call the server effectively holds the full privileges of the identity it runs as. That is true of every server on this list. The flags reduce accidents; the identity’s permissions are the limit. The EKS side of AWS is covered in more depth in the AWS MCP server guide.

Read-only mode

On kubernetes-mcp-server, read-only mode now lives in a TOML file. The project dropped its runtime command-line flags, so older guides that pass --read-only or --toolsets no longer work; only --config and --config-dir remain. With read_only = true, the server exposes only tools annotated as read-only. A starting file for an agent that should only look:

read_only = true
toolsets = ["core"]

# Never show Secrets, even if RBAC would allow it
[[denied_resources]]
group = ""
version = "v1"
kind = "Secret"

Dropping the default config toolset removes the tools that view and switch kubeconfig contexts. denied_resources blocks whole resource kinds by group, version and kind; the project’s own example also denies RBAC objects. If you later allow writes, disable_destructive = true keeps tools annotated as destructive, such as deletes and updates, switched off.

RBAC with a dedicated service account

Do not hand the server your own kubeconfig. The project’s Kubernetes setup guide creates a service account for the agent and binds it to the built-in view role. The Kubernetes RBAC documentation↗ (opens in a new tab) explains why that role is a good fit: it allows read-only access to most objects in a namespace, but not roles or role bindings, and not Secrets, because reading Secrets would expose service account credentials and let a reader act as any service account in the namespace.

kubectl create namespace mcp
kubectl create serviceaccount mcp-viewer -n mcp

# Read-only in the one namespace the agent should see
kubectl create rolebinding mcp-viewer-view \
  --clusterrole=view --serviceaccount=mcp:mcp-viewer -n payments

# Check it
kubectl auth can-i list pods -n payments --as=system:serviceaccount:mcp:mcp-viewer
kubectl auth can-i delete pods -n payments --as=system:serviceaccount:mcp:mcp-viewer

# A short-lived token
kubectl create token mcp-viewer -n mcp --duration=2h

A RoleBinding that points at the view ClusterRole keeps access to one namespace; use a ClusterRoleBinding only if the agent really needs to read the whole cluster. The first check should answer yes and the second no. The token from kubectl create token expires, so a leaked kubeconfig stops working on its own. On EKS, GKE and AKS the same idea runs through the cloud identity as well: an IAM policy, a Google role such as roles/container.clusterViewer, or an Azure role, plus Kubernetes RBAC inside the cluster.

One kubeconfig, one context

By default kubernetes-mcp-server works across every context in your kubeconfig, and each tool gains a context argument to pick a cluster. That is convenient on a laptop and dangerous with an agent, because production is usually one argument away from staging. Build a separate kubeconfig for the agent with a single context: the cluster, the mcp-viewer service account and its token, following the project’s guide, and set its file permissions so only you can read it. Point the server at it with the KUBECONFIG environment variable or the kubeconfig key in TOML. The server then cannot reach a cluster that file does not name.

Destructive tools off

• Know which tools matter. On kubernetes-mcp-server, the core toolset has pods_delete, pods_exec, pods_run, resources_create_or_update and resources_delete; the Helm toolset installs and uninstalls releases. All of them disappear in read-only mode.
• On GKE, connect to /mcp/read-only. Deleting clusters and node pools lives only on /mcp/delete-tools, which you should never add for an agent.
• On EKS, use the read-only managed policy and the proxy’s --read-only. AWS notes that its example write policy includes high-risk permissions, needed to create and tear down clusters.
• On AKS, leave --access-level at readonly. Remember that readwrite gives kubectl and helm the power to read Secrets and deploy workloads, whatever the prompt says.
• Treat exec as a write. Running a command inside a container is as powerful as the container, even if the command looks harmless.

Setup in Claude Code

With the TOML file and the dedicated kubeconfig in place, one command adds the server for your user. Claude Code’s MCP documentation↗ (opens in a new tab) shows --env for the environment and -- before the command it runs:

claude mcp add --scope user --transport stdio \
  --env KUBECONFIG=$HOME/.kube/mcp-viewer.kubeconfig \
  kubernetes -- npx -y kubernetes-mcp-server@latest \
  --config $HOME/.config/kubernetes-mcp-server.toml

Run claude mcp get kubernetes to check it connected, then /mcp in a session to see its tools. There should be no delete, exec or apply tool in the list; if there is, the TOML file was not read. Pin a version instead of @latest once you are happy, so the tool list does not change under you.

Prompts for inspection

• “In the payments namespace, list pods that restarted in the last hour. For each, show the last 50 log lines and the related events. Do not change anything.”
• “Why is the checkout deployment not rolling out? Compare desired and ready replicas, and summarize the events.”
• “Which pods in the payments namespace have no resource limits set? List them with their owners.”

Logs are the one thing view still exposes that deserves thought. Application logs can hold tokens, email addresses or customer data, and whatever the agent reads goes into the conversation. AWS’s open-source EKS server treats logs and events as sensitive and keeps them behind a separate flag for that reason. If your logs are not clean, scope the agent to namespaces whose logs are.

From a finding to a task

A read-only agent is good at finding what is wrong and poor at deciding when to fix it. Each finding, a missing limit, a crash loop, an image pinned to latest, is work for someone to schedule. With fenbs connected as a second MCP server at https://fenbs.ai/api/mcp, the agent can search the board first, then file each finding as a bug or an enhancement with a priority from 1 to 10, a note naming the namespace, the resource and the evidence, and a plan with the fix. The fix itself goes through your normal pull request and deploy, not through the agent’s read-only session. History shows every task under the assistant’s name, and its connection cannot exceed the role you gave it on the board. fenbs does not connect to your cluster; the agent carries the finding across.