Radar OSS · MCP server

Give Claude, Cursor, and Copilot a safe Kubernetes MCP server.

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. 22 read tools, 6 scoped write tools. Local-only by default, RBAC-aware, enabled on first install.

Install OSSRead 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 tools, ~1,800 tokens. Raw kubectl for the same answer: ~12k - measured in the benchmark below.
Benchmark

More accurate. A fraction of the cost.

We ran the same 52-scenario Kubernetes benchmark with the same model - once driving Radar's MCP server, once driving raw kubectl through a shell. Radar reached a better diagnosis with 4x fewer tool calls, a much smaller token bill, and half the time.

Diagnostic accuracy: ahead

Radar MCP scored 0.862 avg diagnostic quality vs 0.765 for kubectl, and passed 80.8% of scenarios vs 77.6%. More accurate - and it gets there with far less work.

-76%
Tool calls per trial

11.1 vs 45.8 - roughly 4x fewer round-trips

-53%
Input tokens per trial

Minified, enriched data instead of raw YAML floods

-66%
Output tokens per trial

Less context to reason over, less to write back

-49%
Time to diagnosis

169s vs 334s average agent time

Why the gap? Radar hands the model an already-computed picture - pre-built topology, problem-correlated timelines, deduplicated events, error-filtered logs - instead of making the agent reconstruct it 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
Read the full benchmark
The problem

Raw kubectl is a bad MCP tool.

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

Token waste. kubectl get pod -o yaml returns hundreds of lines of managedFields, status conditions, and metadata noise. Three of those and you've burned the model's context window on data you didn't need.

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 six 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

22 read tools. 6 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 tools22 · read-only
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_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 tools6 · annotated writes
apply_resource

Create or update a Kubernetes resource from YAML.

manage_workload

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

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

Five MCP clients. Five copy-paste blocks. All verbatim.

Install Radar. Paste one of these into your MCP client's config. That's it.

Claude CodeOne-liner CLI
bash
claude mcp add radar --transport http http://localhost:9280/mcp
Claude Desktop
json
{
  "mcpServers": {
    "radar": {
      "type": "http",
      "url": "http://localhost:9280/mcp"
    }
  }
}
Cursor
json
{
  "mcpServers": {
    "radar": {
      "url": "http://localhost:9280/mcp"
    }
  }
}
VS Code Copilot
json
{
  "servers": {
    "radar": {
      "type": "http",
      "url": "http://localhost:9280/mcp"
    }
  }
}
Cline
json
{
  "mcpServers": {
    "radar": {
      "url": "http://localhost:9280/mcp",
      "type": "streamableHttp"
    }
  }
}

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 tools are strictly read

The read tools have no write path. No privilege-upgrade path from a read to a write. The tool hints annotate write tools so the AI client UI can prompt before executing them.

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.

Compare open source and Cloud
Open source

Apache 2.0. Yours to inspect, fork, or self-host.

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. The one outbound call is an anonymous version check when the UI opens. If we ever change that, you'll see it in a diff first.

skyhook-io/radar
2.6k★ 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 six 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 52-scenario benchmark, yes: 0.862 average diagnostic quality vs 0.765 for raw kubectl, an 80.8% vs 77.6% pass rate, and it got there with 76% fewer tool calls, 53% fewer input tokens, and 49% less time.
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.

Issues & root cause

Failures grouped by subject, folded to the cause, with blast radius.

Applications view

Workloads folded into the apps they form, with health rollups and env skew.

GitOps for Argo + Flux

Fleet + per-app diagnosis with field-level drift, controller attribution, and lifecycle awareness.

Live topology graph

Every resource and connection, laid out by ELK.js, updated via SSE.

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 HelmTry hostedLet's Talk

Apache 2.0 OSS · Unlimited clusters self-hosted · Hosted free tier for up to 3 clusters