homelab-mcp
This MCP server lets an AI agent inspect and operate a Kubernetes/k3s cluster directly, abstracting away kubectl, with safety guardrails built in.
Read (Inspection) Capabilities
cluster_summary— High-level health overview: node/pod totals and a list of unhealthy pods; best starting point for triagelist_pods— List pods cluster-wide or by namespace, with unhealthy pods sorted firstlist_deployments— List deployments with ready vs. desired replica counts, optionally filtered by namespacelist_events— Recent cluster events, with warnings prioritized (configurable limit, default 30)pod_logs— Tail logs for a specific pod (configurable tail length, default 200 lines)node_health— Per-node readiness, kubelet version, resource capacity, and pressure conditionsserver_info— Effective server config: active kubeconfig context, read-only status, and mutable namespace allowlist
Write (Mutating) Capabilities (All gated by a namespace allowlist and a global read-only switch)
restart_deployment— Rollout-restart a deployment (allowlisted namespaces only)scale_deployment— Scale a deployment to a specified replica count (bounded 0–max, default max 10; allowlisted namespaces only)delete_pod— Delete a pod so its controller can recreate it (allowlisted namespaces only)
Safety Features
HOMELAB_MCP_READONLY=1disables all mutating tools globallyHOMELAB_MCP_MUTABLE_NAMESPACEScontrols which namespaces can be mutated (defaults:default,apps,monitoring,ci)HOMELAB_MCP_MAX_REPLICAScaps the scale limit (default: 10)The cluster's own RBAC permissions apply on top of these guardrails
Provides tools for inspecting and operating a k3s cluster, including pod, deployment, node health, events, and logs, with safety guards for mutations.
Provides tools for inspecting and operating a Kubernetes cluster, including pod, deployment, node health, events, and logs, with safety guards for mutations.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@homelab-mcp Show me the cluster health summary"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.
Related MCP server: Kubernetes Read Only MCP Server
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-devClaude Code
claude mcp add homelab -- uvx whitecapdata-devClaude 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-devTools
Tool | Kind | Description |
| read | Node/pod health totals + unhealthy pods |
| read | Pods (optionally one namespace), unhealthy first |
| read | Deployments with ready/desired replicas |
| read | Recent events, Warnings first |
| read | Tail a pod's logs |
| read | Per-node readiness, kubelet, capacity, pressure |
| write | Rollout-restart (allowlisted namespaces) |
| write | Scale to N replicas (0..max, allowlisted) |
| write | Delete a pod; its controller recreates it (allowlisted) |
| read | Effective config (context, read-only, allowlist) |
Configuration
Variable | Default | Description |
| current-context | kubeconfig context to use |
|
|
|
|
| Namespaces mutations may touch; |
|
| Upper bound for |
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/mockedSee CONTRIBUTING.md.
License
MIT © Michael Tierney
Available Tools
10 toolscluster_summaryA
Node and pod health totals plus the list of unhealthy pods. Start here.
Inputs: no named parameters. Returns: result
delete_podB
Delete a pod so its controller recreates it (subject to the allowlist).
Inputs: namespace (required), name (required). Returns: result
list_deploymentsC
List deployments with ready/desired replica counts.
Inputs: namespace. Returns: result
list_eventsC
Recent cluster events; Warning-type events sort first.
Inputs: limit. Returns: result
list_podsA
List pods (optionally one namespace). Unhealthy pods sort first.
Inputs: namespace. Returns: result
node_healthB
Per-node readiness, kubelet version, capacity, and pressure conditions.
Inputs: no named parameters. Returns: result
pod_logsC
Tail a pod's logs.
Inputs: namespace (required), pod (required), tail. Returns: result
restart_deploymentB
Rollout-restart a deployment (subject to the mutable-namespace allowlist).
Inputs: namespace (required), name (required). Returns: result
scale_deploymentB
Scale a deployment to N replicas (0..max), subject to the allowlist.
Inputs: namespace (required), name (required), replicas (required). Returns: result
server_infoB
Report the effective configuration (context, read-only, allowlist).
Inputs: no named parameters. Returns: result
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 10 tools
Each tool targets a distinct aspect of cluster management: summary, pods, deployments, events, nodes, logs, scaling, restart, and configuration. No overlapping purposes.
Tools use a mix of verb_noun (delete_pod, list_deployments) and noun_noun (cluster_summary, node_health) patterns. While mostly clear, the inconsistency may cause minor confusion for an agent.
10 tools provide a well-scoped set for monitoring and managing a Kubernetes cluster, covering essential operations without being overwhelming.
Covers core observability and common actions (restart, scale, delete pod) but lacks CRUD for deployments and pods, leaving gaps for full lifecycle management.
Maintenance
Related MCP Connectors
Fail-closed policy guardrails for AI agents running kubectl, terraform, helm, and argocd.
Provides read access to your GKE and Kubernetes resources.
Governed access to sensitive data, secrets and APIs for AI agents. A signed proof for each decision.
Credential broker for AI agents: scoped, revocable API access with policy enforcement and audit.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceProvides read-only access to Kubernetes clusters for AI assistants.25MIT
- AlicenseAqualityCmaintenanceEnables safe, read-only interaction with Kubernetes clusters, allowing users to list resources and fetch logs without any create/update/delete operations.117Apache 2.0
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to safely observe and troubleshoot Kubernetes workloads, with limited recovery actions like pod deletion and Helm rollbacks, while preventing dangerous modifications.18Apache 2.0
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to safely interact with Kubernetes clusters through scoped, redacted tools, with credentials kept local and write operations requiring human approval.Apache 2.0