Kubernetes MCP Server

kubectl with a conversational interface — inspect pods, read logs, diagnose clusters and manage workloads.

Local serverstdioTypeScriptMIT 1.2k

What is the Kubernetes MCP server?

The Kubernetes MCP server (Flux159's implementation is the established community choice) connects your assistant to any cluster your kubeconfig can reach, wrapping the kubectl verbs that fill an SRE's day: get, describe, logs, events, exec, scale, apply, plus Helm operations for chart management.

Its best genre is the production whodunit. "Why is checkout-service crash-looping?" kicks off an actual investigation — pod status, then events, then logs, then resource limits — with the assistant following the evidence across objects the way a human operator would, except it reads faster and never forgets to check the events. For the recurring classics (ImagePullBackOff, OOMKilled, pending pods with unsatisfiable node selectors) it's remarkably effective at going from symptom to root cause in one exchange.

Cluster comprehension is the second win. Inherited clusters, like inherited codebases, hide their logic; "map what's running in the payments namespace and how services connect" produces the orientation document nobody wrote. Routine operations — scaling deployments, restarting rollouts, port-forwarding for a quick check — are all present too.

It being able to do things is also the caution: exec, apply and delete are in the toolset, and kubeconfig context is your blast-radius control. Point it at staging with a read-heavy role first; a non-destructive mode flag exists and is worth using anywhere important. RBAC applies as it would to any client, so the cluster-side guardrails you already have keep working.

Blast-radius checklist

  • Hand it a purpose-built kubeconfig with one context and a read-mostly ServiceAccount, rather than the file that also carries your production cluster-admin credentials.
  • ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS=true strips the delete-class tools while leaving get, describe, logs and events intact — everything an investigation needs and nothing an accident needs.
  • Log reads on chatty pods are enormous. Asking for a specific container and a bounded tail keeps one debugging session from consuming the entire context window.
  • port_forward opens a real local port that outlives the tool call. Close forwards when you are done, particularly ones pointed at a database service.

What you can do with it

Crash-loop forensics

Status → events → logs → limits, investigated end-to-end in one ask.

Cluster orientation

Namespaces, workloads and service relationships mapped for humans.

Routine ops

Scaling, restarts and quick port-forwards without leaving the conversation.

Available tools

ToolWhat it does
kubectl_get / kubectl_describeList and inspect any resource type
kubectl_logsRead pod/container logs
kubectl_apply / kubectl_deleteApply manifests and remove resources
kubectl_scale / kubectl_rolloutScale deployments and manage rollouts
exec_in_podRun commands inside containers
install_helm_chart / upgrade_helm_chartHelm chart operations
port_forwardForward a local port to a pod or service

How to install the Kubernetes MCP server

{
  "mcpServers": {
    "kubernetes": {
      "command": "npx",
      "args": ["-y", "mcp-server-kubernetes"]
    }
  }
}

Uses your current kubeconfig context — switch contexts to control which cluster it sees. Set ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS=true for a safe mode.

Configuration

Node.js 18+ and a working kubeconfig. RBAC and context selection are your safety controls; safe mode available via env flag.

VariableDescriptionRequired
ALLOW_ONLY_NON_DESTRUCTIVE_TOOLSDisable delete/exec-class tools for a read-safe modee.g. trueOptional

Example prompts to try

  • Why is checkout-service crash-looping in production? Investigate and report.
  • Summarise everything running in the payments namespace and its resource usage.
  • Scale the worker deployment to 5 replicas and watch the rollout.

Frequently asked questions

Whatever your current kubeconfig context points at — same resolution as kubectl. Context switching (or a dedicated scoped kubeconfig) is how you control its reach.