Radar OSS · MCP server

Give Claude Code, Codex, and Cursor a safe Kubernetes MCP server.

Q: Can I turn it off?

Yes. MCP is enabled by default on first install; pass --no-mcp when starting Radar to disable the server entirely.

Radar's built-in MCP server answers with the cluster already joined: topology, what changed and when, deduplicated events and error-filtered logs, with secrets redacted. 23 read tools and 7 scoped write tools. Local, RBAC-aware, on by default.

Install OSS Read the MCP docs

Apache 2.0 · Enabled by default · Disable with --no-mcp

claude · connected to radar · mcp/http

You

why is the payments pod in crashloop

Claude · calling radar tools

→ get_resource(kind=“Pod”, name=“payments-7d9f”)

→ get_events(namespace=“prod”, since=“1h”)

→ get_pod_logs(name=“payments-7d9f”, level=“error”)

Response

The pod payments-7d9f is in CrashLoopBackOff. The kubelet reported OOMKilled at 14:01:47 - the container exceeded its 512Mi limit. A ConfigMap change 90 seconds earlier set cache.preload_on_startup: true, which matches the timing. Revert the ConfigMap or raise the memory limit.

3 tool calls, each returning a focused summary rather than raw YAML.

Benchmark

Same agent, same model: 3× faster with Radar's MCP

Same model, same 50 SREGym faults - once through Radar, once through raw kubectl. Radar was slightly more accurate and got there in an average 64 seconds against 191. Replay every run side by side.

Faster on average

64s through Radar vs 191s through kubectl

37 of 44

Shared faults answered sooner

counting faults both arms got right

90%

Correct by 5 minutes

kubectl: 78% by then

13%

Time blocked on the cluster

42% through kubectl

Against finished AI SRE products it holds up too: on 50 live faults, Claude Code on Radar's MCP was the most accurate of the 6 products we tested: clearly ahead of HolmesGPT, OpenSRE, kagent and AWS DevOps Agent, and slightly ahead of kubectl-ai. It answered in an average 79 seconds at $0.27 a fault, the fastest and cheapest of the 6. See the AI SRE benchmark.

Replay Radar vs kubectl Compare Kubernetes MCP servers

Raw kubectl isn't built for agents

Compact output that fits the agent's context

kubectl get pod -o yaml returns hundreds of lines of managedFields, status and metadata. The agent reads it all, then makes the next call to find the relationship it needed. Radar returns minified objects with the topology, health and recent changes already attached.

A shell can run anything its identity can

Radar's writes are seven explicit tools, enforced by Kubernetes RBAC and annotated as mutating or destructive, so the client can ask before anything changes. There is no delete tool and no arbitrary shell.

23 read tools, 7 write tools

Tools combine what would be several kubectl calls, correlate problems with recent changes, collapse duplicate events, redact secrets and return minified output.

Read

get_dashboard

Cluster health overview - resource counts, problems, warning events, Helm status. Auto-correlates the recent changes that touched any broken resource.

list_resources

Lists resources with minified summaries (pods, deployments, services, CRDs, etc.).

get_resource

Detailed view of a single resource, with optional events + relationships + metrics + logs in one call - one tool instead of four.

get_topology

Pre-built topology graph (nodes + edges) or an LLM-friendly text summary of resource chains and problems.

get_events

Kubernetes events, deduplicated (same reason+message collapsed) and sorted by recency.

get_changes

Resource changes (creates, updates, deletes) from the cluster timeline, with computed diffs.

get_cluster_audit

Best-practice findings with remediation - security, reliability, efficiency. Filter by namespace, category, severity.

get_cluster_upgrade_readiness

Evidence-backed upgrade impact analysis for a target Kubernetes minor, including deprecated APIs, version skew, node runtime, drain feasibility, and webhook readiness.

get_pod_logs

Pod logs filtered to errors/warnings, with secret redaction. Falls back to the last 20 lines if nothing matches.

get_workload_logs

Logs from every pod of a workload, deduplicated and error-prioritized across replicas.

list_namespaces

List all namespaces with status.

list_helm_releases

List all Helm releases with status and health.

get_helm_release

Helm release info with optional values, revision history, and manifest diff across revisions.

list_packages

What's installed in the cluster - one call instead of cross-referencing Helm + workload labels + CRDs + ArgoCD + Flux. Each row carries a sources array (H/L/C/A/F) so you can see WHY it was detected, plus per-source health and version. Catches operator orphans and same-cluster version disagreement.

issues

Ranked stream of what's broken right now - failing workloads, pod-startup blockers, dangling references - across the whole cluster.

diagnose

Root-cause one workload or GitOps reconciler in a single call, with the causal chain assembled for you.

get_neighborhood

BFS-expanded topology around one resource - cheaper than the full graph when you already know the root.

get_subject_permissions

Effective RBAC for a ServiceAccount, User, or Group - what they can actually do, and via which bindings.

search

Find resources by content - config keys, env refs, image names, labels - without knowing the kind up front.

top_resources

Live CPU/memory ranked like `kubectl top | sort`, joined with workload context.

query_prometheus

Run PromQL against the cluster's Prometheus, auto-discovered or configured.

discover_metrics

Find exact metric names, enriched with type and help text from Prometheus metadata.

get_prometheus_rules

