kubernetes-mcp-server: A Native Go MCP Server for Kubernetes and OpenShift
Model Context Protocol (MCP) server for Kubernetes and OpenShift
At a glance
- What is it?
- The containers/kubernetes-mcp-server project puts a Kubernetes API client behind the Model Context Protocol so an LLM tool can list pods, read logs, apply resources and run Helm releases without shelling out to kubectl. The design is a single Go binary, and the trade-off is that it ships no built-in authorization of its own.
- Who is it for?
- Adopt it if you want an MCP client to reach a cluster through a native Go binary instead of a kubectl wrapper, and you are prepared to constrain what that binary can do. Skip it if you need a permission model baked into the server itself, or if your workflow depends on the exact output formatting of kubectl and helm.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap kubernetes-mcp-server fills between an LLM and a cluster
Model Context Protocol defines how a model-facing client discovers and calls tools exposed by a separate process. For Kubernetes, the obvious shortcut is to wrap kubectl and helm behind MCP and call it done. The project's README states plainly that this is not what it does: it is a Go-based native implementation that talks to the Kubernetes API server directly, and the README claims there is no need for external dependencies or tools on the system. That distinction matters more than it first appears. A kubectl wrapper inherits kubectl's flags, its output formats and its version skew against the cluster. A native client inherits the client-go surface instead, which is a different set of constraints. The intended user is an engineer running an MCP-capable assistant (the README shows Claude Code, Claude Desktop, VS Code, VS Code Insiders and Cursor) who wants that assistant to inspect or act on a cluster without a terminal round trip. It is not a replacement for kubectl in a shell, and it is not a controller or an operator.
What the tool surface actually exposes
The README groups capabilities rather than listing every function. Generic Kubernetes and OpenShift resources support create-or-update, get, list and delete on any resource type, which is the broadest part of the surface. On top of that there are pod-specific operations: list across all namespaces or one namespace, get by name, delete, show logs, top for resource usage metrics, exec into a pod, and run a container image with optional exposure. Namespaces and events are read operations. OpenShift gets a projects listing. Helm operations cover install, list and uninstall. Tekton operations cover starting a Pipeline by creating a PipelineRun, restarting or cancelling a PipelineRun, troubleshooting it, retrieving its logs, starting a Task as a TaskRun, restarting a TaskRun with the same spec, and pulling TaskRun logs by resolving the underlying pod. The exec and run entries are the ones to think hardest about. An MCP server that can execute a command inside a running pod is not a read-only observability tool, and the README does not present it as one.
How the server talks to a cluster
Configuration handling is where the native design shows. The README says the server automatically detects changes in the Kubernetes configuration and updates itself, and that it can view and manage the current .kube/config or the in-cluster configuration. Multi-cluster support follows from that: the README states the server can interact with multiple Kubernetes clusters simultaneously, as defined in your kubeconfig files. So the data flow is client to MCP server over the protocol, MCP server to API server over the Kubernetes client, and back. Nothing in the material describes an intermediate agent, a proxy layer or a caching tier. Two consequences follow. Because there is no kubectl in the path, there is also no kubectl context switching semantics to reason about; cluster selection is driven by what is in the kubeconfig the server is reading. And because the server watches for kubeconfig changes, a context switch on the host can change what the assistant is pointed at while a session is live. The README does not describe how in-flight requests behave across such a change, so treat that as unverified.
Installing it: npx, native binaries, and the config file
The fastest documented path is npm. The README gives this block for claude_desktop_config.json: a mcpServers entry named kubernetes whose command is npx and whose args are ["-y", "kubernetes-mcp-server@latest"]. For VS Code the documented command is code --add-mcp with a JSON payload of {"name":"kubernetes","command":"npx","args":["kubernetes-mcp-server@latest"]}, and code-insiders --add-mcp for the Insiders build. Cursor and VS Code Insiders also have install links in the README. If you would rather not run Node, the README states the server is distributed as a single native binary for Linux, macOS and Windows, with npm, PyPI and container images as additional channels, and that native binaries need neither Node nor Python on the system. Configuration is available three ways: command-line arguments, TOML configuration files (the README points at docs/configuration.md), and environment variables. The README does not reproduce the full flag list or the TOML keys in the excerpt available here, so read docs/configuration.md before assuming a specific key name. Observability is optional and documented separately in docs/OTEL.md, covering OpenTelemetry tracing and metrics with custom sampling rates plus a /stats endpoint.
The security question the README leaves to you
This is the part I would push back on. The README's Claude Code section points readers to docs/getting-started-kubernetes.md for a secure production setup with a dedicated ServiceAccount and read-only access. That is a pointer, not a mechanism. Nothing in the material describes an allow-list of verbs, a namespace restriction enforced inside the server, a confirmation prompt before a destructive call, or an audit log of what the model asked for. The tool surface includes delete, exec and run. So the effective permission boundary is whatever the kubeconfig credential or the in-cluster ServiceAccount grants, and the server will exercise it. If the credential in play is a cluster-admin kubeconfig on a developer laptop, the assistant inherits cluster-admin. That is a defensible design choice for a tool that is meant to be general, and it is also the single biggest thing to get right before deployment. The documentation offers the read-only ServiceAccount pattern; it does not enforce it.
Where a kubectl wrapper is the better answer
The obvious alternative is an MCP server that shells out to kubectl and helm. The difference is not cosmetic. A wrapper reuses the exact formatting, flags and version negotiation you already know, so output matches what you see in a terminal and existing muscle memory transfers. It also inherits whatever wrapper scripts, plugins or credential helpers you have already installed. The native server trades that away for a direct API path and, per the README, no external tool dependency and lower latency from not waiting on subprocesses. If your team's workflows depend on kubectl output shapes, or you rely on a kubeconfig exec credential plugin whose behaviour you have not verified against a native client, the wrapper is the lower-surprise option. The same reasoning applies to helm: the README's Helm support covers install, list and uninstall, which is a narrower slice than the helm CLI, so anything involving templating, diffing or rollback is outside what the material shows. There is also a smaller alternative worth naming: for pure read-only inspection, a plain kubectl MCP wrapper plus a read-only kubeconfig gets you most of the diagnostic value with a smaller blast radius.
Release cadence, maintenance and licence
The release history in the material shows v0.0.66 on 2026-07-31, v0.0.65 on 2026-07-14 and v0.0.64 on 2026-07-10, with the last push to main on 2026-09-10. Three releases inside a month, all still on a 0.0.x version. That pattern tells you two things without any inference about quality: the project is moving quickly, and it has not declared a stable API. For an MCP server the practical risk is tool-surface churn. A rename or removal of a tool between v0.0.65 and v0.0.66 can break a saved prompt or an automation built on top of it, and the version string gives you no compatibility promise to lean on. Pin the version you test rather than tracking @latest in a config file you do not review. On licensing, the repository is Apache-2.0 and the README links to the LICENSE file. Apache-2.0 permits commercial use and modification and includes a patent grant, with the usual obligations around preserving notices and stating changes; if you redistribute a modified server, read the licence text rather than this summary. Nothing here is legal advice.
Editorial conclusion
Adopt it if you want an MCP client to reach a cluster through a native Go binary instead of a kubectl wrapper, and you are prepared to constrain what that binary can do. Skip it if you need a permission model baked into the server itself, or if your workflow depends on the exact output formatting of kubectl and helm. Before wiring it into anything that matters, read docs/getting-started-kubernetes.md and verify what the dedicated ServiceAccount can actually reach, then decide whether the default tool set is too broad for the cluster you are pointing it at.
Community notes