Radar MCP vs kubectl: A Kubernetes Agent Benchmark on 52 Faults

I wanted to know one thing: when an AI agent debugs a broken Kubernetes cluster, does it matter what tools we hand it?

Most vendors hand-wave this - "our MCP makes your agent smarter." That is not the bar. If you're giving Claude, Cursor, or an in-house agent access to Kubernetes, the tool surface has to beat raw kubectl on accuracy, cost, and safety. I didn't want to ship a claim I couldn't defend, so I ran the same 52-scenario Kubernetes benchmark with the same model on two tool surfaces. One arm drove raw kubectl through a shell. The other drove Radar's Kubernetes MCP server.

Radar won - and not only the way I expected. The agent landed a better diagnosis, and it got there doing a fraction of the work.

TL;DR

On 52 real Kubernetes fault-injection scenarios, an agent driving Radar's Kubernetes MCP server was more accurate than the same agent on raw kubectl (80.8% vs 77.6% pass rate, 0.862 vs 0.765 avg score) while using ~76% fewer tool calls, ~53% fewer input tokens, ~66% fewer output tokens, and about half the time. The story isn't that MCP makes the agent smarter - it's that a structured visibility layer is far cheaper to reason over than raw YAML, while landing a better answer. It's the same reason humans don't debug clusters by reading kubectl get -o yaml all day.

What I tested

The setup was deliberately simple: same benchmark suite, same model, same goal, two tool surfaces.

• Scenarios: SREGym - 52 real fault-injection scenarios on a live cluster. Bad DNS policies, wrong selectors, missing env vars, broken probes, auth disruptions, CPU floods, slow image pulls. Real faults, not puzzles.
• Cluster: EKS, 3x m5.xlarge, us-east-1.
• Model: claude-sonnet-4-6 on both arms.
• Tool surfaces: Arm A got raw kubectl via Bash. Arm B got Radar's MCP.

Each trial ends with the agent producing a diagnosis, scored against the known injected fault. I tracked whether it got the right answer - and how much it spent getting there.

The numbers

The top two rows are the diagnostic result: Radar landed the better answer. The bottom four rows are the operational result: the MCP arm got there with a quarter of the tool calls, a much smaller context bill, and half the wall-clock time. If you're paying per token or waiting on an AI-assisted Kubernetes debugging workflow mid-incident, that is the part that matters.

Why a Kubernetes MCP server beats raw kubectl

This is the part that explains the numbers instead of just reporting them.

Radar's MCP is not a kubectl wrapper - that distinction is the whole mechanism. Give an agent raw kubectl and a single kubectl get pod -o yaml hands back hundreds of lines: managedFields, full status blocks, annotations, the entire object as the API server stores it. The one useful signal - an OOMKilled condition, a failing readiness probe - is buried in the wall of text. And the agent re-reads its accumulated context every turn, so by call 30 it's dragging a huge transcript of YAML it already parsed. That's the giant input-token count in the kubectl column: the same noise re-ingested turn after turn.

To trace a cross-cutting fault - "this Service can't reach its pods" - a kubectl agent has to reconstruct the graph by hand: list the Service, read its selector, list pods, check labels, read endpoints, check the network policy, pull events, cross-reference timestamps. That's where ~46 tool calls come from.

Radar hands over the already-computed answer instead. The MCP returns minified, enriched, secret-redacted data: pre-built topology graphs, problem-correlated timelines, deduplicated events, error-filtered logs. The agent calls get_topology once and gets the ownership and routing chain as a structured object; it calls the issues API and gets the causal chain - what broke, what it's connected to, what changed - instead of the raw materials to derive it. Four times fewer calls, because each call answers a bigger question, and half the context, because what comes back is signal.

This is exactly the argument Roy made in "Agents, UIs, and CLIs: The False Choice in Kubernetes Operations" - a cluster is a live graph, and raw YAML is a poor way for anything to make sense of it, human or LLM. This benchmark is that argument with a number attached.

Where Radar pulls ahead

The averages hide a pattern. Radar's biggest wins are the faults where the symptom is far from the cause - a wrong DNS policy, a service that can't resolve, a misconfigured selector, a missing env var, a dependency failing three hops away. Radar's issues API, topology, and change feed hand the agent the causal chain already assembled; the kubectl agent has to trace it across dozens of calls, and often runs out of budget and guesses. Those indirect, cross-cutting faults are most of what real incident response actually is.

Raw kubectl happened to edge ahead on a few needle-in-one-log faults. I would not over-read that as a durable advantage. Those are high-variance cases where success can come down to whether the agent opens the one right log line early. Radar also does not have to be the only tool in the agent's toolbox: if you expose shell or kubectl alongside Radar, the agent can still run any plain kubectl command when that is the right move. The difference is that it no longer has to reconstruct the cluster from raw YAML by default.

You don't want an agent loose on raw kubectl

Speed and accuracy aside, raw kubectl through a shell is the ungoverned option. The agent inherits whatever that shell can do, every call is a potential mutation, and you get no record of what it touched.

Radar's MCP is the opposite by design: read tools are read-only and secret-redacted, writes are RBAC-enforced and gated so the client can prompt before anything changes, and Radar Cloud adds the governance layer on top - an inventory of every agent and token with cluster access, the same Kubernetes impersonation a human gets, and audited tool activity for agent actions.

"Cheaper and more accurate" is the benchmark result. "And you can actually let it near production" is why teams route the agent through Radar in the first place.

Why this is the argument for an agent surface

Step back and the result isn't really about AI - it's about data shape. Agents reason over Kubernetes far more cheaply, and a little more accurately, when the data is structured for them. It's the same reason we build dashboards instead of reading raw YAML: eyes need the graph rendered, and it turns out agents need the same graph modeled.

So Radar is one engine that watches your clusters, with two surfaces over it. Humans consume it as a UI - still the surface most of our users live in. Agents consume it as MCP. Both need the same thing: the cluster made sense of, not just dumped. This benchmark was about the second surface, but the human-first one is still the point - we build Radar for the person staring at a cluster at 2am, and increasingly some of that work is done by an agent on their behalf.

Run a Kubernetes MCP server against your own cluster

Don't take my word for it. Radar is open source and the MCP server is on by default, so you can point your own agent at it and break something on purpose to see how it reasons.

curl -fsSL https://get.radarhq.io | sh && kubectl radar

That gets you the UI and the MCP server in one go. Aim your agent at the MCP endpoint and watch it work a fault on a cluster you trust.