kubernetes-mcp-server: a native Go MCP server for Kubernetes and OpenShift

What kubernetes-mcp-server solves for AI clients

An MCP client such as Claude Desktop or VS Code can call tools, but it has no built-in way to talk to a cluster. The usual workaround is to let the model run kubectl through a shell, which means parsing text output, depending on a binary that must exist on the host, and giving the model a general-purpose command runner. kubernetes-mcp-server replaces that with typed tool calls against the Kubernetes API. The README states plainly that the project "IS NOT just a wrapper around kubectl or helm command-line tools" and that it is a "Go-based native implementation that interacts directly with the Kubernetes API server." That distinction matters most for anyone running the server in a container or on a host where Node, Python and the Kubernetes CLI are not installed. The server is distributed as a single native binary for Linux, macOS and Windows, and also as an npm package, a Python package and a container image. The audience is platform engineers and developers who already use an MCP-capable editor and want cluster operations inside the same chat window as their code.

How the Go implementation reaches the API server

The repository layout shows the split: cmd/ holds the entry point, pkg/ holds reusable packages, internal/ holds non-exported code, and cmd is wired through cobra and pflag, both listed in go.mod. Configuration is read from TOML files via github.com/BurntSushi/toml, and fsnotify watches for changes, which lines up with the README claim that the server "automatically detect changes in the Kubernetes configuration and update the MCP server." Authentication plumbing includes go-oidc and go-jose, so OIDC-based cluster auth is handled in-process. On the protocol side the project depends on github.com/modelcontextprotocol/go-sdk, and the Dockerfile carries the label io.modelcontextprotocol.server.name="io.github.containers/kubernetes-mcp-server". Tekton support comes from a real dependency on github.com/tektoncd/pipeline, not a text parser. Observability is optional and built on OpenTelemetry, with OTLP exporters for traces, metrics and logs plus a Prometheus exporter, and the README points to docs/OTEL.md for sampling rates and a /stats endpoint. The tools exposed cover generic CRUD on any resource, pod operations including logs, exec, top and run, namespaces, events, OpenShift projects, Helm install/list/uninstall, and Tekton PipelineRun and TaskRun operations.

Installing kubernetes-mcp-server and wiring it into Claude Desktop

The README lists one requirement: access to a Kubernetes cluster. For Claude Desktop the fastest path uses npx. Open claude_desktop_config.json and add the server to the mcpServers list exactly as the README shows.

{
  "mcpServers": {
    "kubernetes": {
      "command": "npx",
      "args": ["-y", "kubernetes-mcp-server@latest"]
    }
  }
}

After restarting Claude Desktop, the Kubernetes tools should appear in the client's tool list. For VS Code the README gives a CLI install instead of hand-editing JSON.

# For VS Code
code --add-mcp '{"name":"kubernetes","command":"npx","args":["kubernetes-mcp-server@latest"]}'
# For VS Code Insiders
code-insiders --add-mcp '{"name":"kubernetes","command":"npx","args":["kubernetes-mcp-server@latest"]}'

Running the command registers the same npx-based server entry. If you prefer a container, the Dockerfile builds a multi-arch image on top of registry.access.redhat.com/ubi9/ubi-minimal and starts the binary with a default port.

ENTRYPOINT ["/app/kubernetes-mcp-server"]
CMD ["--port", "8080"]
EXPOSE 8080

The process runs as user 65532:65532 and listens on 8080 unless you override the command. The README also points to docs/getting-started-claude-code.md and docs/getting-started-kubernetes.md for a Claude Code setup and a production ServiceAccount with read-only access.

The permissions problem nobody escapes

The server does what your kubeconfig allows. That is the honest description of its security model, and it is also the sharpest limitation. A tool set that includes pod exec, pod run, generic delete and Helm uninstall is an operations interface, not a read-only viewer. If the credentials behind the server belong to a cluster-admin context, an MCP client can delete workloads or open a shell in a running container, and the README's own guidance to review the Kubernetes setup guide for a dedicated ServiceAccount with read-only access suggests the maintainers expect this concern. The project does not document a per-tool allowlist in the README, so the practical control is RBAC on the ServiceAccount or the kubeconfig context you hand it. There is a second, quieter failure mode: the README says the server watches kubeconfig for changes and reloads. That is convenient when you switch contexts and dangerous when something else switches them for you, because the tools keep working against whatever cluster is now current. Nothing in the README describes a confirmation step before destructive calls, which is normal for MCP servers but worth knowing before you point one at production.

kubernetes-mcp-server compared with shelling out to kubectl

The obvious alternative is an MCP server that wraps kubectl and helm as subprocesses. The difference is not cosmetic. A wrapper needs those binaries on the host, parses their stdout, and inherits their flag surface, which means the model has to know kubectl syntax. This project speaks the API directly, so the tool schema is defined by the server and the results are structured rather than formatted text. It also means the server can do things a CLI wrapper cannot easily do, such as holding multiple cluster connections from one kubeconfig, which the README lists as multi-cluster support. The trade-off runs the other way too: a kubectl wrapper inherits years of edge-case handling and every plugin you already trust, while a native implementation has to reimplement resource discovery and watch semantics itself. The go.mod dependency on github.com/google/gnostic-models and the OpenAPI tooling suggests the project is doing that work rather than shelling out. If your team already has hardened kubectl wrappers with audit logging, swapping them for this server is a change in trust boundary, not just a change in transport.

Maintenance, releases and the Apache-2.0 licence

The repository is not archived and the last push was on 2026-09-10, which is recent. Releases move quickly: v0.0.64 on 2026-07-10, v0.0.65 on 2026-07-14, v0.0.66 on 2026-07-31. A version series still at 0.0.x after 66 releases tells you the maintainers have not committed to API stability, so pin the version you deploy rather than tracking @latest in your MCP client config. The upgrade cost is mostly in the client config and any TOML configuration you have written, both of which are documented in docs/configuration.md according to the README. The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. It also requires that you preserve notices and state changes, and it does not grant trademark rights, so you cannot present a fork as the official project. That is a summary of the licence text, not legal advice; check the LICENSE file and your own counsel before redistributing a modified binary.

Editorial conclusion

Adopt kubernetes-mcp-server if you want an AI client to read and act on cluster state without a kubectl wrapper in the middle, and if you can accept a project whose latest release is v0.0.66. Skip it if you need a stable 1.0 API surface or if you cannot review the RBAC you grant it. Before rollout, verify which kubeconfig context the server picks up, confirm whether read-only mode is available in your build, and check the docs/ directory for the configuration reference.

Frequently asked questions

Official sources

1. containers/kubernetes-mcp-server on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases