Skip to main content
Radar includes a built-in Model Context Protocol (MCP) server that lets AI assistants query your Kubernetes cluster. For the design rationale and what the tools return, see the MCP deep dive. Looking for the built-in AI investigations instead - where Radar drives your agent CLI against a failing resource for you? That’s Diagnose.

Why MCP instead of raw kubectl?

Giving an AI assistant raw kubectl access has problems:
  • Token waste - kubectl get pod -o yaml returns verbose YAML full of managed fields, status conditions, and metadata noise that burns through LLM context windows
  • No enrichment - raw output lacks topology relationships, health assessments, or cross-resource correlation
  • Write access risk - kubectl can modify and delete resources
Radar’s MCP server solves these:
  • Token-optimized - resources are minified, stripping noise (managed fields, internal annotations, redundant status) while preserving what matters
  • Enriched data - topology graphs, health assessments, deduplicated events, filtered logs (prioritizing errors/warnings)
  • Safe operations - read tools are read-only (readOnlyHint); write tools (restart, scale, rollback, sync, apply, cordon/drain) are RBAC-enforced and annotated destructiveHint so AI clients can prompt for confirmation
  • Secret-safe - Secret data is never exposed, environment values are redacted, log output is scrubbed for API keys and tokens
  • RBAC-aware - respects your cluster’s RBAC permissions
  • Vendor-neutral - works with any MCP-compatible AI tool

Enabling / Disabling

The MCP server is enabled by default when Radar starts. To disable it:

MCP Endpoint

The port matches your --port flag (default 9280). The MCP server uses HTTP transport with JSON-RPC.

Catalog Introspection

MCP registries and inspectors can start Radar without a Kubernetes cluster when they only need the tool and resource catalog:
This mode skips Kubernetes initialization and starts the /mcp endpoint for schema introspection. Cluster-backed tool calls still require a normal Radar process connected to Kubernetes. For registries that launch MCP servers over stdio, use:
This exposes the same tool and resource catalog over stdio without starting the HTTP UI server. The stdio mode is intended only for catalog introspection; normal Radar sessions use the HTTP endpoint above.

Setup Instructions

Connect your AI tool to Radar’s MCP server. Radar must be running first (radar or kubectl radar).

Claude Code

Run this command:

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

Cursor

Add to ~/.cursor/mcp.json:

Windsurf

Add to ~/.codeium/windsurf/mcp_config.json:

VS Code Copilot

Add to .vscode/mcp.json in your workspace:

Cline

Add via the Cline MCP settings UI:

JetBrains AI

Add via Settings > Tools > AI Assistant > MCP:

OpenAI Codex

Add to ~/.codex/config.toml:

Gemini CLI

Add to ~/.gemini/settings.json:

Available Tools

Read Tools

Write Tools

Available Resources

Security

  • Safe by design - read tools are strictly read-only and annotated with readOnlyHint; write tools (restart, scale, rollback, sync, apply, cordon/drain) are RBAC-enforced and annotated with destructiveHint so AI clients can prompt for confirmation. 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 - every call enforces RBAC at the same boundary as the REST API:
    • Local binary: the cache uses your kubeconfig identity, so MCP can only see what kubectl can see for that user
    • In-cluster (auth enabled): read tools intersect namespaced reads with the calling user’s RBAC-allowed namespaces; cluster-scoped reads (Nodes, PVs, ClusterRoles, cluster-scoped CRDs) are gated per-kind via SubjectAccessReview, so cluster-wide pod visibility doesn’t implicitly grant Node read; write tools, exec, and logs are fully impersonated so the apiserver enforces the user’s RBAC end-to-end
    • In-cluster (no auth): every MCP caller shares the pod ServiceAccount’s view - only deploy this way when MCP isn’t exposed beyond a trusted boundary
  • Prometheus metric data is NOT namespace-filtered - PromQL cannot be namespace-scoped server-side (arbitrary queries can aggregate across namespaces), so query_prometheus and discover_metrics follow the same stance as the REST /prometheus/query endpoint: any authenticated user may run PromQL. Deploy with auth enabled when Prometheus contains sensitive label values
  • Secret redaction - Secret .data and .stringData are never exposed; only key names are shown
  • Value redaction - environment variable values and Helm values returned through MCP are scrubbed for known secret patterns; Helm values also use key-aware redaction for names like password, token, privateKey, and secretKey
  • Log redaction - pod log output and Helm hook log evidence are scrubbed for secret patterns before being returned