Radar OSS · MCP server

Give Claude, Cursor, and Copilot 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.

Not a dumb pipe for kubectl. Radar ships a built-in Kubernetes MCP server whose tools hand AI agents a pre-built topology, problem-correlated timelines, deduplicated events, and error-filtered logs - already minified, with secrets redacted. 23 read tools, 7 scoped write tools. Local-only by default, RBAC-aware, enabled on first install.

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 focused calls. No YAML dumps to wade through.

Benchmark

The right diagnosis, nearly four times sooner.

Same model, same 54 SREGym faults - once through Radar, once through raw kubectl. Radar reached a correct diagnosis in a median 41 seconds versus 154 on the 44 faults both solved. Replay every run side by side.

3.8x

Faster median diagnosis

41s through Radar vs 154s through kubectl

43 of 44

Shared faults answered sooner

Radar was faster on all but one

91%

Correct by 5 minutes

Radar was done; kubectl: 56% then, 87% overall

Time blocked on the cluster

73% through kubectl

Why the gap? Radar does the investigation before the agent asks - connecting topology, problem-correlated timelines, deduplicated events, and error-filtered logs - instead of making the agent reconstruct the cluster from raw kubectl get -o yaml dumps, call after call.

Run it against your own cluster -

install + runbash

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

Replay Radar vs kubectl Compare Kubernetes MCP servers

Read the benchmark methodology and analysis

The problem

Raw kubectl is a bad MCP tool.

Two problems kill the naive “let Claude run kubectl” setup.

Context waste. kubectl get pod -o yaml returns hundreds of lines of managedFields, status conditions, and metadata noise. The model spends its context parsing Kubernetes bookkeeping instead of diagnosing the incident.

Write-access risk. Giving an agent shell access to your cluster means a wrong inference can run any command that identity can run, including destructive operations. You need write capabilities that are explicit, scoped, annotated, and easy for the client to confirm before execution.

Radar's MCP server fixes both. Reads are minified and enriched with Radar's already-computed topology and health. Writes are confined to seven explicit tools, RBAC-enforced, and annotated as mutating or destructive where appropriate so the AI client can prompt before changing state. No delete tool, no arbitrary shell.

The tool surface

23 read tools. 7 write tools.

Each tool does work a raw kubectl wrapper can't - composing related calls into one, correlating timelines with problems, collapsing duplicate events, redacting secrets, and emitting minified output sized for a model's context window.

Read tools23 · read tools

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 tools7 · annotated writes

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.

Note: `scale` is not supported for DaemonSets. Writes are explicit, RBAC-enforced, and annotated as mutating or destructive where appropriate. No delete tool, no arbitrary shell.

cluster:// resourcesMCP resource URIs

cluster://health

Cluster health summary (same data as get_dashboard).

cluster://topology

Full cluster topology graph.

cluster://events

Recent warning events (up to 50).

Wire it up

One command or one paste.

With Radar running locally, choose your client, copy the config, and start asking about your cluster.

Run in your terminal

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

Also supported: Windsurf, JetBrains, Codex, Gemini CLI. See the full MCP docs for all 9 clients.

What you can ask

Real questions, the tools they'll resolve to.

“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

Safe by design

The guardrails aren't optional.

Local-only

The MCP server runs on localhost alongside Radar - bound to 127.0.0.1, not your public interface. AI clients connect to your machine, not the cluster's control plane.

RBAC-aware

Respects your kubeconfig's RBAC permissions. If your ServiceAccount can't list secrets in the payments namespace, neither can the MCP-backed agent. Returns 403 for unauthorized resources.

Three layers of redaction

Secret data never exposed - only key names. Env var values scrubbed for API keys, tokens, and base64 blobs. Pod log output scrubbed for secret patterns before returning.

Read-first tool surface

Diagnosis is read-only by default. Optional in-cluster route probing uses short-lived, self-deleting probe pods. Write operations are RBAC-enforced and flagged for client confirmation.

Explicit, annotated write tools

Write tools can restart, scale, patch/apply, sync, cordon, or drain. They are RBAC-enforced and marked mutating or destructive where appropriate so the client can prompt before execution. No delete tool, no arbitrary shell.

Disable with one flag

Pass `--no-mcp` when starting Radar to turn the server off entirely. On by default, off when you need it off - no stale config surface area.

For teams · Radar Cloud

One MCP endpoint for the whole org.

Local MCP is per-laptop and great for one engineer. When agents need to reach shared and production clusters across a team, Radar Cloud turns the same tools into a governed, audited endpoint. AI access to your clusters becomes something you can actually sign off on.

Set up once, for everyone

Install the Radar agent in each cluster one time. Your whole team's agents - Claude, Cursor, Copilot - reach every cluster through a single endpoint. No kubeconfigs to copy around, no per-cluster local Radar process to keep in sync.

RBAC you can trust

Agents act with the signed-in operator's identity through your SSO, enforced by Kubernetes RBAC. A viewer's agent can read but never mutate. The cluster itself governs access, so the same rules apply whether a human or an agent makes the call.

Audited tool activity

Tool-call activity is audited - who ran which tool, which cluster it targeted, and whether it succeeded, was blocked, or failed. High-volume successful loops are coalesced with counts; blocked and failed calls are preserved.

Read-only that keeps diagnosis

Set the org to read-only and mutating tools disappear, but diagnose stays with an allowlisted, non-mutating schema. Live in-cluster probes and unclassified arguments are also refused at call time.

Compare open source and Cloud

Open source

Apache 2.0. Yours to inspect, fork, or run in your own cluster.

Radar's source is on GitHub. Every feature on this page is in the binary you install with brew install. No telemetry, no mandatory login, no cluster data out. Outbound traffic is limited to anonymous version checks when the UI opens. If we ever change that, you'll see it in a diff first.

skyhook-io/radar

3.2k★ GitHub stars

Apache 2.0 · Actively maintained

FAQ

Questions we get about MCP.

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?

Claude Code, Claude Desktop, Cursor, VS Code Copilot, and Cline out of the box with copy-paste config. Windsurf, JetBrains, Codex, and Gemini CLI are also supported - 9 clients total, documented in the full MCP docs.

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

In Radar's own 54-scenario benchmark on a live EKS cluster, yes. Same model both sides: a 91% pass rate against 87% for raw kubectl, and it got there roughly four times faster - a median 41 seconds to a correct diagnosis against 154, measured across the 44 faults both arms got right. Cap the agent at five minutes, which is what a real incident allows, and it is 91% against 56%.

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

Point an agent at a real cluster. Safely.

Install Radar, paste a config block, and Claude can reason about your cluster in under a minute.

Install with Helm Try hosted Let's Talk

Apache 2.0 OSS · Unlimited clusters with Radar OSS · Hosted free tier for up to 3 clusters