MCP field guide / Kubernetes
// mcp field guide · infrastructure
This is the high-stakes one. With writes enabled, the agent holds kubectl-equivalent power over a live cluster — and a mis-scoped delete of a namespace or PVC is the Kubernetes DROP TABLE. The built-in read-only flags help, but they're coarse and have already failed once. Here's the sourced map.
GUARD FIT · READ TIER
PASS-THROUGHget/describe/logs/events are genuinely safe. Gating them adds friction with zero risk reduction.
GUARD FIT · MUTATE / DESTROY TIER
STRONGDelete a namespace/PVC, drain a node, scale to zero, exec in a container — high blast radius, often irreversible. A pre-call human checkpoint is essential.
Overall fit: STRONG — one of the clearest cases in this guide.
containers/kubernetes-mcp-server — hosted under the Red Hat-sponsored containers org (Podman/Buildah/Skopeo), OpenShift-aware, with Helm and Tekton toolsets. Flux159/mcp-server-kubernetes — a widely-installed community server (~20k npm downloads/week) that wraps kubectl/helm directly, including a kubectl_generic escape hatch for arbitrary kubectl. Both default to full cluster control and rely on the operator to opt into restricted modes.13
Tool names are verbatim from each project's README; the risk grouping is our classification of each tool's documented effect.
| Tier | containers/kubernetes-mcp-server | Flux159/mcp-server-kubernetes |
|---|---|---|
| read-only | pods_list, pods_get, pods_log, resources_get, events_list, nodes_top, helm_list… | kubectl_get, kubectl_describe, kubectl_logs, explain_resource, list_api_resources… |
| mutating | resources_create_or_update, resources_scale, pods_run, pods_exec, helm_install, tekton_* | kubectl_create, kubectl_apply, kubectl_scale, kubectl_patch, kubectl_rollout, kubectl_generic, port_forward |
| destructive | pods_delete, resources_delete (namespace / PVC!), helm_uninstall | kubectl_delete, cleanup, cleanup_pods, node_management (drain/cordon), uninstall_helm_chart |
Restricted-mode toggles exist — --read-only and --disable-destructive on the containers server; ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS=true on Flux159. Red Hat recommends --read-only plus a dedicated RBAC-scoped service account. But they're set at start and are all-or-nothing.2
Why a start-time flag isn't a guard — CVE-2026-46519. A security advisory found that the Flux159 server's non-destructive filter applied only to the tools/list response — it hid the dangerous tools from discovery, but tools/call still executed them. Restricted tools remained directly invokable until the fix in v3.6.0.4 The lesson generalizes: hiding a tool is not the same as refusing to run it. Enforcement has to sit at the point of the call, checking the actual request — exactly where a transparent proxy operates, and exactly what a toggle can't do.
SRE / incident response. "Show me all pods in CrashLoopBackOff" — correlate pods_list + events_list + pods_log, propose a cause, and (if writes are on) restart or rescale.
Interactive troubleshooting. "Why isn't my deployment scaling?" — inspect the Deployment/HPA, read events, and scale to remediate.
Cluster hygiene. "Clean up failed pods in staging" → cleanup_pods / kubectl_delete — the scenario where a wrong context or fat-fingered selector is catastrophic.
Don't gate the read tier. get/describe/logs/events are genuinely safe — gate them and you've added friction for nothing.
Gate the mutate/destroy tier — this is the strongest fit in the guide. The irreversibility is concrete, not theoretical:
resources_delete / kubectl_delete on a Namespace cascades-deletes everything inside it; on a PVC it can destroy the volume and its data. No undo — the Kubernetes DROP TABLE.node_management drain evicts every pod off a node; scale to zero takes a service offline; pods_exec / kubectl_generic run arbitrary commands inside running containers.The honest framing: a guard that intercepts the destructive tools/call and shows the exact target — context + namespace + resource — for human approval before it runs is precisely what the coarse start-time flags miss. For a deleted namespace there's no compensation to run; the guard's job is the pre-commit checkpoint and an honest "this cannot be undone" — compensation is not undo, at cluster scale.
delete hits prodChronoMCP gates the destructive tools/call at the point it's made — showing context, namespace and resource — while reads pass straight through.
Profiles describe third-party software from its public sources; ChronoMCP is not affiliated with these projects. Risk groupings are our classification of each tool's documented effect. Capabilities reflect sources current as of Aug 2026 and can change — check the source links for the latest.