Best Kubernetes MCP servers · 2026

The best Kubernetes MCP server in 2026 is Radar.

It was fastest across all 25 faults and on the same 16 faults every arm got right. We build Radar; every result is downloadable and every competitor claim below links to primary documentation.

See the benchmark See the full ranking

Reviewed by Nadav Erell, Skyhook CEO and former Google engineer with a decade of experience across GKE and cloud infrastructure. Checked against our live-cluster benchmark and each server's linked primary documentation on August 10, 2026. We build Radar, so treat this as a sourced vendor comparison, not an independent review. Found a mistake? Email us and we'll fix it.

Our ranking

The five Kubernetes MCP servers, ranked.

Radar ranks first because it combines the fastest measured diagnosis with investigation work completed before the agent asks, explicit writes, simple local installation, and the strongest path to fleet governance.

Radar MCP (opens in a new tab)

Best overall

The fastest server we measured, with investigation work already done before the agent asks: issues, topology, events, changes, logs, ownership, Helm, and GitOps. It also has the clearest path from local open source to a governed fleet endpoint.

containers/kubernetes-mcp-server (opens in a new tab)

Strong standalone API bridge

A compact Go server that talks directly to the Kubernetes API, supports multiple contexts, and can be made strictly read-only. It is easier to treat as infrastructure than the remaining alternatives, but it leaves more of the investigation for the agent to assemble than Radar.

Flux159/mcp-server-kubernetes (opens in a new tab)

Broad control surface, weaker boundary

An independent TypeScript repo, unrelated to Flux CD, with broad kubectl and Helm operations. The breadth is useful, but its subprocess runtime and permissive non-destructive mode leave more safety and governance work to the operator.

k8sgpt (opens in a new tab)

Useful analyzer, narrower server

k8sgpt exposes codified health analyzers to an existing assistant alongside resource, event, log, and cluster-health reads. That is useful, but narrower than a general operational MCP server and it was the slowest MCP arm in our benchmark.

Lens MCP (opens in a new tab)

Capable, but tied to Lens Desktop

A deliberately read-only bridge to clusters and Prometheus already connected to Lens. Requiring a paid Lens plan and a continuously running desktop app makes it the most constrained option here. It was not included in the benchmark.

This is an editorial product ranking, not a composite benchmark score. We weighed diagnosis usefulness, safety, writes, operational coverage, installation, multi-cluster reach, and governance. We build Radar; measured speed and source-verified product facts are separated in the comparison below.

Full comparison

Five Kubernetes MCP servers, seven decisions.

Product behavior today, plus measured speed for the four servers in our benchmark. Every feature claim links to the project's primary documentation.

