Operate a k3s / Kubernetes cluster from your AI agent — safe-by-default MCP server.
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent — or use 1-click editor setup below.
We haven't yet run this listing's install command through our automated sandbox check. This isn't a red flag — we're steadily working through the catalog.
💡 Paste the JSON block into your client's configuration file under mcpServers, then restart the application.
Inspect callable tools, capabilities, and parameters exposed to AI agents by WhiteCapData Dev.
cluster_summaryNode/pod health totals + unhealthy pods
list_podsPods (optionally one namespace), unhealthy first
list_deploymentsDeployments with ready/desired replicas
list_eventsRecent events, Warnings first
pod_logsTail a pod's logs
node_healthPer-node readiness, kubelet, capacity, pressure
Operate a k3s / Kubernetes cluster straight from your AI agent — safe by default.
An MCP server that lets an agent (Claude Code, Claude Desktop, Cursor, …) inspect and operate a Kubernetes / k3s cluster — your homelab box, a dev cluster, whatever your kubeconfig points at — without shelling out to kubectl. It talks to the Kubernetes API directly using your existing kubeconfig (or an in-cluster service account).
The design goal is safe by default: reads are always on; every mutating action (restart / scale / delete) is gated before the API call by a read-only switch and a namespace allowlist, so an over-eager agent can't touch kube-system or nuke a deployment you didn't sandbox.
Name note: the PyPI package is
whitecapdata-dev(thehomelab-k8s-style name was taken); the import package and tools are k8s/homelab-focused as described here.
cluster_summary gives node + pod totals and the unhealthy pods, so the agent starts triage with real data.HOMELAB_MCP_READONLY=1 to make the whole server read-only.kubectl uses), or run it in-cluster with a service account.uvx).A Dockerfile is included. The server speaks MCP over stdio and reaches
your cluster through a mounted kubeconfig. Run interactively (-i), starting read-only:
| Tool | Kind | Description |
|---|---|---|
cluster_summary | read | Node/pod health totals + unhealthy pods |
list_pods | read | Pods (optionally one namespace), unhealthy first |
list_deployments | read | Deployments with ready/desired replicas |
list_events | read | Recent events, Warnings first |
pod_logs | read | Tail a pod's logs |
node_health | read | Per-node readiness, kubelet, capacity, pressure |
restart_deployment | write | Rollout-restart (allowlisted namespaces) |
scale_deployment | write | Scale to N replicas (0..max, allowlisted) |
delete_pod | write | Delete a pod; its controller recreates it (allowlisted) |
server_info | read | Effective config (context, read-only, allowlist) |
| Variable | Default | Description |
|---|---|---|
HOMELAB_MCP_CONTEXT | current-context | kubeconfig context to use |
HOMELAB_MCP_READONLY | 0 | 1/true disables all mutating tools |
HOMELAB_MCP_MUTABLE_NAMESPACES | default,apps,monitoring,ci | Namespaces mutations may touch; * = all |
HOMELAB_MCP_MAX_REPLICAS | 10 | Upper bound for scale_deployment |
HOMELAB_MCP_READONLY=1 rejects every mutating tool up front.HOMELAB_MCP_MUTABLE_NAMESPACES (default a homelab-friendly set; * opts into all).scale_deployment clamps to 0..HOMELAB_MCP_MAX_REPLICAS.The cluster's own RBAC still applies on top — this server can only do what the kubeconfig identity is permitted to do.
See CONTRIBUTING.md.
MIT © Michael Tierney
Factual signals from GitHub, npm, and our automated checks — not a rating.
No reviews yet — be the first to share how this listing worked for you.
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/whitecapdata-dev)<a href="https://allmcps.com/mcp/whitecapdata-dev"><img src="https://allmcps.com/api/badge/whitecapdata-dev?style=directory" alt="WhiteCapData Dev on AllMCPs" /></a>