Claude Kubernetes connectorWhat Claude can do on your Kubernetes cluster.
The Claude Kubernetes connector exposes 22 tools. 6 read your cluster, 12 can change it (from applying a manifest to deleting resources or draining a node), and 4 are not clearly documented. Below: what each does, how to keep it non-destructive, and what your machine needs first.
Verified Trustpilot reviews · AI, automation & growth agency
What changes when Claude can drive kubectl
This connector is an extension that runs on your own computer, inside Claude Desktop. It uses the kubectl command-line tool and the kubeconfig file already on your machine, and connects to whatever cluster your current context points to. You describe what you want in plain words; Claude picks the matching kubectl or Helm operation and shows you the result.
Look before you touch. Claude can list or fetch resources with kubectl_get, inspect one with kubectl_describe, read container logs with kubectl_logs, and ask explain_resource what a field means. Secrets come back masked in get commands, according to the publisher.
Ship a change from the conversation. kubectl_apply applies a YAML manifest, kubectl_patch edits fields, kubectl_scale resizes a deployment and kubectl_rollout manages its rollout. Helm charts install, upgrade and uninstall through three dedicated tools.
Maintenance on a node. node_management cordons, drains and uncordons nodes for maintenance or scaling.
What to keep in mind: this set goes far beyond reading. kubectl_delete removes resources and kubectl_generic runs any kubectl command, which the publisher warns may include destructive ones. A non-destructive mode turns those off. Claude also cannot add new clusters to your configuration, and nothing runs on a schedule. For the bigger picture of connectors covered, see the Integrations hub.
Five words before you install
The vocabulary Claude uses around this connector, in one minute.
- Connector
- A link you set up once between Claude and something you already run, here your Kubernetes cluster, so Claude can work on it.
- Tool
- One named action the connector gives Claude, such as fetching logs. Claude chooses which ones to call while it answers you.
- Authorization
- The step where you grant the access Claude will use. Here, that access is whatever your local kubeconfig already allows.
- Approval
- The confirmation Claude waits for before an action that changes something, such as deleting a pod, shown in the conversation.
- MCP
- The open standard connectors are built on: it is what lets an assistant like Claude drive an outside tool such as kubectl.
Connect Kubernetes to Claude in three steps
- 01
Find the extension
The publisher's README gives this path: in Claude Desktop, open Settings (Cmd+, on Mac), then Extensions, then Browse Extensions, and scroll to mcp-server-kubernetes. If your version of the app labels things differently, search the directory for Kubernetes MCP Server.
- 02
Turn it on
Install it from there. The publisher says the extension then runs kubectl through the command line with your kubeconfig. If Claude reports errors, open a regular terminal and run kubectl get pods to check that your cluster answers without credential issues.
- 03
Check what it can reach
The extension acts with the access of your kubeconfig, not a separate login. Make sure the current context points at the cluster you mean before you ask Claude anything.
The 22 Kubernetes tools, read versus write
Kubernetes MCP Server gives Claude 22 tools: 6 that read your account, 12 that change something in it, and 4 no official source describes.
Three groups: what Claude reads, what it changes on the cluster, and what no source documents clearly. Names stay exactly as Claude shows them.
- 6 read
- 12 write
- 4 not documented
What Claude reads (6)
6 toolsSix tools that check the connection, list, describe, explain and read logs without changing the cluster.
ping
Checks that the extension can reach your cluster at all. The publisher presents it simply as the tool that verifies the connection to the cluster.
kubectl_get
Gets or lists resources such as pods, deployments or services, the everyday kubectl get. The publisher says secret values come back masked in these commands.
kubectl_describe
Returns the detailed description of one resource, the same view kubectl describe gives, without typing the command yourself. It only reads, so the resource stays exactly as it was.
kubectl_logs
Fetches the logs of a container so Claude can read them with you. The publisher notes that the masking applied to secrets in get commands does not cover logs.
explain_resource
Explains what a Kubernetes resource or field is for, the kubectl explain view, so you can read the reference without leaving the chat.
list_api_resources
Lists the API resource types the cluster knows, which shows what can be queried on that particular cluster. It only reads, so the cluster stays exactly as it was.
What Claude changes (12)
12 toolsTwelve tools that create, alter or remove things on the cluster. No source spells out their confirmation, so the general rule below applies.
cleanup
Approval: see the ruleRuns a cleanup of the resources the extension manages. The publisher only describes it in one line and counts it among destructive operations switched off in non-destructive mode.
kubectl_apply
Approval: see the ruleApplies a YAML manifest to the cluster, which can bring a new resource to life or bring an existing one in line with the file. It stays available in non-destructive mode.
kubectl_delete
Approval: see the ruleDeletes Kubernetes resources, any kind. The publisher lists it first among destructive operations and disables it in non-destructive mode.
kubectl_create
Approval: see the ruleCreates resources on the cluster, the kubectl create counterpart. It is one of the operations the publisher keeps allowed in non-destructive mode.
kubectl_patch
Approval: see the ruleUpdates one or more fields of an existing resource without resending the whole manifest. Allowed in non-destructive mode, according to the publisher.
kubectl_rollout
Approval: see the ruleManages deployment rollouts, the kubectl rollout family. The publisher keeps it allowed in non-destructive mode.
kubectl_scale
Approval: see the ruleScales resources such as deployments up or down. The publisher says it replaces an older scaling tool and remains available in non-destructive mode.
kubectl_generic
Approval: see the ruleExecutes any kubectl command, beyond the dedicated tools. The publisher warns it may include destructive operations and turns it off in non-destructive mode.
install_helm_chart
Approval: see the ruleInstalls a Helm chart on the cluster, with support for custom values, repositories and versions. It needs Helm v3 on your machine.
upgrade_helm_chart
Approval: see the ruleUpgrades an installed Helm release, again with custom values, repositories or a target version. It remains allowed in non-destructive mode.
uninstall_helm_chart
Approval: see the ruleUninstalls a Helm release from the cluster. The publisher classes it as destructive and disables it in non-destructive mode.
node_management
Approval: see the ruleCordons, drains and uncordons nodes for maintenance or scaling. The publisher notes it can drain nodes and disables it in non-destructive mode.
Not documented (4)
4 toolsFor these four, no source says whether they only read or change the cluster, and two have no description at all.
kubectl_context
The publisher's README lists it for managing kubectl contexts, and that is all: no source says whether it only reads them or switches the active one, so we do not classify it.
exec_in_pod
The directory lists this name, but the publisher's README never describes it and no Claude page does either. We have no text to go on, so this page says nothing about its effect.
port_forward
The README lists it under connectivity, next to pods and services. No source says whether that counts as reading or changing anything on the cluster, so it stays in this group.
stop_port_forward
This name only appears in a list of operations the publisher keeps in non-destructive mode, with no sentence describing it. Without a source, the page leaves its role blank rather than guess.
What Claude asks before acting
By default, Claude stops and asks before each action it takes on an account for someone. On a cluster, that rule is your first safety net.
No source describes a specific confirmation for any of the 12 write tools, so that default is what covers deleting, patching, scaling or draining. The publisher adds a second net on its side: a non-destructive mode that hides delete, uninstall, cleanup, node management and the generic command. On Team and Enterprise workspaces, owners can also restrict what a connector may do for the organization. And Claude only reaches what your kubeconfig already reaches.
Which plans can use it
No official source publishes plan availability connector by connector, and none of the 819 directory sheets shows it.
The published rule is general: desktop extensions install on Claude Desktop, while remote connectors are open to all users on Claude, Cowork, Claude Desktop and mobile. On Team and Enterprise, an Owner or Primary Owner opens a connector for the organization before members use it. For this extension's current state, its sheet in the official directory is the place to check.
Where the Kubernetes connector stops
A connector is not an automation. Claude calls these tools while it answers you, so nothing reacts by itself when a pod crashes or a node goes down.
Everything here comes from the publisher's README: no Claude help page covers this extension. The partner badge is not a security audit, and Anthropic states it neither picks the tools a publisher exposes nor guarantees they behave as announced. Here that matters more than usual, because several tools can remove or disrupt workloads. The publisher's own safeguard is the non-destructive mode described above.
Need help connecting Kubernetes MCP Server to Claude?
A person reads every message.