Kubernetes MCP server comparison across speed, context, safety, installation, multi-cluster support, and governance
Decision	Radar Correlated model	containers repo Native API	Flux159 repo kubectl + Helm	k8sgpt Analyzers	Lens MCP Desktop
The decision
Product model The kind of context and control each project exposes to the agent. Radar MCP docs containers/kubernetes-mcp-server Flux159/mcp-server-kubernetes k8sgpt Lens MCP docs	Strong: Continuously correlated operational model	Native Kubernetes API bridge	kubectl and Helm command surface	Codified analyzer findings plus resource reads	Read-only bridge through Lens Desktop
Measured diagnosis speed Median across all 25 faults, followed by the same 16 correctly diagnosed faults. Lens was not part of the run. Five-arm benchmark	Strong: 38.0s all · 36.0s shared	64.3s all · 55.8s shared	61.5s all · 57.2s shared	119.4s all · 91.0s shared	Not benchmarked
Context returned What the agent gets back before it starts reasoning. Radar MCP docs containers/kubernetes-mcp-server Flux159/mcp-server-kubernetes k8sgpt Lens MCP docs	Strong: Correlated issues, topology, resources, changes, logs, metrics, Helm, and GitOps	Native API objects, events, logs, metrics, Helm, and optional ecosystem toolsets	kubectl output, logs, API discovery, Helm, rollouts, port forwards	Codified analyzers plus resources, events, logs, and cluster health	Read-only kubectl output plus PromQL through Lens
Control and operations
Safety and writes Read-only is a server mode; safe writes still depend on Kubernetes RBAC and client approval. Radar MCP docs containers/kubernetes-mcp-server Flux159/mcp-server-kubernetes k8sgpt Lens MCP docs	Strong: Read tools plus explicit apply, patch, workload, GitOps, CronJob, and node tools with dry-run/verification support	Strict --read-only mode; --disable-destructive is a separate, less restrictive option	Partial: Broad writes. Non-destructive mode still allows create, update, scale, rollout, and Helm apply	Cluster-facing MCP tools read and analyze; filter tools change k8sgpt configuration	Strictly read-only; no MCP write operations
Installation and runtime Radar MCP docs containers/kubernetes-mcp-server Flux159/mcp-server-kubernetes k8sgpt Lens MCP docs	Strong: Single Go binary or in-cluster install; HTTP MCP is on by default	Single Go binary, npx, uvx, container, or Helm; no kubectl subprocess	npx/Node or Docker; invokes kubectl and Helm operations	k8sgpt binary or Helm/operator; stdio and HTTP MCP modes	Lens premium feature; Lens Desktop must stay running
Multi-cluster support Radar MCP docs containers/kubernetes-mcp-server Flux159/mcp-server-kubernetes k8sgpt Lens MCP docs	Strong: Radar OSS follows its connected cluster; Radar Cloud exposes an org fleet through one endpoint	Strong: Multiple kubeconfig contexts at once; context argument on tools	Current kubectl context, with a context-switch tool	One configured cluster context per process; operator supports remote-cluster patterns separately	Strong: Connected EKS, AKS, local, and Teamwork clusters
Governance and audit The layer above kubeconfig and Kubernetes RBAC. Radar MCP docs containers/kubernetes-mcp-server Flux159/mcp-server-kubernetes k8sgpt Lens MCP docs	Strong: OSS inherits local identity/RBAC; Cloud adds SSO, org RBAC, server-side credentials, and per-call audit	Kubernetes RBAC; current HTTP mode supports OAuth/OIDC and optional OpenTelemetry	Kubernetes RBAC; optional OpenTelemetry traces tool calls	Kubernetes RBAC; no separate MCP gateway policy layer	Lens account/team controls plus each connected cluster's credentials

The decision

Product model

The kind of context and control each project exposes to the agent.

Radar MCP docs containers/kubernetes-mcp-server Flux159/mcp-server-kubernetes k8sgpt Lens MCP docs

Radar: Strong: Continuously correlated operational model
containers repo: Native Kubernetes API bridge
Flux159 repo: kubectl and Helm command surface
k8sgpt: Codified analyzer findings plus resource reads
Lens MCP: Read-only bridge through Lens Desktop

Measured diagnosis speed

Median across all 25 faults, followed by the same 16 correctly diagnosed faults. Lens was not part of the run.

Five-arm benchmark

Radar: Strong: 38.0s all · 36.0s shared
containers repo: 64.3s all · 55.8s shared
Flux159 repo: 61.5s all · 57.2s shared
k8sgpt: 119.4s all · 91.0s shared
Lens MCP: Not benchmarked

Context returned

What the agent gets back before it starts reasoning.

Radar MCP docs containers/kubernetes-mcp-server Flux159/mcp-server-kubernetes k8sgpt Lens MCP docs

Radar: Strong: Correlated issues, topology, resources, changes, logs, metrics, Helm, and GitOps
containers repo: Native API objects, events, logs, metrics, Helm, and optional ecosystem toolsets
Flux159 repo: kubectl output, logs, API discovery, Helm, rollouts, port forwards
k8sgpt: Codified analyzers plus resources, events, logs, and cluster health
Lens MCP: Read-only kubectl output plus PromQL through Lens

Control and operations

Safety and writes

Read-only is a server mode; safe writes still depend on Kubernetes RBAC and client approval.

Radar MCP docs containers/kubernetes-mcp-server Flux159/mcp-server-kubernetes k8sgpt Lens MCP docs

