This post designs the Kubernetes client. The next post wraps it as an MCP server and wires it to an agent.
Asking instead of running
There's a familiar rhythm to debugging a bad deploy: kubectl get pods, spot the CrashLoopBackOff, kubectl logs --previous, still not obvious, kubectl describe pod, scroll to Events, cross-reference with kubectl get events, maybe check if the Service even has endpoints. Five or six commands, in your head, in a specific order, because you've done this enough times to know the order.
That order is exactly what an AI agent can execute for you, if you give it the right tools, ask "why is checkout-service failing?" and have it chain through the same commands you would have, arriving at an actual answer instead of a wall of YAML. The protocol that makes an agent capable of calling tools like that is the Model Context Protocol (MCP), and building that server is part 2 of this series.
This post is about what comes first and matters more: the Kubernetes client those tools will eventually sit on top of. An agent is only as good as what it's allowed to ask for. Hand it a client with one ListPods method and it can list pods, nothing else. Hand it a client that mirrors what a senior engineer actually checks when something's broken, pod state, events, endpoints, node capacity, rollout history, and it can genuinely diagnose. That client is a real piece of engineering on its own, independent of whether an LLM ever touches it, which is why it gets its own post before MCP enters the picture at all.
