Config is the same across clients — only the file and path differ.
{
"mcpServers": {
"io-github-michael-whitecapdata-whitecapdata-dev": {
"args": [
"whitecapdata-dev"
],
"command": "uvx"
}
}
}Are you the author?
Add this badge to your README to show your security score and help users find safe servers.
Operate a k3s / Kubernetes cluster straight from your AI agent — safe by default.
Run this in your terminal to verify the server starts. Then let us know if it worked — your result helps other developers.
uvx 'whitecapdata-dev' 2>&1 | head -1 && echo "✓ Server started successfully"
After testing, let us know if it worked:
Five weighted categories — click any category to see the underlying evidence.
No known CVEs.
Checked whitecapdata-dev against OSV.dev.
Be the first to review
Have you used this server?
Share your experience — it helps other developers decide.
Sign in to write a review.
Others in ai-ml / cloud
Dynamic problem-solving through sequential thought chains
Persistent memory using a knowledge graph
Privacy-first. MCP is the protocol for tool access. We're the virtualization layer for context.
An autonomous agent that conducts deep research on any data using any LLM providers
MCP Security Weekly
Get CVE alerts and security updates for io.github.Michael-WhiteCapData/WhiteCapData-Dev and similar servers.
Start a conversation
Ask a question, share a tip, or report an issue.
Sign in to join the discussion.
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).uvx whitecapdata-dev # run directly
# or
pip install whitecapdata-dev # then run: whitecapdata-dev
claude mcp add homelab -- uvx whitecapdata-dev
{
"mcpServers": {
"homelab": {
"command": "uvx",
"args": ["whitecapdata-dev"],
"env": {
"HOMELAB_MCP_MUTABLE_NAMESPACES": "default,apps,monitoring",
"HOMELAB_MCP_READONLY": "0"
}
}
}
}
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
| 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 |