Kubernetes Just Got A Chatty New Assistant, And It Speaks Fluent YAML

Ever tried explaining to a colleague why a pod is stuck in CrashLoopBackOff, only to spend twenty minutes digging through kubectl commands before you even get to the actual fix? That daily grind of cluster troubleshooting is exactly what Red Hat is trying to shrink down to a single question typed in plain English.

In this article, we will look at Red Hat’s new open-source MCP server for Kubernetes, how it works under the hood, what makes it different from other similar tools already out there, and why it matters for anyone running clusters at scale.

What is this MCP server anyway

MCP stands for Model Context Protocol, a standard introduced by Anthropic in 2024, allowing AI models to connect to external data sources or tools in a structured manner. MCP can be described as a universal translator used between an LLM and the target system regardless of technology.

Red Hat has created its own MCP server for Kubernetes and OpenShift. The AI assistant, such as Visual Studio Code, Microsoft Copilot, or Cursor, gets connected to the cluster and is able to give the service owner instructions in natural language.

Instead of typing a long kubectl command, an administrator can ask the system a question such as, “What are the pods that are in CrashLoopBackOff on the previous date?” or “Why did my deployment not scale?”

Why it is not just another kubectl wrapper

Following is the technical point of differentiation for Red Hat’s version. Most implementations of Kubernetes MCP function by encoding the pre-existing command-line tools (like Helm or kubectl) in order to convert the normal language into these commonly used commands in the back-end.

Red Hat, however, uses an alternate approach. Its server is developed using Go programming language and enables direct communication with the Kubernetes API server,, which eliminates the command line interface layer altogether. As mentioned in the project’s GitHub page, this direct access to the API streamlines the process and gives full access to all functionalities provided by the API, including custom resources,, which might be challenging for the tools employing wrappers.

The entire tool is distributed as one single executable program which does not depend on any external application and runs either on the developer’s machine or inside the cluster itself to be accessed via Streamable HTTP or Server Side Events.

Keeping the AI on a leash

Giving a large language model (LLM) access to your company’s production cluster may seem like a bad idea, but Red Hat has clearly taken precautions against it. The server can be integrated seamlessly into the existing RBAC framework of the organization, meaning it has access to no more than the service account that it is utilizing.

For instances where it is necessary to maintain confidentiality, there is a read-only or non-invasive option, which allows the server to access logs, view occurrences, and analyze usage through commands similar to ‘top.’

Ultimately, however, in the default mode the server has full permissions to perform any operations on any type of resource (including custom resources) using the API. This is an astonishingly powerful system, and in this case, it is RBAC guarding the user from the risks rather than the user disabling extra options.

In addition, Red Hat has released a guide on how to configure the read-only version of the server using OpenShift 4.19 and VS Code.

A crowded but growing field

Red Hat is far from the only player building this kind of bridge between AI and Kubernetes. Stacklok has its own Go based implementation called mkp. There is also MCP K8S Go, another Go project in the same space. On the Python side, mcp kubernetes server offers a natural language layer over kubectl and the Python Kubernetes SDK. Independent developer Alexei Ledenev packaged a version in a Docker container bundled with kubectl, Helm, istioctl, and Argo CD support. Microsoft has its own entry too, tailored for Azure with built in Azure security controls.

What Red Hat is betting on is that a clean, dependency free, direct to API design will hold up better at scale than tools built as thin layers over existing command line utilities.

Why this matters beyond the tech specs

Kubernetes has become widely known for its powerful features, but it is still not easy to learn. Functions such as that of the MCP server form the basis of the new trend of AI assistants that are changing the nature of their role in infrastructure from merely chatting with users to leading actual operations and collecting, diagnosing, and acting upon information in the system.

For platform teams, this means that they can respond to problems faster without having to switch between conversation, documentation, and terminal screens. For young professionals, the complexity of understanding how Kubernetes functions is reduced since they no longer have to rely on memorizing various kubectl flags. 

However, with autonomy comes the responsibility to ensure appropriate access permissions. Anyone implementing this kind of tool should treat RBAC in the same as that of any other user with access to a cluster, and must be serious when configuring it.

In conclusion, if you are responsible for the management of the Kubernetes environment and spend too much time solving various problems manually, then you should start piloting new tools, but first try them in read-only mode.