Atlas inspects pods, deployments, and container logs through kubernetes-mcp-server, a native client-go server rather than a kubectl shell wrapper, so it can explain a CrashLoopBackOff and patch the manifest. Add it with atlas mcp add kubernetes --env KUBECONFIG=$HOME/.kube/config -- npx -y kubernetes-mcp-server@latest, and keep 'kubectl delete *' set to deny under permission.bash.
Why kubernetes-mcp-server is a client-go server, not a kubectl wrapper
Atlas inspects pods, deployments, and container logs through kubernetes-mcp-server, which is a native client-go server rather than a kubectl shell wrapper. In 2026 that distinction matters: Atlas receives structured objects from the Kubernetes API instead of parsing the text output of a kubectl command.
Shelling out to kubectl and reading the printed table is how most naive integrations work, and it is fragile. Output formats change, wide mode truncates, and the agent ends up regexing a human-facing display. kubernetes-mcp-server skips that by using client-go, the same Go client kubectl itself is built on. Atlas gets pods, deployments, and container logs as real API objects. That is what makes it possible for Atlas to explain a CrashLoopBackOff precisely, because it can read the previous container's termination state rather than guessing from a status column.
Adding kubernetes-mcp-server to Atlas
Add the server with atlas mcp add kubernetes --env KUBECONFIG=$HOME/.kube/config -- npx -y kubernetes-mcp-server@latest. In 2026 the KUBECONFIG environment variable is what points kubernetes-mcp-server at your cluster and your current context, so Atlas connects to exactly the cluster kubectl would.
The Node route is the quickest, and it is the one most developers use on a laptop that already has npx. KUBECONFIG=$HOME/.kube/config is the default location, so if your kubeconfig lives elsewhere, point the env var at the real path. Because kubernetes-mcp-server honors the kubeconfig, it also honors the active context. Switch context with kubectl before you start Atlas, or you will be debugging staging while looking at production names. There is no separate cluster credential to configure for Atlas: the kubeconfig is the credential.
Running kubernetes-mcp-server on Python or in Docker
kubernetes-mcp-server ships 3 ways in 2026, so Atlas can use whichever runtime you already have. Beyond npx, the same server is on PyPI as uvx kubernetes-mcp-server@latest and as the container image ghcr.io/containers/kubernetes-mcp-server. All 3 expose the same pod, deployment, and log tools.
Kubernetes operators tend to be Python and Go people rather than Node people, and forcing a Node install onto a jump box to run an MCP server is a bad trade. Use uvx kubernetes-mcp-server@latest if uv is already your Python runner, or run ghcr.io/containers/kubernetes-mcp-server if you would rather keep the server inside a container image you can pin and scan. The choice is about the runtime you already maintain. Atlas sees an identical set of Kubernetes capabilities in every case, and the KUBECONFIG rule is the same.
Running Atlas and kubernetes-mcp-server in-cluster
Running in-cluster, kubernetes-mcp-server reads the mounted service account instead of KUBECONFIG. There is no separate token env var to set in 2026. Deploy the server into the cluster with a service account bound to the roles you want Atlas to have, and the permissions follow from that binding.
In-cluster is the right shape when Atlas is running inside the cluster it is debugging, or when your security model says developer kubeconfigs should not leave a workstation. kubernetes-mcp-server detects the in-cluster environment and reads the mounted service account token that Kubernetes projects into the pod. Because there is no separate token env var, the only lever you have is RBAC on the service account, which is the correct lever. Bind it to read pods, deployments, and logs, and Atlas gets exactly that much and no more.
Explaining a CrashLoopBackOff with Atlas
The signature Atlas and Kubernetes workflow in 2026 is a CrashLoopBackOff. Ask Atlas to find the CrashLoopBackOff pod, read its previous container's logs, and explain the exit code. kubernetes-mcp-server gives Atlas the previous container's output, which is where the real cause almost always lives.
A CrashLoopBackOff pod is by definition not running, so the current container has nothing useful to say. The previous container's logs do. Atlas reads them through kubernetes-mcp-server, pairs them with the exit code from the termination state, and explains what actually happened: an out of memory kill, a failed migration at boot, a missing environment variable. Because Atlas is running in your repository, it does not stop at the explanation. It can point at the code path that produced the exit and propose the change that stops it recurring.
Patching a Deployment manifest under review
Atlas can patch a Deployment's resource limits and readiness probe, then show you the manifest diff before kubectl apply. In 2026 that is the safe division of labor for Kubernetes: kubernetes-mcp-server reads the live cluster state, Atlas proposes the manifest change, and you decide whether it ships.
Resource limits and readiness probes are the two knobs most often wrong on a struggling Deployment, and both are guesses unless you can see the real numbers. Atlas reads the live pod state through kubernetes-mcp-server, so the limits it proposes are informed by what the workload actually consumed before it was killed. The manifest is a file in your repository, so the change arrives as a diff. Keep 'kubectl delete *' set to deny under permission.bash so Atlas can never tear down a workload unattended, and the worst outcome of a bad suggestion is a diff you decline.
Setup
- 01Add the server with atlas mcp add kubernetes --env KUBECONFIG=$HOME/.kube/config -- npx -y kubernetes-mcp-server@latest
- 02If you prefer Python or a container, the same server ships as uvx kubernetes-mcp-server@latest on PyPI and as the image ghcr.io/containers/kubernetes-mcp-server.
- 03Running in-cluster, skip KUBECONFIG entirely: kubernetes-mcp-server reads the mounted service account, and there is no separate token env var.
- 04Keep 'kubectl delete *' set to deny under permission.bash so Atlas can never tear down a workload unattended.
- 05Ask Atlas to find the CrashLoopBackOff pod, read its previous container's logs, and explain the exit code.
- 06Let Atlas patch the Deployment's resource limits and readiness probe, then diff the manifest before kubectl apply.
Frequently asked questions
- how to connect atlas to a kubernetes cluster
- Run atlas mcp add kubernetes --env KUBECONFIG=$HOME/.kube/config -- npx -y kubernetes-mcp-server@latest. The kubeconfig is the credential, so Atlas targets the same cluster kubectl would.
- is kubernetes-mcp-server a kubectl wrapper
- No. kubernetes-mcp-server is a native client-go server rather than a kubectl shell wrapper, so Atlas reads structured API objects instead of parsing kubectl text output.
- how do i run kubernetes-mcp-server in docker
- Use the image ghcr.io/containers/kubernetes-mcp-server. The same server also ships on PyPI as uvx kubernetes-mcp-server@latest, so pick whichever runtime you already have.
- how does kubernetes-mcp-server authenticate in-cluster
- Running in-cluster it reads the mounted service account instead of KUBECONFIG. There is no separate token env var, so RBAC on the service account is the control.
- can atlas explain a crashloopbackoff
- Yes. Ask Atlas to find the CrashLoopBackOff pod, read its previous container's logs, and explain the exit code. The previous container's output is where the cause lives.
- can atlas delete my kubernetes deployment
- Not if you configure it correctly. Keep 'kubectl delete *' set to deny under permission.bash so Atlas can never tear down a workload unattended.
- can atlas fix a readiness probe or resource limits
- Yes. Let Atlas patch the Deployment's resource limits and readiness probe, then diff the manifest before kubectl apply.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas with DeepSeek Coder 33B (Ollama): Local Setup and Tradeoffs in 2026
DeepSeek Coder 33B (Ollama) drives Atlas locally from 19GB of weights with a 16K token context and no API bill. Setup, VRAM budget, and honest tradeoffs for 2026.
Atlas with Qwen3.6 Plus: The Stable Million-Token Tier in 2026
Qwen3.6 Plus gives Atlas 1M tokens (1,000,000) of context at $0.50 per Mtok input and $3.00 per Mtok output, matching Qwen3.7 Plus while keeping 3.6 generation behavior.
Atlas with Amazon Nova Pro: Bedrock Billing and a 300K Window (2026)
Amazon Nova Pro runs Atlas at $0.80 / $3.20 per Mtok on a 300,000 token window, billed through your existing AWS account with no new vendor contract.
Atlas with Kimi K2.7 Code: Open Weights at Trillion-Parameter Scale (2026)
Kimi K2.7 Code drives Atlas at $0.95 / $4 per Mtok on a 262,144 token window. Open weights, 1T total parameters, served by four independent providers.
Atlas vs Jules: Terminal AI Coding Agents in 2026
Atlas and Jules comparison for 2026. Atlas offers terminal-native TUI and local code indexing. Jules provides cloud VMs and a Critic agent for PR review.
Atlas vs Zed: Terminal AI Coding Agents in 2026
Comparing Atlas, the terminal-native AI coding agent, with Zed, the GPU-accelerated collaborative editor, for developers in 2026. Evaluate their AI autonomy, privacy, and workflow.
Atlas with Devstral 2: Mistral's Agent-First Coding Model in 2026
Devstral 2 in Atlas: Mistral's agent-trained coding model with a 262,144 token window at $0.40 / $2 per Mtok, loaded through @ai-sdk/mistral. Setup and tradeoffs.
Atlas with Grok 4.20 (Non-Reasoning) in 2026: Fast, Predictable Edit Passes
Grok 4.20 (Non-Reasoning) bills no thinking tokens, so cost per turn is fully predictable at $1.25 / $2.5 per Mtok, with the same 1,000,000 token context as the reasoning variant.