Radar: Strong: Read tools plus explicit apply, patch, workload, GitOps, CronJob, and node tools with dry-run/verification support
containers repo: Strict --read-only mode; --disable-destructive is a separate, less restrictive option
Flux159 repo: Partial: Broad writes. Non-destructive mode still allows create, update, scale, rollout, and Helm apply
k8sgpt: Cluster-facing MCP tools read and analyze; filter tools change k8sgpt configuration
Lens MCP: Strictly read-only; no MCP write operations

Installation and runtime

Radar MCP docs containers/kubernetes-mcp-server Flux159/mcp-server-kubernetes k8sgpt Lens MCP docs

Radar: Strong: Single Go binary or in-cluster install; HTTP MCP is on by default
containers repo: Single Go binary, npx, uvx, container, or Helm; no kubectl subprocess
Flux159 repo: npx/Node or Docker; invokes kubectl and Helm operations
k8sgpt: k8sgpt binary or Helm/operator; stdio and HTTP MCP modes
Lens MCP: Lens premium feature; Lens Desktop must stay running

Multi-cluster support

Radar MCP docs containers/kubernetes-mcp-server Flux159/mcp-server-kubernetes k8sgpt Lens MCP docs

Radar: Strong: Radar OSS follows its connected cluster; Radar Cloud exposes an org fleet through one endpoint
containers repo: Strong: Multiple kubeconfig contexts at once; context argument on tools
Flux159 repo: Current kubectl context, with a context-switch tool
k8sgpt: One configured cluster context per process; operator supports remote-cluster patterns separately
Lens MCP: Strong: Connected EKS, AKS, local, and Teamwork clusters

Governance and audit

The layer above kubeconfig and Kubernetes RBAC.

Radar MCP docs containers/kubernetes-mcp-server Flux159/mcp-server-kubernetes k8sgpt Lens MCP docs

Radar: Strong: OSS inherits local identity/RBAC; Cloud adds SSO, org RBAC, server-side credentials, and per-call audit
containers repo: Kubernetes RBAC; current HTTP mode supports OAuth/OIDC and optional OpenTelemetry
Flux159 repo: Kubernetes RBAC; optional OpenTelemetry traces tool calls
k8sgpt: Kubernetes RBAC; no separate MCP gateway policy layer
Lens MCP: Lens account/team controls plus each connected cluster's credentials

Published August 4, 2026 · Last updated August 10, 2026. Product facts verified against the linked primary docs; benchmark data verified August 9, 2026.

Measured, not estimated

Radar submitted the first diagnosis in 38 seconds.

Across all 25 faults, Radar used 38% less time than the next-fastest MCP server and 48% less than kubectl. Restrict the comparison to the same 16 correct faults and Radar still leads at 36.0 seconds.

Explore all 25 faults

Median time to first submitted diagnosis

Bars include all 25 faults. Each line below shows the stricter check on the same 16 faults every arm diagnosed correctly. Lower is faster.

agent start → first submitted diagnosis

01Radarfastest
Correlated cluster model · 8 median calls
38.0s
same 16 correct faults36.0s · 6.2 calls
02Flux159/mcp-server-kubernetes
kubectl/Helm command tools · 14 median calls
61.5s
same 16 correct faults57.2s · 11 calls
03containers/kubernetes-mcp-server
Native Kubernetes API client · 14 median calls
64.3s
same 16 correct faults55.8s · 12.5 calls
04kubectl
Shell and kubectl · 8 median calls
72.4s
same 16 correct faults62.8s · 6 calls
05k8sgpt
Analyzer plus resource reads · 18 median calls
119.4s
same 16 correct faults91.0s · 12 calls

Why Radar's case is broader than speed

Fast is useful. A production boundary is better.

The benchmark measures diagnosis. The product decision also includes what the server sees, what it can change, and who controls it across a fleet.

Investigation work already done

Issues, topology, events, logs, changes, Prometheus, Helm, GitOps, and cluster audit are connected before the agent asks.

Explicit action surface

Writes are named tools with dry-run and verification behavior, still bounded by Kubernetes RBAC and the client's approval policy.

Local OSS, no account

The MCP server starts with the same single Go binary as the UI. Use it locally or in-cluster under Apache 2.0.

Fleet governance when needed

Radar Cloud adds one endpoint across clusters, SSO, org RBAC, server-side connector credentials, and per-call audit.

Adjacent, not equivalent

Three categories that solve a different layer.

