# Kubernetes — MCP Server

> Inspect and operate a cluster through the Kubernetes API, not kubectl.

**Source:** https://mcpplaygroundonline.com/mcp-servers/kubernetes  
**Transport:** stdio  
**Requires auth:** Yes

---

## What it does

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.

## Tools exposed

- pods_list / pods_list_in_namespace / pods_get — enumerate and inspect pods
- pods_log — read container logs, the first stop in any incident
- pods_exec / pods_run — run a command in a pod or start a new one
- pods_top — live CPU and memory usage, cluster-wide or per namespace
- resources_list / resources_get — read any resource type, including custom resources
- resources_create_or_update / resources_delete — apply and remove manifests
- events_list — cluster events, usually where the real failure reason is
- helm_install / helm_list / helm_uninstall — manage Helm releases

## Example queries you can run

- "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."

## Details

- **Recommended model:** anthropic/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.
- **Transport:** stdio
- **Authentication:** Required — 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.
- **Official source:** [containers/kubernetes-mcp-server — source repository](https://github.com/containers/kubernetes-mcp-server)

## Connecting to Kubernetes

### Environment variables

- `KUBECONFIG` — Path 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"]
    }
  }
}
```

## Frequently asked questions

### What is the Kubernetes MCP server?

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.

### Is it safe to give an AI agent access to a production cluster?

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.

### How is this different from wrapping kubectl?

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.

### Does it work with custom resources?

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.

### Does it support OpenShift?

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.

---

_Test this server across 40+ models on MCP Playground: https://mcpplaygroundonline.com/mcp-servers/kubernetes — free, no install._