WhiteCapData-Dev
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.
Why you'd want this
- 🩺 One-call health.
cluster_summarygives node + pod totals and the unhealthy pods, so the agent starts triage with real data. - 🔒 Safe by default. Mutations are blocked unless the namespace is on your allowlist; flip
HOMELAB_MCP_READONLY=1to make the whole server read-only. - 🧰 The operations you actually do. Pods, deployments, events, logs, node health, rollout-restart, scale, delete-pod.
- 🪶 No bespoke backend. Uses the standard Kubernetes API + your kubeconfig — nothing to deploy server-side.
- ✅ Tested. Pure logic is unit-tested with fakes; guard logic is tested against a mocked API. No cluster needed to run the suite.
Requirements
- A reachable cluster and a working kubeconfig (the same one
kubectluses), or run it in-cluster with a service account. - Python 3.11+ (or just
uvx).
Install
uvx whitecapdata-dev # run directly
# or
pip install whitecapdata-dev # then run: whitecapdata-dev
Claude Code
claude mcp add homelab -- uvx whitecapdata-dev
Claude Desktop / Cursor
{
"mcpServers": {
"homelab": {
"command": "uvx",
"args": ["whitecapdata-dev"],
"env": {
"HOMELAB_MCP_MUTABLE_NAMESPACES": "default,apps,monitoring",
"HOMELAB_MCP_READONLY": "0"
}
}
}
}
Run with Docker
A Dockerfile is included. The server speaks MCP over stdio and reaches
your cluster through a mounted kubeconfig. Run interactively (-i), starting read-only:
docker build -t whitecapdata-dev .
docker run --rm -i \
-v "$HOME/.kube/config:/home/app/.kube/config:ro" \
-e HOMELAB_MCP_READONLY=1 \
whitecapdata-dev
Tools
| 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) |
Configuration
| 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 |
Safety model
- Read-only switch —
HOMELAB_MCP_READONLY=1rejects every mutating tool up front. - Namespace allowlist — mutating tools refuse any namespace not in
HOMELAB_MCP_MUTABLE_NAMESPACES(default a homelab-friendly set;*opts into all). - Bounded scale —
scale_deploymentclamps to0..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.
Development
git clone https://github.com/Michael-WhiteCapData/WhiteCapData-Dev
cd WhiteCapData-Dev
uv pip install -e ".[dev]"
ruff check .
pytest # no cluster required — APIs are faked/mocked
See CONTRIBUTING.md.
License
MIT © Michael Tierney
Metadata
Release files for whitecapdata-dev 0.1.3
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| whitecapdata_dev-0.1.3.tar.gz | 15.3 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| whitecapdata_dev-0.1.3-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 27.6 kB
Release files / whitecapdata_dev-0.1.3.tar.gz
| Download URL | whitecapdata_dev-0.1.3.tar.gz |
|---|---|
| Size | 15.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
c532d1dcd8838d3b63225ddd662a9fbc0c67acb5b8e382eab28ff6a4488e82d0
|
|
BLAKE2b-256 checksum How to use checksums |
eee3d5c7b1ccac4410ec105025a92b35f6aeb7cdee687ec889222a39aba67d50
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 23, 2026.
Transparency logRelease files / whitecapdata_dev-0.1.3-py3-none-any.whl
| Download URL | whitecapdata_dev-0.1.3-py3-none-any.whl |
|---|---|
| Size | 12.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
347e5ff3b348f03944068365367bf76208eded076d283fcb5579940a5bad0088
|
|
BLAKE2b-256 checksum How to use checksums |
345e212e41393cd68e832135c0e6cf96de71af5064bf5c3bc7e2398436b392ba
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 23, 2026.
Transparency log