They often appear in the same search results. They are useful, but they are not interchangeable with a Kubernetes MCP server for your existing agent.

AI SRE agents

HolmesGPT, Komodor

They consume Kubernetes and other sources into their own investigation loop. Pick them when you want the agent, not just the tool surface.

Observability MCP servers

Grafana, Datadog

Excellent access to telemetry already in those systems. Pair one with a cluster MCP when the live object graph matters.

Generic MCP gateways

Docker, ContextForge, Cloudflare

They centralize routing, credentials, and policy across domains. They do not add Kubernetes diagnosis or cluster semantics themselves.

FAQ

Choosing a Kubernetes MCP server

What is the best Kubernetes MCP server?

Our overall ranking is: 1. Radar MCP, 2. containers/kubernetes-mcp-server, 3. Flux159/mcp-server-kubernetes, 4. k8sgpt, and 5. Lens MCP. Radar ranks first because it combines the fastest measured diagnosis with investigation work completed before the agent asks, explicit write tools, simple local installation, and a path to multi-cluster governance. This overall order is our editorial judgment, not a benchmark score, and we build Radar. The speed result is downloadable; the remaining product claims link to primary sources.

How much faster was Radar in the benchmark?

Across all 25 faults, Radar used 38% less time than the next-fastest MCP server and 48% less than raw kubectl. Its median time to the first submitted diagnosis was 38.0 seconds, against 64.3 for containers/kubernetes-mcp-server, 61.5 for Flux159/mcp-server-kubernetes, 72.4 for raw kubectl, and 119.4 for k8sgpt. Radar also led on the same 16 faults every arm diagnosed correctly. Lens MCP was not tested.

What makes a Kubernetes MCP server safe?

Lens is the simplest strict answer because its MCP server is read-only. containers/kubernetes-mcp-server also has a strict --read-only mode. Radar and Flux159/mcp-server-kubernetes expose writes, so safety depends on Kubernetes RBAC, which tools are enabled, whether the client confirms actions, and the server's dry-run or verification behavior. The latter's non-destructive mode still allows create and update operations, so do not treat that label as a read-only boundary.

Which servers can actually change cluster state?

Radar, containers/kubernetes-mcp-server, and Flux159/mcp-server-kubernetes expose write operations. Radar separates explicit write tools and supports dry-run and post-action verification. containers/kubernetes-mcp-server supports generic CRUD and Helm but can disable writes with --read-only. Flux159/mcp-server-kubernetes has the broadest kubectl-style operational surface of this group. k8sgpt's cluster-facing MCP tools analyze and read; Lens MCP is read-only.

Which options work across multiple clusters?

containers/kubernetes-mcp-server can address multiple kubeconfig contexts directly, and Lens MCP works across clusters connected to Lens Desktop. Radar OSS connects to a cluster like the local UI; Radar Cloud adds one organization endpoint across the fleet with SSO, RBAC, and audit. Flux159/mcp-server-kubernetes can switch the active kubectl context. k8sgpt's MCP process uses its configured cluster context.

Was Radar also the most accurate?

No. Most tools scored highly and the gaps are too small for a confident accuracy ranking. The speed result is clearer: Radar leads across all 25 faults and on the same 16 faults every benchmarked arm diagnosed correctly. The per-scenario explorer exposes every score.

Why aren't AKS-MCP and kubectl-ai ranked?

Azure/aks-mcp is a serious first-party option for teams whose operational boundary is Azure and AKS, but it is cloud-specific rather than a general Kubernetes server. GoogleCloudPlatform/kubectl-ai can expose its tools through MCP, but its center of gravity is an AI assistant and tool-aggregation runtime. This ranking focuses on general Kubernetes server surfaces for an agent you already use, plus Lens as a major existing operator surface. Neither was included in the benchmark.

Why not give an AI agent raw kubectl?

A server can be better when it changes the context, permission boundary, or audit model. Merely wrapping kubectl in MCP does not make the output more useful. Radar's measured speed advantage came from returning a correlated cluster model in fewer calls. A native API server can avoid subprocess overhead and restrict tools. Raw kubectl remains the most flexible option, but it also makes the agent assemble context and inherit whatever shell permissions you grant it.