kubectl-mcp-server: A Kubernetes MCP Server That Exposes 253 Tools to AI Assistants
Published in CNCF Landscape: A MCP server for Kubernetes.
At a glance
- What is it?
- The project wraps kubectl operations into a Model Context Protocol server so assistants like Claude and Cursor can query and act on clusters. It is broad in surface area, and that breadth is exactly what to scrutinise before pointing it at a production cluster.
- Who is it for?
- Adopt kubectl-mcp-server if you want an AI assistant to read cluster state (logs, events, RBAC, resource usage) without leaving the chat window, and you are prepared to run it against a non-production cluster first. Do not adopt it as your only path to production changes until you have verified two things yourself: which tools remain available when non-destructive mode is enabled, and how the OAuth 2.1 path behaves in your setup.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 160 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap kubectl-mcp-server fills between a cluster and a chat window
An assistant that can read a repository cannot see a cluster. The README frames the problem as context-switching: you leave the conversation, open a terminal, run kubectl get pods, paste the output back. kubectl-mcp-server removes that step by presenting Kubernetes operations to the assistant as MCP tools, so the assistant calls them directly. The stated audience is anyone already using an MCP-capable assistant for infrastructure work: the README lists Claude, Cursor, Windsurf, Copilot and, by its own count, 15 or more other tools. The project is Python, MIT licensed, published to both PyPI and npm, and a Docker image is referenced at rohitghumare64/kubectl-mcp-server. It also appears in the CNCF Landscape, which the README mentions in its header. That last point is a directory listing, not an endorsement, and it should be read as such.
What the server actually exposes: tools, prompts and resources
The README's own count is 253 tools, 8 workflow prompts and 8 data resources. Tools are the callable operations. Prompts are pre-written workflows the assistant can invoke, and resources are data the assistant can read. The tool surface is grouped by task: crash diagnosis, deployment, cost analysis, network connectivity, security audit and dashboards. Two optional groups sit outside the default set. Installing with the [ui] extra adds six interactive dashboard tools that render HTML dashboards with live metrics. A separate browser automation group adds 26 tools for web-based tools. The README also describes 24 agent skills for AI coding agents, and an in-cluster deployment mode it calls kMCP. The default installation therefore exposes far fewer than 253 tools; the headline number is the union of the optional groups. That distinction matters when you are deciding what an assistant can reach.
Getting it running: npx, pip, Docker and an MCP client entry
The README gives three installation routes. The recommended one is zero-install via npx:
npx -y kubectl-mcp-server
or globally with npm install -g kubectl-mcp-server. The Python route is pip install kubectl-mcp-server, with pip install kubectl-mcp-server[ui] to add the interactive dashboards, which the README recommends. Docker is listed as a third option. Beyond installation, the README points to a Quick Setup with Your AI Assistant section and a CLI section, but the supplied material does not include the contents of either, so the exact MCP client configuration block is not something I can reproduce here. What can be said is structural: an MCP server is registered in the client's configuration, and this project ships as both a Python package and an npm package, so the same server can be launched by whichever runtime your client expects. The README also references advanced configuration and an enterprise OAuth 2.1 authentication mode, again without the underlying keys in the material provided.
Diagnostics, cost analysis and security audit as named tool groups
The README's example prompts map onto tool groups rather than single commands. "Why is my pod crashing?" is described as combining logs, events and resource analysis into a root cause with recommendations. "Show me which pods are wasting resources" is framed as cost optimisation with savings estimates. "Audit security across all namespaces" covers RBAC permission analysis, secret scanning and pod security policies. "Which services can't reach the database?" is network diagnostics with DNS resolution and service chain tracing from ingress down to pods. These are composite behaviours: the assistant is expected to chain several tool calls and synthesise an answer. That is the actual value proposition, and it is also where the project is hardest to evaluate from documentation alone. A composite answer is only as good as the individual calls underneath it, and the README does not document how the chaining is constrained or what happens when one call in the chain fails.
Safety controls the README claims, and what they do not settle
The project advertises OAuth 2.1 authentication, RBAC validation, a non-destructive mode and secret masking. Those are the right categories of control for a tool that hands an LLM write access to a cluster. Non-destructive mode is the one to understand precisely: the README does not state which tools are removed or blocked when it is enabled, so you cannot assume that enabling it leaves you with a read-only server. Secret masking is similarly underspecified in the material I have; whether it masks at the tool boundary or in the returned payload is not stated. RBAC validation is listed alongside the others without detail. None of this means the controls are weak. It means the documentation does not let you reason about their boundaries, and boundaries are the whole point of a safety feature. Treat the README's control list as a starting point for your own inspection, not as a specification.
Where kubectl-mcp-server is the wrong tool
The most obvious mismatch is deterministic automation. If you need a pipeline step that applies a manifest and fails the build on a non-zero exit code, an MCP server is the wrong layer: the assistant is in the loop, and the assistant's output is prose. Use kubectl, Helm or a GitOps controller for that, and keep the MCP server for interactive investigation. The second mismatch is scale of exposure. A server with 253 tools, optional browser automation and an in-cluster mode gives an assistant a wide reach. If your requirement is that an assistant may read pod logs and nothing else, a smaller purpose-built MCP server is easier to reason about than a broad one you have to narrow down. The third is the missing detail I flagged above: without knowing exactly what non-destructive mode blocks, you cannot safely point this at a cluster where a mistaken write is expensive. The project's own README leans on natural-language convenience, and convenience and least privilege pull in opposite directions here.
Alternatives and the difference in approach
The clearest alternative is not another MCP server but the plain kubectl CLI plus a shell-capable assistant. The difference is the trust boundary. With kubectl, the assistant writes a command and you see it before it runs; the command is the artefact under review. With kubectl-mcp-server, the assistant selects a tool and supplies arguments, and the tool's implementation decides what reaches the API server. That is faster and less repetitive, and it moves the review point from the command line to the tool definition. If you want to keep reviewing the exact command, stay with kubectl. If you accept reviewing the tool surface once and then trusting it, the MCP route is the point of the project. A second alternative is writing a narrow MCP server of your own for the handful of read operations you actually need. That trades the 253-tool surface for something you can audit in an afternoon, at the cost of the composite diagnostics and dashboards this project already ships.
Maintenance, licensing and what to check before adopting
The licence is MIT, which permits commercial use and modification with the licence text retained; that is a summary of the identifier, not legal advice, and your own counsel should confirm obligations for your distribution model. The repository is not archived, and the release cadence in the supplied material is roughly monthly around early 2026: v1.23.0 and v1.23.1 in early February, v1.24.0 in late February. The last push is dated 2026-04-08. The README claims 234 tests passed in one badge and 216 passing tests elsewhere on the same page, which is an inconsistency worth noting rather than a red flag on its own. Two distribution channels (PyPI and npm) plus a Docker image mean more than one artefact to keep current, and the optional [ui] and browser automation extras add dependency weight that a plain install avoids. Before adopting, verify the tool list your client actually receives after startup, confirm what non-destructive mode removes, and check whether the OAuth 2.1 path is required for your deployment or whether it is only relevant to the enterprise configuration the README mentions.
Editorial conclusion
Adopt kubectl-mcp-server if you want an AI assistant to read cluster state (logs, events, RBAC, resource usage) without leaving the chat window, and you are prepared to run it against a non-production cluster first. Do not adopt it as your only path to production changes until you have verified two things yourself: which tools remain available when non-destructive mode is enabled, and how the OAuth 2.1 path behaves in your setup. Start with npx -y kubectl-mcp-server against a throwaway cluster and inspect the tool list before wiring it into a kubeconfig that can reach anything you care about.
Community notes