Radar

Official

Built-in MCP server for the open-source Kubernetes UI — lets AI assistants query and operate your cluster.

Unverified

HTTP (remote)

No auth

View repo 2.4k Website

Add to your client

Copy the config for your MCP client and paste it into its config file.

Install / run

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

Paste into ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "radar": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "http://localhost:9280/mcp"
      ]
    }
  }
}

Claude Desktop connects to remote servers through the `mcp-remote` proxy (installed on first run via npx). Restart Claude Desktop after saving.

Step-by-step guides: Add to Claude Desktop · Add to Cursor · Add to Windsurf

Before you start

A running Radar instance (radar or kubectl radar) — the MCP server is enabled by default on http://localhost:9280/mcp
Access to a Kubernetes cluster via kubeconfig (GKE, EKS, AKS, minikube, kind, k3s, or any conformant cluster)
An MCP-compatible AI client (Claude Code, Claude Desktop, Cursor, Windsurf, VS Code Copilot, Cline, JetBrains AI, OpenAI Codex, or Gemini CLI)

About Radar

Radar bundles an MCP server into its open-source Kubernetes UI. AI assistants connect over HTTP to http://localhost:9280/mcp and get token-optimized, enriched, RBAC-aware access to a live cluster: topology graphs, health assessments, deduplicated events, filtered logs, Helm and GitOps (FluxCD/ArgoCD) state, cluster audit findings, and RBAC introspection. Read tools are read-only; write tools (restart, scale, rollback, sync, apply, cordon/drain) are RBAC-enforced and clearly annotated as destructive. Radar must be running first (radar or kubectl radar); the MCP server is enabled by default and disabled with --no-mcp.

Tools & capabilities (25)

issues

Ranked, curated stream of live operational failures (failing workloads/pods, dangling references, pod-startup blockers, False CRD conditions). Each row carries a source label sliceable via filter.

diagnose

Root-cause one workload or GitOps reconciler in a single call — minified resource + resourceContext + current and previous container logs + filtered events + startupBlockers (workloads), or reconciler status + parsed issues (Application/Kustomization/HelmRelease).

get_dashboard

Cluster/namespace health overview — resource counts, failing pods, unhealthy workloads, warning events, Helm status. Inventory-style triage before drilling in.

top_resources

Live metrics ranked like `kubectl top | sort`, joined with K8s context (status, restarts, owner, requests/limits). For CPU/memory/OOM/load symptoms.

list_resources

List resources of a kind with minified summaries plus per-row summaryContext (managedBy / health / issueCount).

search

Find resources by content/term match (config keys, env refs, images, label values, CRD fields, status messages). Supports kind:/ns:/label:/image: modifiers and CEL filter; secret values never indexed.

get_resource

Detailed view of a single resource — minified spec + status + metadata + default-on resourceContext, with optional supplemental events/metrics.

get_topology

Whole-namespace/cluster topology graph (nodes + edges). Supports a summary format for LLM-friendly text chains.

get_neighborhood

BFS-expanded topology neighborhood around one known root — cheaper and clearer than get_topology for cross-resource failures (routing, selector/endpoint, refs, owner chains). RBAC-filtered.

get_events

Recent Kubernetes Warning events, deduplicated and sorted by recency. Filter by resource kind/name to scope.

get_changes

Recent resource changes (creates, updates, deletes) from the cluster timeline — investigate what changed before an incident.

get_pod_logs

Filtered pod logs prioritizing errors/warnings, with secret redaction. Supports server-side grep filtering.

get_workload_logs

Aggregated, AI-filtered logs from all pods of a workload (Deployment, StatefulSet, DaemonSet).

get_cluster_audit

Static config posture — best-practice findings (Security / Reliability / Efficiency) with remediation. Independent of operational health.

list_packages

Installed packages (Helm releases, label-managed workloads, CRDs, Argo Applications, Flux HelmReleases + Kustomizations) with source provenance, versions, and health, in one call.

list_helm_releases

List all Helm releases with status and health.

get_helm_release

Detailed Helm release info with optional values, history, and manifest diff.

list_namespaces

List all namespaces with status.

get_subject_permissions

Effective RBAC permissions of a ServiceAccount / User / Group: bindings (with inheritedFromGroup), deduplicated flat rule list, and (for SAs) the Pods running as it. Answers over-privilege / blast-radius questions.

apply_resource

