What is MCP Server Kubernetes?
MCP Server Kubernetes, published on npm as mcp-server-kubernetes by the GitHub user Flux159, lets an agent inspect and change a cluster through kubectl and Helm. It exposes 23 tools, from kubectl_get, kubectl_describe and kubectl_logs to kubectl_apply, kubectl_delete, exec_in_pod, node_management and a kubectl_generic tool that runs any kubectl command, plus a k8s-diagnose troubleshooting prompt. Most tools shell out to the kubectl and helm binaries on your PATH, passing arguments directly rather than through a shell; port forwarding and connection checks use the official JavaScript client library.
It reads ~/.kube/config by default and uses whatever context is current. It also accepts a whole kubeconfig in KUBECONFIG_YAML or KUBECONFIG_JSON, a server and bearer token in K8S_SERVER and K8S_TOKEN, a custom path, or the in-cluster ServiceAccount when it runs in a pod, which the repo's Helm chart supports. Stdio is the default; Streamable HTTP is opt-in behind ENABLE_UNSAFE_STREAMABLE_HTTP_TRANSPORT, with an optional X-MCP-AUTH header token.
The MIT-licensed repo has about 1,600 GitHub stars; v4.2.1 shipped on 26 October 2026, and the npm package was downloaded about 34,000 times in the month to 26 October. It is listed in the official MCP registry.
How to install MCP Server Kubernetes
npx mcp-server-kubernetesIs MCP Server Kubernetes worth it?
The defaults are the problem, not the feature list. Started with no environment variables, the server offers all 23 tools against whatever kubeconfig context is current, which for most engineers is an admin identity. An agent can then delete namespaces, drain nodes, uninstall Helm releases, run commands inside pods with exec_in_pod and pass anything to kubectl_generic. Even kubectl_context's set operation rewrites your kubeconfig, so the context your own terminal uses changes too.
Three switches narrow it, in this order of priority. ALLOWED_TOOLS takes an exact list and refuses to start on a misspelt name. ALLOW_ONLY_READONLY_TOOLS leaves seven documented tools: get, describe, logs, context (with switching blocked), explain_resource, list_api_resources and ping. ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS is weaker than its name: it removes delete, uninstall, cleanup, node management, exec and kubectl_generic, but keeps kubectl_apply, kubectl_patch, kubectl_scale and Helm install and upgrade, so an agent can still scale a deployment to zero or overwrite a running manifest.
Secrets are masked, partly. kubectl_get replaces the data values of any Secret with *** by default, but the docs say plainly that logs and other operations are not covered. In the default mode kubectl_generic and exec_in_pod are both available, so an identity with get on Secrets can read them in full. Pod specs with inline environment variables and ConfigMaps come back unmasked in every mode. Masking is a convenience; RBAC is the control.
That is where a dedicated ServiceAccount earns its keep. Bound to Kubernetes' built-in view ClusterRole in a single namespace, it can read most objects but not Secrets, roles or role bindings, so neither a prompt-injected log line nor a server bug can reach credentials or write anything. Kubernetes' own guidance warns that list and watch on Secrets reveal their contents just as get does. Do not take the repo's Helm chart as the model here: its ClusterRole, described as least-privilege, grants get, list and watch on Secrets cluster-wide, plus delete on pods and deployments and pods/exec.
The security record cuts both ways. Eleven advisories have been published since July 2025, eight rated high, covering command injection, flag injection that could send the operator's bearer token to another API server, arbitrary local file reads and, in May 2026, read-only modes that only hid tools rather than blocking calls (fixed in 3.6.0). Each was fixed quickly, and the code now blocks flags such as --server, --token and --as from tool input. It is a lot of findings for one server, and a reason to stay on the current release.
Where it earns its place
An on-call SRE at a 50-engineer SaaS company running production on Kubernetes
Find out why pods in one namespace are crash-looping without risking a write
Run with ALLOW_ONLY_READONLY_TOOLS=true and a kubeconfig for a ServiceAccount bound to the view role in that namespace, then invoke the k8s-diagnose prompt. The agent reads events, describe output and logs; it cannot read Secrets or change anything. The server is free, and setup is one Role binding.
A developer working against a local minikube or kind cluster
Install a Helm chart, change values and redeploy while iterating on a service
Default mode with the local context is reasonable here: install_helm_chart, kubectl_apply and kubectl_rollout cover the loop. Point it at production with the same settings and the same agent can delete namespaces, so keep the kubeconfig's current context on the local cluster.
A platform team lead at a fintech deciding whether to allow agents near shared clusters
Set a policy for which agent actions are acceptable
ALLOWED_TOOLS=kubectl_get,kubectl_describe,kubectl_logs pins the surface and fails at start-up on a typo, and OpenTelemetry tracing records every call. The bigger decision is the RBAC role behind it, because the Helm chart's default can read every Secret in the cluster.
Before you commit
- Setup
- Needs kubectl on the PATH and a working kubeconfig (Helm 3 optional), then claude mcp add kubernetes -- npx mcp-server-kubernetes or the same npx command in Claude Desktop, VS Code, Cursor or Codex; an mcpb bundle, Docker image and Helm chart are also offered. If kubectl get pods works in your terminal, the first call works in minutes.
- Integrations
- 23 tools: read tools (kubectl_get, kubectl_describe, kubectl_logs, explain_resource, list_api_resources, ping), write tools (kubectl_apply, kubectl_create, kubectl_patch, kubectl_scale, kubectl_rollout, Helm install, upgrade and uninstall), destructive tools (kubectl_delete, cleanup, node_management, exec_in_pod, kubectl_generic), plus port forwarding and context switching. Optional OpenTelemetry export to any OTLP backend.
- Data and privacy
- It can do whatever the kubeconfig identity can, and with defaults that includes reading Secrets in full through kubectl_generic or exec_in_pod. Pod logs, events and annotations are untrusted text that reaches the model, which is how several advisories describe token exfiltration. HTTP mode binds localhost with DNS rebinding protection on by default, but requires no token unless MCP_AUTH_TOKEN is set.
- Cost at scale
- Free; the cluster bills as usual. The cost that grows is API server load and context: list calls across all namespaces in a large cluster can overflow the default 1 MB output buffer, which SPAWN_MAX_BUFFER raises.
- Limits
- Requires kubectl and helm binaries locally; no approval step of its own, so confirmation depends on the MCP client. Masking covers only kubectl_get on Secrets. The Helm chart's HTTP mode accepts unauthenticated requests unless security.mcpAuthToken is set.
What's good
- 23 tools cover kubectl, Helm, logs, port forwarding and node work
- Read-only and exact allow-list modes enforced at call time since 3.6.0
- Secret values masked in kubectl_get output by default
- Many credential sources, including in-cluster ServiceAccounts
What's not
- Default mode includes delete, exec_in_pod and raw kubectl
- Non-destructive mode still allows apply, patch and scale
- Eleven security advisories, eight rated high
- Helm chart's default ClusterRole can read every Secret
Best for
Platform engineers who want an agent to investigate clusters through kubectl, and will give it a scoped ServiceAccount and read-only mode first.
MCP Server Kubernetes alternatives
MCP Server Kubernetes: common questions
- Is MCP Server Kubernetes worth it?
- Broad and actively patched, but out of the box it hands an agent delete, exec and raw kubectl on your current context, so run it read-only against a ServiceAccount that cannot see Secrets. We rate it 3.8 out of 5.
- How much does MCP Server Kubernetes cost?
- Free and open source (MIT). You pay only for the cluster it talks to.
- What are the downsides of MCP Server Kubernetes?
- Default mode includes delete, exec_in_pod and raw kubectl; non-destructive mode still allows apply, patch and scale; eleven security advisories, eight rated high; helm chart's default ClusterRole can read every Secret.
- Who is MCP Server Kubernetes best for?
- Platform engineers who want an agent to investigate clusters through kubectl, and will give it a scoped ServiceAccount and read-only mode first.
- How much does MCP Server Kubernetes cost for a team or in production?
- Free; the cluster bills as usual. The cost that grows is API server load and context: list calls across all namespaces in a large cluster can overflow the default 1 MB output buffer, which SPAWN_MAX_BUFFER raises.
- Is MCP Server Kubernetes safe for company data?
- It can do whatever the kubeconfig identity can, and with defaults that includes reading Secrets in full through kubectl_generic or exec_in_pod. Pod logs, events and annotations are untrusted text that reaches the model, which is how several advisories describe token exfiltration. HTTP mode binds localhost with DNS rebinding protection on by default, but requires no token unless MCP_AUTH_TOKEN is set.
- What are the best MCP Server Kubernetes alternatives?
- The closest alternatives we have reviewed are AWS MCP Server, Azure MCP Server, Terraform MCP Server and Grafana MCP Server.
Answers checked Oct 28, 2026.