List Prometheus alerting and recording rules with their PromQL and current state.

Write

apply_resource

Create or update a Kubernetes resource from YAML.

manage_workload

Restart, scale, or rollback a Deployment, StatefulSet, DaemonSet, or Argo Rollout.

manage_rollout

Abort, retry, promote, fully promote, or advance one step of an Argo Rollout.

manage_cronjob

Trigger, suspend, or resume a CronJob.

manage_gitops

Manage ArgoCD and FluxCD resources - sync, reconcile, suspend, resume.

manage_node

Cordon, uncordon, or drain a Kubernetes node.

patch_resource

Patch one existing resource with a JSON Patch, merge patch, or strategic merge - precise field edits without rewriting the manifest.

RBAC-enforced and annotated as mutating or destructive. No delete tool, no arbitrary shell.

Connect an agent

With Radar running, Claude Code needs one command:

claude mcp add radar --transport http http://localhost:9280/mcp

Codex, Cursor, GitHub Copilot, OpenCode, Google Antigravity, Kiro, JetBrains, Cline, Devin Desktop and any other MCP client connect to the same URL: setup for each client.

Examples

Questions and the tools they call

“What's wrong with my cluster right now?”

get_dashboard

Resource counts, problems by kind, recent warnings, Helm release health

“Why is the payments pod failing?”

get_pod_logs + get_events + get_resource

Scrubbed logs filtered to errors/warnings, recent events for the Pod, full resource detail with related context

“What changed in the last hour that could explain this?”

get_changes

All creates, updates, and deletes from the cluster timeline within the window

“Diff my last two Helm revisions for the api chart.”

get_helm_release (with include=diff)

Values diff, manifest diff, and history for the release

“Show me the network topology around the ingress namespace.”

get_topology

LLM-friendly structured graph of nodes, edges, and ownership for the requested scope

Security model

Local only: Bound to 127.0.0.1 next to Radar. Agents connect to Radar on your machine; the API server is never exposed.
Your RBAC: Every call runs as your kubeconfig identity. What it can't read, the agent can't read.
Secrets redacted: Secret values, secret-looking env values and matching log lines are scrubbed before the agent sees them.
Writes are explicit: Seven write tools, annotated so the client can confirm first. No delete, no shell.
Read-only diagnosis: Diagnosis never writes. Optional route probes use short-lived pods that delete themselves.
Off with one flag: Start Radar with --no-mcp to disable the server.

Radar Cloud: one MCP endpoint for every cluster

The local server covers one engineer's kubeconfig. Radar Cloud serves the same tools to the whole team from one endpoint.

One endpoint, every cluster: Install the Radar agent in each cluster once. Every agent on the team reaches all of them through a single URL, with no kubeconfigs to hand out.
SSO identity, Kubernetes RBAC: Agents act as the signed-in user. A viewer's agent can read but can't change anything.
Audited tool calls: Who ran which tool, on which cluster, and whether it succeeded, was blocked or failed.
Org-wide read-only: Switch the org to read-only and write tools disappear, while diagnosis keeps working.

Compare open source and Cloud

FAQ

MCP server questions

Is Radar's MCP server safe to point at a production cluster?

With the right setup, yes - and the limits are worth knowing. It's local-only by default (bound to 127.0.0.1), every call goes through your kubeconfig's RBAC, and secrets are redacted at three layers (secret data, env var values, log output). But RBAC is the real boundary: the agent can do exactly what the identity you hand it can do, so give it a least-privilege kubeconfig. The seven write tools are annotated as mutating or destructive so clients can prompt first - a client that ignores annotations is constrained only by RBAC.

Which AI clients does it support?

Any client that speaks MCP over HTTP. The docs have setup for Claude Code, Codex, Cursor, GitHub Copilot (VS Code and CLI), OpenCode, Google Antigravity, Kiro, JetBrains AI Assistant and Junie, Cline, Devin Desktop (formerly Windsurf), Claude Desktop, Zed and Gemini CLI.

Is it actually better than letting an agent run kubectl directly?

Yes: much faster and slightly more accurate. In Radar's own 50-fault benchmark on a live EKS cluster, with the same model on both sides, the agent averaged 64 seconds to a diagnosis through Radar against 191 through raw kubectl - 3x - and scored a mean 0.936 against 0.905 on the judge's rubric. The gap comes from time spent blocked on the cluster: 42% of the incident with a shell, 13% through Radar. Cap the agent at five minutes, which is what a real incident allows, and it is 90% correct against 78%.

Can I turn it off?

Yes. MCP is enabled by default on first install; pass --no-mcp when starting Radar to disable the server entirely.

How does this work for a whole team instead of one laptop?

Local MCP is per-laptop. Radar Cloud turns the same tools into one governed, SSO-authenticated endpoint for the whole org - agents act with the signed-in operator's identity through Kubernetes RBAC, and tool-call activity is audited (who ran what, on which cluster, blocked or succeeded).

More of the Radar surface

More of what Radar does in the same binary.

All features

Connect your agent to Radar's MCP server.

It ships in the open source binary and is on by default.

Quick install

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

Other install methods (Krew, Scoop, .rpm, direct download) →

or try Radar Cloud free →Star on GitHub →

Apache 2.0 · No account for local use · Run Radar OSS forever