Create or update a Kubernetes resource from YAML (write). Supports multi-document YAML, per-document partial-failure results, server-side dry-run preview, and SSA ownership-conflict reporting.

patch_resource

Patch one existing resource with JSON Patch, JSON Merge Patch, or strategic merge patch (write) — precise field/list edits without rewriting the full manifest.

manage_workload

Restart, scale, or rollback a Deployment, StatefulSet, or DaemonSet (write). Scale is not supported for DaemonSets.

manage_cronjob

Trigger, suspend, or resume a CronJob (write).

manage_gitops

Manage ArgoCD and FluxCD resources (write) — sync, refresh, terminate, suspend, resume, rollback (Argo), reconcile / reconcile-with-source (Flux), with lifecycle-aware refusal and per-action input validation.

manage_node

Cordon, uncordon, or drain a Kubernetes node (write).

What this server can do

Radar provides tools for these capabilities — tap one to see every MCP server that does the same:

Manage Git repos Deploy & manage cloud infra

When to use it

Ask an AI assistant "what's broken right now?" and get a ranked stream of live operational failures instead of paging through kubectl output
Root-cause a failing workload or GitOps reconciler in one call with diagnose (resource + logs + events + startup blockers)
Let an AI triage cluster health, topology, and recent changes with token-optimized data that doesn't blow the context window
Audit RBAC blast radius — ask whether a ServiceAccount is over-privileged or what happens if a Pod is compromised
Perform RBAC-enforced, confirmation-gated write operations (restart/scale/rollback, GitOps sync, apply YAML, cordon/drain nodes) through an AI client

Security notes

Read tools are strictly read-only (readOnlyHint); write tools are RBAC-enforced and annotated destructiveHint. Some are genuinely destructive — apply_resource force=true can take field ownership from Helm/Flux, manage_node drain evicts pods, and rollback/terminate overwrite or abort desired state. RBAC-aware: the local binary uses your kubeconfig identity, so MCP can only see what kubectl can see for that user. Secret .data/.stringData are never exposed (key names only); env var values and pod logs are scrubbed for known secret patterns. With in-cluster no-auth deployment every MCP caller shares the pod ServiceAccount's view — only deploy this way behind a trusted boundary.

Radar FAQ

What transport and endpoint does the MCP server use?

HTTP transport with JSON-RPC at http://localhost:9280/mcp. The port matches Radar's --port flag (default 9280). Clients configure it as an http/streamableHttp server pointing at that URL.

Do I need an API key or other auth?

No. For local use there is no auth — the MCP server uses your kubeconfig identity, so it can only see what kubectl can see for that user. Shared in-cluster deployments can add proxy or OIDC auth with per-user Kubernetes RBAC.

How do I connect Claude Code?

With Radar running, run: claude mcp add radar --transport http http://localhost:9280/mcp

Is it safe to give an AI write access?

Read tools are strictly read-only (readOnlyHint). Write tools are RBAC-enforced and annotated destructiveHint so clients can prompt for confirmation. Some are genuinely destructive (apply_resource force=true, manage_node drain, rollback/terminate), so review before approving. Secret data is never exposed and logs/env values are scrubbed for secrets.

Can registries introspect the catalog without a cluster?

Yes. radar --mcp-catalog-only --no-browser starts the /mcp endpoint for schema introspection without Kubernetes, and radar --mcp-catalog-stdio exposes the same tool/resource catalog over stdio. Cluster-backed tool calls still require a normal Radar process connected to Kubernetes.

#kubernetes #k8s #devops #helm #gitops #topology #observability #kubectl

Alternatives to Radar

Compare all alternatives →

GitHub MCP Server

DevOps & Cloud

31k

GitHub's official server for repos, issues, PRs, and Actions — local Docker or hosted remote.

Featured

Verified

stdio (local)

API key

7 tools

Updated 7 days agoRepo

AWS API MCP Server

DevOps & Cloud

9.3k

Official AWS Labs server that lets agents call any AWS API via the AWS CLI surface.

Verified

stdio (local)

API key

Python

3 tools

Updated 9 days agoRepo

kubefwd

DevOps & Cloud

4.1k

Bulk Kubernetes port forwarding with an MCP server that lets AI assistants forward services, inspect pods, and monitor traffic.

Unverified

stdio (local)

No auth

28 tools

Updated 1 day agoRepo

Compare Radar with:

vs GitHub MCP Server vs AWS API MCP Server vs kubefwd vs Grafana MCP Server