MCP Server Kubernetes

What it does

MCP Server Kubernetes gives an MCP client the everyday operations of a Kubernetes cluster. It runs on your machine and works through the kubectl and Helm command-line programs, using whatever kubeconfig context you already have, so the assistant sees the same cluster you do in a terminal.

Its tools cover listing, describing, creating, applying, patching, scaling and deleting resources, reading pod logs, managing rollouts, switching contexts, explaining resource types, port-forwarding, running commands inside pods, cordoning and draining nodes, and installing, upgrading or removing Helm charts. A catch-all kubectl_generic tool passes any kubectl command through. It also ships a k8s-diagnose prompt that walks through troubleshooting pods matched by a keyword.

Three settings narrow what it exposes: ALLOW_ONLY_READONLY_TOOLS keeps only tools that cannot change the cluster, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS removes delete, uninstall, node drain, exec and generic kubectl, and ALLOWED_TOOLS names an exact list. Values in kubectl get secrets output are masked by default. By default it speaks stdio; HTTP and SSE transports, a Docker image and a Helm chart for running it inside a cluster are also documented, and OpenTelemetry tracing can be switched on.

What it needs

Node.js to run it with npx (or Docker for the container image). kubectl on the PATH and a kubeconfig with a working context for a reachable cluster (minikube, Rancher Desktop, GKE, EKS, AKS and so on). Helm v3 on the PATH if you want the Helm tools. Credentials can instead come from KUBECONFIG_YAML, KUBECONFIG_JSON, or K8S_SERVER plus K8S_TOKEN.

Limits

It can only do what your kubeconfig identity is allowed to do; it does not add RBAC of its own. Secret masking applies only to kubectl get secrets output, not to logs or other commands. The HTTP and SSE transports are marked unsafe in their own setting names: anyone who can reach the endpoint acts with your kubeconfig, and the SSE transport is deprecated in favour of Streamable HTTP. Adding clusters to kubectx is listed as not planned. Very large clusters may need SPAWN_MAX_BUFFER raised.

Who it suits

It suits developers and operators who already use kubectl and want an assistant to inspect and change their clusters, including Helm releases and node maintenance. Because it acts with full kubeconfig rights and can delete resources, exec into pods and run any kubectl command, anyone pointing it at a shared or production cluster should start it with ALLOW_ONLY_READONLY_TOOLS or ALLOWED_TOOLS, or give it a restricted kubeconfig. It is a community project, not published by the Kubernetes project or a cloud vendor; people who need only a hosted, managed view of one cloud's clusters may prefer that vendor's own tooling.