The question set is the interesting part: pending pods come back with the reason, restart counts come with a threshold, and orphaned resources are surfaced as a category — these are the things you would otherwise assemble from several kubectl invocations. Because it uses your existing kubeconfig or the in-cluster service account, its reach is exactly whatever RBAC already allows that identity.
A Python server that reads a Kubernetes cluster and answers diagnostic questions. Every operation is a read; there is no apply, delete or scale, so an agent can explore a production cluster without the risk that usually comes with that access.
- `get_namespaces` lists namespaces; `list_nodes` and `node_capacity` cover node status and remaining capacity
- `list_pods` lists pods, optionally within one namespace
- `failed_pods` returns pods in Failed or Error state, and `pending_pods` returns pending pods together with the reason they are stuck
- `high_restart_pods` finds pods above a restart threshold, defaulting to 5
- `list_deployments`, `list_services` and `list_events` cover the rest of the everyday objects
- `orphaned_resources` finds resources with no owner reference — the ones nobody remembers creating
- `get_resource_yaml` returns the full YAML for a named resource
Access to a cluster, which it finds by itself: your kubeconfig at `~/.kube/config`, or the service account token when it runs inside a pod. No extra configuration if either is in place. Python 3.8+ and uv — clone the repository, `uv venv` and `uv sync`, then point your client at `uv --directory <absolute path> run server.py`. The Python package is `k8s-mcp`, version 0.1.0.
One command — uvx k8s-mcp