The Kubernetes MCP server gives an agent access to cluster state: pods, deployments, services, events and logs. Debugging Kubernetes is largely a matter of gathering the right five pieces of information from four different commands, which makes it a natural fit for something that can run all of them and read the output.
What it actually does
The server uses your kubeconfig to talk to a cluster and exposes inspection operations as tools. Claude can list workloads and their status, describe individual resources, read recent events and pull container logs. The advantage over running the commands yourself is that it can chase a thread: see a pod restarting, read its logs, check the events on its node, and tell you what connects them.
Practical patterns:
- ‘Why is this deployment not coming up?’
- ‘Which pods have restarted in the last hour, and what do their logs say?’
- ‘Compare the resource limits on these two deployments.‘
Why use it
The tedious part of cluster debugging is the fetching, not the thinking. You know roughly what to look at; getting it takes six commands and careful reading. Handing that to an agent shortens the loop between symptom and hypothesis considerably, particularly for the sort of intermittent problem where you need to look at a lot of things quickly.
Gotchas
The server acts against whatever context your kubeconfig currently selects, and the classic failure is being pointed at production while you think you are on staging. Check before you start. Give it a read-only service account unless you have a specific reason not to; an agent with delete permissions on a cluster is a risk with no corresponding upside for diagnosis. Log volume also adds up fast in the context window, so ask for specific pods rather than everything in a namespace.
