Stop Pasting kubectl Output Into Your Chat Window

You know the workflow. You're in the middle of a coding session with an AI assistant, and suddenly you need to check what's running in your cluster. So you switch terminals, run kubectl get pods, copy the output, paste it back into the chat, and hope the AI parses it correctly. Then you need to scale a deployment, so you do it all over again. It's clunky, error-prone, and breaks your flow entirely.

That's the problem mcp-server-kubernetes is built to solve. It's a TypeScript-based Model Context Protocol (MCP) server that gives your AI tools direct, structured access to your Kubernetes cluster through kubectl and Helm. Instead of copying and pasting, you just ask—and the tools go run the commands for you.

What It Does

At its core, this is a bridge. It sits between an MCP-compatible client (like Claude Code, Codex CLI, or Claude Desktop) and your Kubernetes cluster. The server reads your existing kubeconfig, connects to whatever context you have configured, and exposes cluster operations as MCP tools that your AI assistant can call directly.

The architecture is straightforward. It's written in TypeScript and runs as a standard MCP server over stdio. Rather than talking to the Kubernetes API directly, it shells out to tools you already have installed—kubectl for cluster management and Helm v3 for chart operations. That's a sensible design choice: it means the server inherits all your existing authentication, context switching, and cluster configuration without needing to reimplement any of it.

Kubeconfig loading follows a priority order, though the README notes the default behavior loads from ~/.kube/config. There's an advanced README that covers additional authentication options like environment variables and custom paths, so you're not locked into the default location if your setup is more complex.

Why It's Cool

The thing that stands out here is how pragmatic the whole approach is. Let me break down what makes it interesting:

It doesn't reinvent the wheel. The server doesn't try to be a full Kubernetes client library. It uses kubectl and Helm, which means whatever authentication you've already configured—whether that's a cloud provider credential, a local minikube context, or something more exotic—just works. You don't need to set up service accounts or manage API tokens for the MCP server itself.

It's genuinely zero-config for common setups. If you already have kubectl working from your terminal, you're essentially ready to go. The README asks you to verify with kubectl get pods first, and that's it. No cluster-side installation, no RBAC changes, no new credentials to manage.

The client support is broad and getting broader. Claude Code, Codex CLI, Claude Desktop, VS Code, and even a mcpb extension for Claude Desktop's extension marketplace. That last one is nice—you can install it like a regular extension and it handles the kubectl dependency for you.

It operates at the level you actually work at. You're not writing YAML and API calls. You're having a conversation. "What's running in the default namespace?" "Scale that deployment to three replicas." "Show me the Helm releases." The server translates those into the right kubectl or Helm invocations.

Helm support is included but optional. You only need Helm v3 installed if you plan to use Helm features. That's a thoughtful touch—not everyone uses Helm, and the server doesn't force it on you.

How to Try It

Getting started depends on which MCP client you use, but they're all quick. The prerequisites are simple: kubectl in your PATH, a valid kubeconfig with configured contexts, access to a working cluster (minikube, Rancher Desktop, GKE, whatever), and Helm v3 if you want Helm features.

For Claude Code, it's one command:

claude mcp add kubernetes -- npx mcp-server-kubernetes

For Codex CLI, it's equally simple:

codex mcp add kubernetes -- npx mcp-server-kubernetes

That registers the server globally in ~/.codex/config.toml, making its tools available across all your Codex sessions.

For Claude Desktop, add this to your config file:

{
  "mcpServers": {
    "kubernetes": {
      "command": "npx",
      "args": ["mcp-server-kubernetes"]
    }
  }
}

There's also a VS Code one-click install link in the README, and if you're using Claude Desktop, you can find it in the Extensions marketplace under mcpb. A manual .mcpb download from the latest release works too.

Before you start, run kubectl get pods in your terminal to confirm your cluster connection is solid. The README is explicit about this—it'll save you debugging a credential issue through an AI assistant later.

Final Thoughts

This is one of those tools that feels obvious once you see it. If you're already using MCP clients and spending any time managing Kubernetes clusters, it removes an entire category of friction from your workflow. It's not flashy, but it's genuinely useful, and the decision to lean on kubectl and Helm rather than building a parallel auth system is the kind of pragmatic choice that makes a tool worth adopting.

The project is actively maintained, welcomes PRs, and has CI running, so it's not a stale side project. If you work with Kubernetes and an AI coding assistant, give it a shot. The setup takes about two minutes, and you might find yourself wondering how you managed clusters in chat before.

Follow @githubprojects for more developer tools and open source projects.