The shape of this one is a Deployment with its own ServiceAccount rather than a laptop process reading your kubeconfig, which is why the streaming endpoint matters — long-running cluster queries report as they go instead of timing out silently. The trade is that the endpoint ships with no auth of its own, so what stops arbitrary callers from listing your pods is the network policy and the RBAC you write around it.
A Kubernetes server built around streaming: instead of one blocking response it exposes `/call-tool-chunked`, which streams progress and results as JSON lines while a query runs. It ships with troubleshooting prompts as well as resource tools — `k8s-pod-crashloop-diagnose` takes a pod name and namespace and walks the diagnosis. It reads the cluster through whatever kubeconfig it is given.
- `get_pods` lists pods in a namespace, called by POST to `/call-tool-chunked` on port 3000
- A `k8s-pod-crashloop-diagnose` prompt that takes a pod name and namespace and works through the failure
- Streaming responses — progress and results arrive as JSON lines rather than one payload at the end
- A ready-made manifest that creates the namespace, ServiceAccount, RBAC, Deployment and Service for in-cluster use
Node.js v18+ to build, Docker to containerise, and access to a cluster with `kubectl` configured. Run it locally with `npm install`, `npm run build` and `MCP_TRANSPORT=http-chunked npm start`; it picks up `~/.kube/config` unless `KUBECONFIG` points elsewhere. Deployed in-cluster it authenticates through the ServiceAccount and RBAC in the supplied manifest, so scope those to least privilege. There is no authentication on the endpoint itself — keep it off the public internet and put TLS and a network policy in front of it.
One command — npx -y mcp-server-kubernetes