Kubernetes MCP Guard MCP Server

Kubernetes MCP Guard MCP server is a locally run integration for AI assistants that speak the Model Context Protocol. It is a security-first bridge between AI agents and Kubernetes, with out-of-band, OAuth-authenticated, human-in-the-loop (HITL), plan-based approval for every gateway-exposed mutation.

What the assistant can call

Once Kubernetes MCP Guard is connected, these are the calls the assistant has available:

• request_apply_manifest — Dry-run and plan server-side apply for Deployment, Service, or ConfigMap
• request_delete_manifest — Dry-run and plan deletion for supported manifest kinds
• request_scale_deployment — Dry-run and plan a Deployment replica-count change
• request_restart_deployment — Dry-run and plan a Deployment rollout restart
• request_set_deployment_image — Dry-run and plan a Deployment container image update
• propose_plan — Create an approval-pending Operator Approval Policy plan for the autonomous Planner operation menu
• execute_approved_plan — Create the browser approval challenge or execute an approved, digest-bound plan after gates pass
• get_plan_status — Read the current approval status for a plan
• wait_for_plan_approval — Wait briefly for an out-of-band browser approval and return status JSON without applying the plan

Setting it up

Setup follows the usual MCP pattern — install or clone the server, register it in your client's configuration file, restart the client.

Choosing this one

Plenty of browser automation servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. Kubernetes MCP Guard's toolset — request_apply_manifest, request_delete_manifest, request_scale_deployment and 6 more — is a fair guide to whether it matches your workflow. It is maintained by mirusser; worth a glance at recent repository activity before you build anything load-bearing on it.

We check each listing at SyncDev against the project's documentation before it goes live — if something here drifts out of date, it is a bug worth reporting.

Before you rely on it

• It runs with your machine's permissions. That is convenient and also the reason to think about what you point it at before you approve a tool call.
• With 9 tools registered it takes up a noticeable share of the context window; turn it off in projects that never touch Kubernetes MCP Guard.
• MCP clients confirm each tool call by default. Leave that on until you have watched what the kubernetes mcp guard mcp server does with a few real requests.