The Kubernetes MCP server talks to the cluster API directly from a single Go binary — no kubectl, no helm CLI, nothing to shell out to. It exposes pods, arbitrary resources, events, logs and Helm releases as tools, and ships read-only and non-destructive modes that are worth setting before you point a model at anything real.
Bring your own
Claude Sonnet 4.5
Chat with 60+ AI models on the same workflow — switch to a different model mid-conversation and re-run the same prompt, or use Compare mode to put several side-by-side and balance quality vs. cost.
Your existing kubeconfig. The agent inherits exactly the permissions of that context, so point it at a scoped, read-only service account rather than cluster-admin.
How models use it and what it is built for.
Most cluster integrations wrap the kubectl binary and pay for it in latency and brittle output parsing. This server is a native Go implementation that speaks to the Kubernetes API server directly, which means structured responses and no external dependency on the host. It covers pods specifically — list, get, delete, logs, exec, run and top — and then generalises: resources_list, resources_get, resources_create_or_update and resources_delete work against any resource type including your own CRDs, so an agent can read an Argo Rollout or a cert-manager Certificate without the server needing to know what those are. Helm install, list and uninstall are included, and events_list plus pod logs cover the debugging path people actually reach for. It works against OpenShift as well as vanilla Kubernetes, and authenticates with your existing kubeconfig.
Typical tools an AI model can call. Exact names vary by version.
Taken from the official Kubernetes documentation — see containers/kubernetes-mcp-server — source repository for the full reference.
Environment variables
KUBECONFIGPath to the kubeconfig the server should use. Create a dedicated context with a narrow RBAC role rather than reusing your admin one.
Client configuration
Read-only mode (start here)
--read-only exposes only tools that cannot change cluster state. This is the configuration to use the first time you point a model at a real cluster.
{
"mcpServers": {
"kubernetes": {
"command": "npx",
"args": ["-y", "kubernetes-mcp-server@latest", "--read-only"]
}
}
}Write access without destructive tools
--disable-destructive keeps create and update but removes delete, which is the useful middle ground for an agent that fixes things.
{
"mcpServers": {
"kubernetes": {
"command": "npx",
"args": ["-y", "kubernetes-mcp-server@latest", "--disable-destructive"]
}
}
}Copy any of these into MCP Agent Studio after connecting.
Which pods in production have restarted more than five times today, and why?
Read the logs of the failing checkout pod and tell me what is crashing it.
Show me every resource in this namespace that is not in a Ready state.
Compare CPU and memory usage across namespaces and flag anything near its limit.
This is not a single-model product: you get the same MCP connection with 60+ models (Claude, GPT, Gemini, DeepSeek, open-weight, and more), you can switch mid-conversation, and you can open Compare mode to run the same prompt against multiple models at once. The card above is a suggested starting point for this server — not the only choice.
Default pick for Kubernetes
Claude Sonnet 4.5
Cluster debugging is correlation work across logs, events and resource state. Sonnet 4.5 chains those reads well and is careful about destructive calls.
Listing tools proves the server is reachable, not that a model can work with it. Evals go further: they read every tool on the server, write a test suite from its real schemas, and run it — code decides pass/fail on the responses (schema conformance, error codes, pagination, result caps) while a scoring model grades plain-English tasks driven through the tools.
Get a pass/fail report per tool with the evidence behind each verdict — and replay the same suite after every schema change. Destructive tools are excluded from the run.
Run evalsOpen MCP Agent Studio with the connection pre-filled. Add your token, pick any of 60+ models, and start chatting — no install required.
Open Agent StudioCommon questions about connecting, scoping and using it safely.
It is a Go-based MCP server that connects AI agents to a Kubernetes or OpenShift cluster through the API server directly, rather than by wrapping the kubectl and helm command-line tools. It is distributed as a single binary and also published on npm.
Not by default. Start with --read-only, which removes every state-changing tool, and give the server a kubeconfig context bound to a narrow RBAC role. --disable-destructive is the middle ground: create and update stay available, delete does not.
A kubectl wrapper shells out per call, pays process-start latency each time, parses text output and needs the binary installed on the host. This server calls the API directly and returns structured data, which is both faster and less fragile.
Yes. The generic resources_list, resources_get, resources_create_or_update and resources_delete tools operate on any API group and kind, so CRDs from Argo, cert-manager, Crossplane and anything else are reachable without server-side support.
Yes. OpenShift-specific resources such as Routes, DeploymentConfigs and ImageStreams are reachable through the same generic resource tools, and the project tests against OpenShift as a first-class target.