MCP Server for Kubernetes: the options

The right MCP server for Kubernetes depends on one question: do you want the agent to run kubectl against a cluster, or to drive a dashboard you already trust? For raw cluster access, install one thin server — MCP K8S Go or K8s MCP Server — and point it at a read-only kubeconfig context. If you already run a Kubernetes UI like Radar or K8M, turn on its built-in MCP endpoint instead of adding a separate binary. Installing more than one is how you burn your tool budget for no gain.

This is the grounded shortlist. Every server below is real, linked, and matched to a specific job, with the minimal config that works. Most MCP servers — roughly 90% — run locally over stdio, and three of these five do exactly that: a local process holding your kubeconfig, which is the least surprising, most private way to hand cluster credentials to an LLM.

Pick by how you already run Kubernetes

Start from your setup, not from GitHub stars. If you live in kubectl, you want a CLI-shaped server. If you already run a dashboard, use its embedded MCP endpoint so the agent and the UI share one auth path. This table maps each option to its job so you install exactly one.

Server	Best for	Transport	Notes
MCP K8S Go	Raw cluster, resource CRUD	stdio	list/get/create/modify, logs, exec; npx install
K8s MCP Server	kubectl + helm + argocd in a sandbox	stdio	Runs the CLIs inside a Docker container
kubefwd	Local dev against remote services	stdio	Bulk port-forward, inspect pods, watch traffic
Radar	You already run the Radar UI	HTTP	MCP built into the open-source dashboard
K8M	You already run the K8M dashboard	SSE	49 cluster tools; needs an auth token

If you only read one row: kubectl person → MCP K8S Go; you want helm and argocd too → K8s MCP Server; you already run a UI → Radar or K8M.

MCP K8S Go: the default for a raw cluster

For a plain cluster connection, MCP K8S Go is the server to reach for first. It's a small Go binary that speaks the core Kubernetes verbs — list, get, create, and modify resources, read pod logs, and run commands — which is exactly the surface you want next to an agent, and nothing more. It reads your existing kubeconfig, so if kubectl works, it works.

Run it over stdio with a single command:

{
  "command": "npx",
  "args": ["@strowk/mcp-k8s"]
}

The one thing to get right before you wire it up: it inherits your current kubeconfig context. Point it at a read-only context or a scoped service-account token, not your cluster-admin default. The server won't stop an agent from deleting a Deployment if the credentials allow it — that guardrail is yours to set at the RBAC layer.

K8s MCP Server: when you need helm, argocd, and a sandbox

Reach for K8s MCP Server when one CLI isn't enough. It runs kubectl, helm, istioctl, and argocd against your clusters — but inside a Docker container, so the tools and their blast radius stay isolated from your host. That's the pick for anyone whose day is helm releases and ArgoCD syncs, not just reading pods.

It runs over stdio and mounts your kubeconfig into the container read-only, which is the important detail:

{
  "command": "docker",
  "args": ["run", "-i", "--rm", "-v", "/Users/YOUR_USER_NAME/.kube:/home/appuser/.kube:ro", "ghcr.io/alexei-led/k8s-mcp-server:latest"]
}

Note the :ro on the volume mount — the agent can read your kubeconfig but can't rewrite it, and the container is --rm so nothing persists. It's Python under the hood, but you never touch that; the Docker image is the whole interface. Give the mounted context least privilege and you have the most contained option on this list.

kubefwd: for local dev, not cluster ops

kubefwd solves a different problem — it's for developing against a cluster, not operating one. Its MCP server lets an agent bulk port-forward services, inspect pods, and monitor traffic, so your local app can hit my-service.my-namespace as if it ran in the cluster. If you're debugging a service locally against real dependencies, this is the one; if you want the agent to apply manifests, it isn't.

It's a stdio server that ships inside the kubefwd binary you already use:

{
  "command": "kubefwd",
  "args": ["mcp"]
}

Heads-up: kubefwd edits /etc/hosts and binds low ports to make forwarding transparent, so it typically wants elevated privileges. That's expected for its job, but it means you should trust the binary — install it from the official release, not a random fork.

Radar and K8M: use your dashboard's built-in server

If you already run a Kubernetes UI, don't add a separate CLI server — turn on the one built into the dashboard. Radar is an open-source Kubernetes UI with an MCP server baked in, exposed over HTTP at a local endpoint, so the agent operates the same cluster view you do. K8M is an AI-driven mini dashboard whose built-in server exposes 49 cluster operation tools over SSE — the broadest tool surface here by count.

Radar is the simpler wiring — a plain local HTTP URL, no token:

{ "url": "http://localhost:9280/mcp" }

K8M gates access behind a token you generate in its UI, which is the right default for a server carrying 49 tools:

{
  "url": "http://localhost:3618/mcp/k8m/sse",
  "headers": { "Authorization": "<token-from-K8M>" }
}

That 49-tool count is also the catch. Most clients get unreliable at tool selection well before you'd expect — the practical ceiling is around 40 tools total — so K8M alone can crowd out everything else you have installed. If you run K8M, keep your other servers lean, and understand the arithmetic in Cursor's tool limit.

What to skip and how to wire it up

Skip installing two Kubernetes servers at once. They overlap heavily, and every extra server eats into that roughly 40-tool budget before selection degrades — a 49-tool dashboard plus a CLI server is already over the line. Pick one, point it at a least-privilege context, and stop.

Also skip giving any of these cluster-admin on day one. These servers are only as safe as the kubeconfig behind them; the server enforces nothing, RBAC enforces everything. Start read-only, widen deliberately.

Adding any of these is the same three steps in any client — server command or URL, credentials, restart — walked through in how to add an MCP server. To browse the full field or compare tooling side by side, start from the best MCP servers, filter by capabilities, or check alternatives when one of these doesn't fit your cluster.