An AI model can write a convincing kubectl command and still know nothing about the cluster in front of it.
It does not know which pods are failing now, what events were emitted five minutes ago, or whether a virtual machine is healthy inside. Someone still has to collect that context, paste it into a chat, run the suggested command, and return with the result.
That is useful assistance, but it is not yet an agentic workflow.
The open-source Kubernetes MCP Server closes this gap. It connects AI clients to Kubernetes and OpenShift through the Model Context Protocol, giving an agent structured tools for inspecting and managing a real cluster.
I started contributing to the project to make KubeVirt—virtual machines managed through Kubernetes—part of that workflow.
From advice to action
A chatbot can suggest why a workload might be failing. An agent with the right tools can inspect the current workloads, read events and logs, compare the evidence, propose an action, and check whether it worked.
This observe, reason, act, and verify loop is where MCP—and agentic loop engineering—becomes valuable. As Anthropic explained when it introduced MCP, the protocol provides a common way for AI applications to connect to external systems. The client can discover a tool, understand its inputs, call it, and receive a structured result.
For Kubernetes, live context is essential. Clusters change constantly, and useful evidence is spread across resources, events, logs, metrics, and custom APIs. An agent should not have to guess the current state from an old manifest or parse a page of copied terminal output.
Why the project matters
The Kubernetes MCP Server is not simply a shell-command wrapper. Its native Go implementation talks directly to the Kubernetes API without invoking kubectl.
It provides tools for common tasks such as listing pods, reading logs and events, inspecting resource usage, and managing arbitrary Kubernetes resources.
Structured tools give an agent clearer choices than an unrestricted shell. Support for generic resources also matters because Kubernetes Operators extend the platform with custom APIs. The agent can work with those custom resources even when there is no dedicated tool for each one.
The project also includes evaluation scenarios that ask models to complete real tasks. This is important for agent-facing software: code can compile and unit tests can pass while a model still struggles to discover the correct tool or provide the right arguments.
What I contributed for KubeVirt
KubeVirt extends Kubernetes with APIs and controllers for running virtual machines alongside containers. A useful agent therefore needs to understand both the Kubernetes view of a VM and what is happening inside its guest operating system.
My first contribution began with VM deletion. I initially proposed a dedicated delete action for the VM lifecycle tool. During review, we found that the generic resource tool could already delete virtual machines. A new action would have duplicated an existing capability.
The real missing feature was control over the deletion grace period. A stuck VM, including some Windows guests, may not shut down cleanly. I closed the first proposal and opened a more general change that added grace-period options to resource deletion. That change was merged.
This taught me an important lesson about MCP design: the goal is not to create a separate tool for every sentence a user might type. A small set of reusable tools is easier for an agent to understand and combine.
My next merged contribution added vm_guest_info. It retrieves operating-system details, filesystems, network interfaces, IP addresses, and logged-in users through the QEMU guest agent, without requiring SSH credentials.
Previously, troubleshooting might stop at:
The VM is running. Try logging in and checking its network configuration.
This capability creates a practical troubleshooting loop. An agent can inspect a VM through Kubernetes, retrieve its guest network information, compare the two views, and explain where they disagree. It can gather evidence that previously required a separate login to the VM.
The review also improved the evaluations. Broad, model-dependent scenarios were replaced with smaller tasks such as retrieving the guest OS, filesystems, IP address, and users. Those building blocks make failures easier to understand.
At the time of writing, I have two more contributions under review. One adds HyperConverged Cluster Operator awareness, helping an agent collect conditions, component health, configuration, and events for the virtualization stack. The other adds VM creation from templates, allowing an agent to use platform-approved defaults instead of inventing a complete VM definition.
Useful does not mean unrestricted
Giving an agent cluster access requires care. Natural language is not a security boundary, and MCP does not make an administrator credential safe.
The server follows Kubernetes authentication and RBAC, so a good setup begins with a dedicated, least-privilege identity. It can also run in read-only mode, disable destructive operations, deny selected resources, and limit which toolsets are exposed. The Red Hat setup guide demonstrates this approach with a read-only ServiceAccount and short-lived credentials.
The goal is not to let AI operate a cluster without supervision. It is to give an agent the smallest useful set of capabilities.
Better models need better interfaces
The agentic era will not be defined only by better models. It will also depend on the interfaces we give them.
Kubernetes already has a powerful API. MCP does not replace either one. It makes carefully scoped capabilities discoverable to AI clients, allowing an agent to gather live evidence and complete a multi-step workflow instead of stopping at a suggested command.
That is why I think Kubernetes MCP Server matters. It gives agents a structured and testable path into real Kubernetes environments.