Labsco
MCP SERVER

WhiteCapData-Dev

by Michael-WhiteCapData

Operate a k3s or Kubernetes cluster from an agent, with every mutating call checked before it reaches the API.

Containers, Kubernetes & Cluster Operations
Summary
An agent with cluster access, and a brake it cannot reach around.

The allowlist is enforced before the API call rather than by asking the model to behave, which is what makes this attachable to a cluster you care about. The cluster summary is the sensible opening call: it returns the unhealthy pods rather than everything.

What it is

A Python MCP server that talks to the Kubernetes API through your existing kubeconfig, or an in-cluster service account. Reads are always on; restart, scale and delete are gated by a read-only switch and a namespace allowlist before the API call is made.

What you get
  • A one-call cluster summary: node and pod totals, plus the unhealthy pods
  • Pods, deployments and events listed
  • Pod logs and node health read back
  • A deployment rollout-restarted or scaled
  • A pod deleted
  • Mutations blocked unless the namespace is on your allowlist, and HOMELAB_MCP_READONLY=1 to make the whole server read-only
Requirements

A reachable cluster and a working kubeconfig — the same one kubectl uses — or an in-cluster service account. Python 3.11+, or run it with uvx. The PyPI package is whitecapdata-dev.

Setup effort

One command — uvx whitecapdata-dev