Kubernetes for DevOps automation
DevOps automation is about letting an agent operate real infrastructure: inspect what is running, find what broke, and act on it. This native Kubernetes and OpenShift server is our third pick of four, and its lane is precise, it operates the cluster itself, not the cloud account or the build runtime around it.
It earns third because the scope is the orchestration layer rather than the whole platform. AWS (AWS Labs) reaches across a hyperscaler's services, and Google Cloud Run covers managed container hosting on GCP. Where the work is diagnosing and operating containerized workloads on a Kubernetes cluster, this server is the direct tool.
How Kubernetes fits
An agent debugging a deployment uses pods_list and pods_list_in_namespace to see what is scheduled, pods_get to inspect a single pod, and events_list to read the warnings and state changes that explain a crash loop. nodes_log pulls kubelet and system logs, while nodes_top, pods_top, and nodes_stats_summary surface CPU and memory pressure. configuration_view confirms which cluster and context the agent is acting against. For action, pods_delete restarts a stuck pod and pods_exec opens a shell inside one to run a command.
The limits are worth stating. This is a cluster client, so it does not provision cloud resources, manage IAM, or build images. The tool set here also centers on pods and nodes rather than higher-level objects like Deployments or Services as first-class write targets. For account-wide automation across a cloud, AWS fits better; for deploying a container without managing a cluster, Google Cloud Run is simpler; and Docker is the pick when the work is the local container runtime under a build. Reach for this server when the cluster is the thing you need to read and operate.
Tools you would use
| Tool | What it does |
|---|---|
| configuration_view | Get the current Kubernetes configuration content as a kubeconfig YAML (minified to the current context by default). |
| events_list | List Kubernetes events (warnings, errors, state changes) for debugging and troubleshooting in the current cluster. |
| namespaces_list | List all the Kubernetes namespaces in the current cluster. |
| nodes_log | Get logs from a Kubernetes node (kubelet, kube-proxy, or other system logs) via the node's proxy endpoint. |
| nodes_stats_summary | Get detailed resource usage statistics from a node via the kubelet's Summary API. |
| nodes_top | List the CPU and memory consumption of nodes as recorded by the Kubernetes Metrics Server. |
| pods_list | List all the Kubernetes pods in the current cluster across all namespaces. |
| pods_list_in_namespace | List all the Kubernetes pods in a specified namespace. |
| pods_get | Get a Kubernetes pod by name in the current or provided namespace. |
| pods_delete | Delete a Kubernetes pod by name in the current or provided namespace. |
FAQ
- Can this Kubernetes MCP server restart a failing pod?
- Yes. pods_delete removes a pod by name, and the cluster reschedules it under its controller, which is the usual way to restart a stuck workload. To investigate first, events_list and nodes_log surface why it failed, and pods_exec lets the agent run a command inside a running pod.
- Does it provision cloud infrastructure like databases or load balancers?
- No. It operates an existing Kubernetes or OpenShift cluster through the Kubernetes API, listing, inspecting, and managing pods, nodes, and namespaces. For provisioning cloud services the AWS server fits better, and Google Cloud Run handles managed container deployment on GCP.