A Kubernetes MCP server is more than a convenience layer for prompts: it creates a new control plane path into the cluster. That matters architecturally because the real design question is not whether natural-language operations are useful, but where this service sits in the trust boundary and how tightly it is scoped. Teams that treat it like a developer-side helper will miss that it effectively becomes an API broker between an LLM client and production infrastructure.
The most important implementation choice is deployment model. Running the binary locally reduces cluster-side footprint, but shifts risk to endpoint security, kubeconfig handling and inconsistent policy enforcement. Running it in-cluster can centralize controls, logging and network policy, but also turns the MCP endpoint into a high-value service that needs the same hardening as any privileged operational component. In both models, service-account design, namespace scoping, audit logging and explicit disabling of write actions should be decided before experimentation moves beyond sandbox use.
Red Hat’s direct Kubernetes API approach is also operationally significant. Avoiding kubectl wrappers should improve fidelity and reduce toolchain dependencies, but it means practitioners need to think about request visibility, rate limiting, error handling and how AI-generated actions map to existing approval workflows. If the MCP can issue CRUD operations on custom resources, platform teams will also need to test how it behaves with operators, admission controllers and GitOps reconciliation loops.
For most enterprises, the pragmatic first step is narrow adoption: read-only access, non-production clusters, full audit capture and a defined set of investigative use cases such as incident triage. The value is real, but so is the need to govern LLM-driven infrastructure access as a production interface, not just a chat feature.
TL;DR — Key Takeaways
- Red Hat’s open source Kubernetes MCP server gives AI assistants a direct way to interact with Kubernetes and OpenShift clusters through natural language.
- The Go-based server talks directly to the Kubernetes API rather than acting as a wrapper around
kubectlor Helm. - Administrators can restrict the MCP server with Kubernetes RBAC, read-only access and controls that disable destructive operations.
Red Hat is building an open source MCP server extension to help developers and administrators manage Kubernetes and Red Hat’s own OpenShift Kubernetes distribution.
The extension can help AI assistants like Visual Studio Code, Microsoft Copilot, and Cursor control and interact with Kubernetes clusters. It is one of a number of open source MCP servers currently available, though Red Hat’s clean design offers full API accessibility and a single binary installation.
Anthropic initially created the Model Context Protocol (MCP) specification in 2024 to connect large language model (LLM)-driven applications with external data and tools. In this case, Red Hat is creating an MCP to interact with Kubernetes and OpenShift clusters.
For instance, an MCP would provide a conduit for cluster administrators to ask questions, in natural language, about what is happening with their clusters, e.g. “Show me all the pods in CrashLoopBackOff in the last 24 hours,” or “Why is my deployment not scaling?”
It could also aid in diagnosing and resolving issues, drawing on the selected LLM’s knowledge of how Kubernetes works.
When installed, the software can be wired into the organization’s own RBAC permissions and organizational policies, perhaps by establishing a service account (“cluster-reader”) under which the MCP can operate.
Those working in a sensitive environment can just keep the MCP in read-only or “non-destructive” modes, where they can retrieve events and logs. They can check CPU and memory usage through the top command.
The MCP server, however, defaults to full cluster control, which allows you to get the most work done by giving the LLM the full ability to execute commands and perform CRUD operations on any Kubernetes resource, including custom resources. The LLM can, via MCP, make direct API calls with no command-line tool overhead.
Red Hat’s MCP server, written in the Go programming language, works as a single binary with no external dependencies. It can run either locally on the user’s machine or within the cluster, accessible via Streamable HTTP or Server-Side Events (SSE).
In an introductory page, Red Hat walks users through how to set up a read-only Kubernetes MCP Server so it can be used with OpenShift 4.19 and VS Code. The page then shows how to troubleshoot issues through natural language and tool calls. Some prompts that can be used:
- “show node”
- “show pods that are not working”
- “list namespaces”
- “get customresourcedefinitions”
- “get the events of a pod in the default namespace”
- “describe pod <name> in namespace <ns>”
- “get deployments in namespace mcp”
- “show nodes”
- “help me diagnose the pod <my-app-123>”
Red Hat is not alone in implementing an MCP server for Kubernetes. Stacklok offers a Go-based implementation, called mkp, for working with core Kubernetes resource operations. MCP K8S Go is another open source Go-based implementation.
Elsewhere, the mcp-kubernetes-server project is built on Python, and offers a natural language interface for interacting with kubectl actions and Python Kubernetes SDK operations. Developer Alexei Ledenev packaged his MCP server in a Docker container with several cloud native tool libraries for working with kubectl, helm, istioctl, and argocd.
And Microsoft has its own MCP Kubernetes implementation for Azure, with Azure’s built-in security privileges built in.
But Red Hat’s implementation comes with its own advantages, according to the company.
“Unlike other Kubernetes MCP server implementations, this IS NOT just a wrapper around kubectl or helm command-line tools. It is a Go-based native implementation that interacts directly with the Kubernetes API server,” the GitHub page states.
Frequently Asked Questions
It is an open source Model Context Protocol server that enables AI assistants to interact with Kubernetes and OpenShift clusters.
It can help users query cluster resources, troubleshoot failing workloads, retrieve logs and events, inspect resource usage and perform Kubernetes operations allowed by the credentials assigned to it.
Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.