mrkeyoor.com_
Tue 01 Sept 16:16 UTC

This page is what happened when we ran it. The project itself — code, maintenance, community — has its own review: full repo review →

CloudMCP servermeasured 19 Aug 2026

Kubernetes

The Kubernetes MCP server, mcp-server-kubernetes by Flux159, hands an AI agent your kubectl. It is a community project, not a CNCF or vendor release, and it wraps get, apply, patch, delete, logs, describe, scale, rollout, exec, port-forward and Helm install into MCP tools that run against whatever kubeconfig context the process can see.

BootBOOTS ✓We started it and initialize came back in 26.3s.
Tools23tools/list payload 23,854 bytes
Context tax~5,964estimated tokens for the whole tools/list, chars/4 estimate
Resources / prompts5 / 1counts returned by resources/list and prompts/list
Measured19 Aug 2026one run of the harness, clean environment, no credentials · how we test

How we started it

npx -y mcp-server-kubernetes
Verdict

Use it if you want an agent doing read-heavy cluster triage, and only if you have pointed it at a context where the worst possible command is survivable. The tools are thorough and the descriptions are honest about what they do, which is exactly the problem: kubectl_delete, kubectl_patch and exec_in_pod are one confident hallucination away from a bad afternoon. It boots clean with no env vars and no auth dance, so the only thing standing between the model and production is your kubeconfig hygiene. That is a thin wall.

Use it if

You want an agent to read logs, describe pods and explain why a deployment is stuck, against a context scoped to one non-critical namespace
You already live in kubectl and want the same verbs without leaving the chat, including kubectl_generic for the flags nobody wrapped
You run Helm and want install, upgrade and uninstall driven from the same session as the debugging
You need port_forward and stop_port_forward for a quick local look at a service, and you remember to call cleanup

Skip it if

Your default kubeconfig context points at production and you have not built a read-only one to swap in
You cannot tolerate exec_in_pod and kubectl_delete existing in the tool list at all, and your client has no per-tool disable
Your agent session is already tight on context; this payload is the third-largest single spend in most configs it lands in
You wanted a managed, vendor-supported integration with an audit trail; this is a community npm package and the version we booted moves fast
You are on a cluster where RBAC for your user is broad, since the server inherits every permission your kubeconfig has

The bill for your context window

ToolEst. tokensDescribed?Required params
kubectl_create~995yes (82 chars)0
node_management~383yes (67 chars)1
kubectl_delete~380yes (83 chars)0
kubectl_logs~354yes (66 chars)3
install_helm_chart~339yes (83 chars)3
kubectl_patch~324yes (90 chars)2
kubectl_get~322yes (81 chars)1
kubectl_rollout~320yes (75 chars)4

Its tools/list is 23,854 bytes, about 5,964 tokens by the chars/4 estimate, for 23 tools. That is heavy for a directory whose median server lands near two thousand, and the weight is distributed oddly: kubectl_create alone accounts for roughly a sixth of the payload because its schema enumerates resource kinds, while cleanup, ping and stop_port_forward cost almost nothing. The description text is not the culprit; most tool descriptions are one line. The JSON schemas are. If your client lets you disable tools, dropping the Helm trio and kubectl_create buys back real room without touching the triage workflow you probably came for.

Setup reality

There is nothing to configure, which is the whole story. We started it with npx and it printed "Starting Kubernetes MCP server v4.1.4, handling commands..." with telemetry disabled and no environment variables requested; the harness recorded zero env hints. Auth is your existing kubeconfig, so the server is exactly as privileged as the shell that launched it. First boot took 26,252 ms because npx was resolving the package cold, and the install log is noisy with deprecation warnings from transitive deps. Restarts are far quicker. If you want safety, the work is outside the server: a dedicated context, a service account with narrow RBAC, and kubectl_context pinned before anything else runs.

Questions people ask

Does the Kubernetes MCP server need any API keys or environment variables?

No. We booted it with a clean environment and it recorded no env hints; it authenticates by reading your kubeconfig the same way kubectl does. That also means it inherits your permissions, so the security question is which context you leave selected, not which secret you set.

Can I make it read-only?

Not from the server side in the build we measured; all 23 tools are listed unconditionally, including delete, patch and exec_in_pod. The README describes a non-destructive mode via environment flag, so check the current docs. Otherwise, enforce it with RBAC on a dedicated service account.

Is that startup time the server's fault?

That was npm, not the server. Our first run resolved and installed the package from scratch under npx, which dominated the 26,252 ms we recorded; the server itself announces readiness immediately after. A warm cache or a global install makes startup unremarkable.

What does it actually expose besides tools?

Alongside the tools it advertises 5 resources and 1 prompt, which is more than most servers in this directory bother with. The resources cover cluster objects your client can read directly rather than through a tool call, which is cheaper when it works.

Other cloud servers we started

ServerVendorBootsContext tax
Azure MCPMicrosoft~0 tokens
HerokuHeroku~0 tokens
NetlifyNetlify~3,083 tokens

How this page is made: the server is spawned as an unprivileged user with a clean environment and no credentials, then asked for its tools, resources and prompts over stdio. Token figures are estimates at four characters per token, not a tokenizer count. One run, one machine. Corrections: contact the desk.

← All measured MCP servers