Kubernetes MCP server

Radar includes a built-in Model Context Protocol (MCP) server that lets AI agents inspect, investigate, and operate 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 agent 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 - write tools such as restart, scale, apply, and rollback are identified for client confirmation and enforced through Kubernetes RBAC. Diagnosis is read-only by default; optional in-cluster route probing uses short-lived, self-deleting probe pods
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:

radar --no-mcp

MCP Endpoint

http://localhost:9280/mcp

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:

radar --mcp-catalog-only --no-browser

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:

radar --mcp-catalog-stdio

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 mcp add radar --transport http http://localhost:9280/mcp

Claude Desktop

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

{
  "mcpServers": {
    "radar": {
      "type": "http",
      "url": "http://localhost:9280/mcp"
    }
  }
}

Cursor

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "radar": {
      "url": "http://localhost:9280/mcp"
    }
  }
}

Windsurf

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

{
  "mcpServers": {
    "radar": {
      "serverUrl": "http://localhost:9280/mcp"
    }
  }
}

VS Code Copilot

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

{
  "servers": {
    "radar": {
      "type": "http",
      "url": "http://localhost:9280/mcp"
    }
  }
}

Cline

Add via the Cline MCP settings UI:

{
  "mcpServers": {
    "radar": {
      "url": "http://localhost:9280/mcp",
      "type": "streamableHttp"
    }
  }
}

JetBrains AI

Add via Settings > Tools > AI Assistant > MCP:

{
  "mcpServers": {
    "radar": {
      "url": "http://localhost:9280/mcp"
    }
  }
}

OpenAI Codex

Add to ~/.codex/config.toml:

[mcp_servers.radar]
url = "http://localhost:9280/mcp"

Gemini CLI

Add to ~/.gemini/settings.json:

{
  "mcpServers": {
    "radar": {
      "httpUrl": "http://localhost:9280/mcp"
    }
  }
}

MCP Registry / Docker

Radar is listed on the official MCP registry as io.github.skyhook-io/radar, packaged as the ghcr.io/skyhook-io/radar Docker image. The registry-suggested invocation is:

docker run -p 127.0.0.1:9280:9280 \
  -v ~/.kube/config:/kubeconfig:ro \
  -e KUBECONFIG=/kubeconfig \
  ghcr.io/skyhook-io/radar:latest

Prefer the native install (brew install skyhook-io/tap/radar, krew, or the install script - see the README) - it uses your kubeconfig exactly as kubectl does. The Docker path has real limitations because the image is distroless (no shell, no cloud CLIs):

Exec-plugin auth does not work. Kubeconfigs for GKE/EKS/AKS typically call gke-gcloud-auth-plugin, aws eks get-token, or kubelogin - none exist inside the container. Only kubeconfigs with embedded certificates or static tokens work.
Local clusters are unreachable. kind/minikube/Docker Desktop API servers listen on the host’s 127.0.0.1, which inside the container is the container itself.
File ownership matters. On Linux hosts a 0600 kubeconfig owned by your user is unreadable by the container’s nonroot (uid 65532) user.

The Docker image’s primary use is in-cluster deployment with a ServiceAccount, where none of these apply.

Diagnose evidence limits

For workload diagnose responses, logCoverage.selectedPods counts pods selected for log requests, not pods whose logs were successfully read. Per-container errors and logsError describe failed collection. logCoverage.totalLines counts diagnostic-filter output before the aggregate response cap (including fallback tail lines); shownLines counts the lines retained after that cap. Neither describes a container’s complete log history. totalPods and shownPods count pods contributing at least one line before and after that cap - not all selected pods or successful empty reads. eventsTotalGroups, recent-change coverage/error fields, and log sampling/truncation must remain qualifications even when an agent reports no problem. expectedPreviousLogAbsences requires container status consistent with no previous instance and either an empty successful read or the specific previous-instance-not-found response. Permission failures, missing pods, unavailable servers, and interrupted reads remain collection errors. One call combines cached Kubernetes resource state, historical events/changes, and live log requests. Its completion time records when the call finished, not a shared observation time or freshness guarantee for those sources. Event/change timestamps retain their source-specific meaning. These public MCP fields are available to consumers running the updated Radar server. The OSS local AI investigation additionally uses its own evidence ledger, citations, and Findings integration. Hosted/Cloud consumers need corresponding backend provenance and investigation integration; upgrading a frontend package alone does not establish parity.

Available Tools

Read Tools

For interpreting workload bundles, see Diagnose evidence limits, including collection failures, sampling, source timestamps, and the public MCP versus local investigation boundary.

Tool	Description	Parameters
`issues`	”What’s broken right now?” - a ranked, curated stream of live operational failures: failing workloads/pods, active native Helm release failures or stuck pending operations (`kind=HelmRelease`, `group=helm.sh`), dangling references, pod-startup blockers (unschedulable / admission-rejected / stuck post-bind), and False CRD conditions. No source filter; each row carries a `source` label sliceable via `filter`. Recovered Helm rollbacks are deploy history, not live issues; use `get_changes` for Helm deployment history and `get_helm_release` for native Helm full revision/history/hook diagnostics. Flux `HelmRelease` rows (`group=helm.toolkit.fluxcd.io`) are GitOps reconcilers and should use `diagnose`. For static posture use `get_cluster_audit`; for raw events use `get_events`.	`namespace` (optional), `severity` (optional: `critical,warning`), `kind` (optional), `filter` (optional CEL), `limit` (optional, default 200, max 1000)
`diagnose`	Collect a bounded, point-in-time evidence bundle for one narrowed workload, GitOps reconciler, or network entry kind in a single call. It supports diagnosis but does not run an agent, provide an authoritative root-cause verdict, or exhaustively read every source. Pod/Deployment/StatefulSet/DaemonSet and Argo Rollout (`kind=Rollout`, `group=argoproj.io`) get minified resource + `resourceContext` + selected, capped current and previous container logs across pods + `crashCause` evidence that pairs active crashloop status with one highest-signal filtered log line (`logLineSelection` states how the line was chosen, in descending confidence: `fatal_pattern`, `traceback_header_only`, `last_matched_line`, `log_tail`) + filtered events + `startupBlockers`; Application/Kustomization/Flux HelmRelease get reconciler status + related parsed issues; Service/Ingress/HTTPRoute/GRPCRoute/Gateway get coverage-honest reachability evidence: a `summary` (headline + tested/passed/failed/skipped counts over the intended routes), `routes` (per-route outcome + `confidence` - `indirect` = reached only via the API-server proxy, not the live-traffic path), `notTested` (with why + a copyable command), an optional named `brokenRoute` when established, and `path` (hops with static findings). Optional active reachability test (`probe: true`, bounded to a 3s total budget; a timeout returns an honest partial). The returned bundle is frozen from one call, but its sources are not read atomically; preserve its limits, errors, timestamps, and confidence. In `resourceContext`, `issueSummary` uses live-operational `critical`/`warning`, while `auditSummary` uses the Checks posture-remediation ladder `critical`/`high`/`medium`/`low` (current built-ins are `high`/`medium`) and is not evidence of an active outage.	`kind` (required: workload, GitOps reconciler, or network entry kind), `group` (optional API group; set it for CRDs or same-kind collisions, for example `argoproj.io` for `Rollout`; built-in groups are inferred when omitted), `namespace` (required), `name` (required), `probe` (optional: network kinds only - run DNS/TCP/TLS/HTTP probes as applicable; explicitly non-HTTP Service ports stop at TCP), `in_cluster` (optional on the full `/mcp` endpoint only, MUTATING - network kinds only: runs the applicable probe layers from inside the cluster by creating up to 5 short-lived, self-deleting probe pods under your RBAC; the only diagnose option with a side effect, requires `create jobs`, `list pods`, and `get pods/log`; forces `probe` on; omitted from and rejected by `/mcp-readonly`)
`get_dashboard`	Cluster/namespace health overview - resource counts, failing pods, unhealthy workloads, warning-event groups (`warningGroups`, up to 20 recency-ordered; `totalWarningGroups`/`warningGroupsTruncated` signal when more exist), Helm status. Inventory-style triage before drilling in.	`namespace` (optional)
`top_resources`	Live metrics ranked like `kubectl top	sort`, joined with K8s context (status, restarts, owner, requests/limits). Use for CPU/memory/OOM/load symptoms.	`kind` (optional: `pods` default, `workloads`, `nodes`), `namespace` (optional), `sort` (optional: `cpu` default, `memory`), `limit` (optional, default 20, max 100)
`list_resources`	List resources of a kind with minified summaries + per-row `summaryContext` (managedBy / health / issueCount).	`kind` (required), `group` (optional), `namespace` (optional), `context` (optional: default / `none`)
`search`	Find resources by content/term match (config keys, env refs, images, label values, CRD fields, status messages). Tokens AND’d; secret values never indexed. Supports `kind:`/`ns:`/`label:`/`image:` modifiers and CEL `filter`.	`query` (required), `filter` (optional CEL), `limit` (optional)
`get_resource`	Detailed view of a single resource - minified spec + status + metadata + default-on `resourceContext` (managedBy / exposes / selectedBy / uses / runsOn / scheduling / issue+audit rollups). Exact `kueue.x-k8s.io/v1beta2` Workloads expose a bounded admission observation under `scheduling.observations`. Admission is not Pod placement or physical capacity, and unsatisfied admission is not automatically an Issue. See Kueue + Cluster Autoscaler for semantics and limits. `issueSummary` uses live-operational `critical`/`warning`; `auditSummary` uses the Checks posture-remediation ladder `critical`/`high`/`medium`/`low` (current built-ins are `high`/`medium`) and is not evidence of an active outage. Optionally include heavier supplemental data (events / metrics). For logs use `get_pod_logs` / `get_workload_logs` / `diagnose`.	`kind` (required), `namespace` (optional - omit for cluster-scoped kinds: Node, ClusterRole, IngressClass, etc.), `name` (required), `group` (optional, for ambiguous kinds), `include` (optional: `events,metrics,changes,revisions` - `revisions` lists rollback targets for Deployment/StatefulSet/DaemonSet/Rollout with `number`, `image`, `createdAt`, `isCurrent`; Rollouts also mark `isStable`, the revision an abort reverts to), `context` (optional: `basic` default, `none` for bare minified output)
`get_topology`	Whole-namespace/cluster topology graph (nodes + edges). Use `summary` format for LLM-friendly text chains. Once you have a suspect root, prefer `get_neighborhood`.	`namespace` (optional), `view` (optional: `traffic` or `resources`), `format` (optional: `graph` or `summary`)
`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.	`kind` (required), `namespace` (optional), `name` (required), `profile` (optional: `auto` default / `all`), `hops` (optional, default 1, max 2)
`get_events`	Recent Kubernetes events, deduplicated and sorted Warning-groups-first then by recency - all types by default, so warnings lead and lifecycle events follow as timeline evidence. Filter by resource kind/name to scope; `type=Warning` for warnings only, `type=Normal` for lifecycle only.	`namespace` (optional), `limit` (optional, default 20, max 100), `kind` (optional), `name` (optional), `type` (optional: `all` default, `Warning`, `Normal`)
`get_changes`	Recent meaningful changes from the Kubernetes cluster timeline plus native Helm release deployment/operation history (`source: helm`). Use to investigate what changed before an incident, including failed upgrades, rollbacks, and current Helm revisions. If the response includes `sourcesErrored`, treat it as partial data for those sources. Use `get_helm_release include=history,operations` for the full Helm revision trail.	`namespace` (optional), `kind` (optional), `name` (optional), `since` (optional, e.g. `1h`, `30m`; default `1h`), `limit` (optional, default 20, max 50)
`get_pod_logs`	Pod logs with secret redaction. Without `grep`, prioritizes errors/warnings and falls back to recent tail lines; with `grep`, returns only regex-matching lines instead of applying the diagnostic filter.	`namespace` (required), `name` (required), `container` (optional), `tail_lines` (optional, default 200), `grep` (optional)
`get_workload_logs`	Aggregated logs from all pods of a workload (Deployment, StatefulSet, DaemonSet, Job, Argo Workflow). Without `grep`, auto-filters for diagnostic relevance; with `grep`, returns only matching timestamp-prefixed lines.	`kind` (required), `namespace` (required), `name` (required), `container` (optional), `tail_lines` (optional, default 100 per pod), `grep` (optional)
`get_cluster_audit`	Static config posture - best-practice findings (Security / Reliability / Efficiency) with remediation. INDEPENDENT of operational health. Finding severity and the explicit `summary.critical`/`high`/`medium`/`low` counts are posture remediation priority; current built-in checks emit `high` or `medium`. For “what’s broken right now?” use `issues`.	`namespace` (optional), `category` (optional), `severity` (optional: `critical`, `high`, `medium`, or `low`)
`get_cluster_upgrade_readiness`	Upgrade impact analysis for a target Kubernetes minor - the evidenced check catalog (version skew, removed/deprecated API usage across live manifests / Helm sources / API-server metrics, node runtime + cgroup evidence, drain feasibility, webhook readiness, release-specific config checks). The verdict is not a readiness guarantee: `unknown` checks had incomplete evidence, `coverage` states what the caller’s RBAC could actually inspect, and `no_access` returns no verdict at all. Tier 1 is one row per check; `check=<id>` expands into findings with evidence + remediation, paged 25 at a time (`offset` + `scan_id` bind pages to one scan snapshot). Results are memoized ~60s per caller; `refresh=true` re-scans after a fix. Fix findings at the source `evidence.source` names - live objects via `patch_resource`/`apply_resource`, Helm findings in the chart, GitOps-managed resources in Git.	`target` (optional, default next minor), `check` (optional), `level` (optional: `blocker`, `warning`, `review`), `offset` (optional), `scan_id` (required when `offset` > 0), `refresh` (optional)
`list_packages`	Installed packages (Helm releases, label-managed workloads, CRDs, Argo Applications, Flux HelmReleases + Kustomizations) with source provenance, versions, and health, in one call. Response includes `sourceLegend` for the stable source codes.	`namespace` (optional), `source` (optional: `H`/`helm`, `L`/`labels`, `C`/`crds`, `A`/`argocd`, `F`/`fluxcd`), `chart` (optional substring)
`list_helm_releases`	List Helm releases with status, resource health, storage namespace, Flux ownership, current `lastOperation`, and a capped `operations` trail when Helm history indicates failed upgrades, rollback-after-failure, rollbacks, or stuck pending operations. Use this first for Helm deployment debugging.	`namespace` (optional)
`get_helm_release`	Detailed Helm release info with owned resources, resource health, Flux ownership, current `lastOperation`, `operationInsight` (active/recovered state, likely resource to inspect, suggested compare), hooks, and failed/running hook diagnostics with live Job/Pod/Event/redacted-log evidence when still available. Use `include=history,operations` for the full Helm revision trail; `include=values` for key-aware redacted user values; `include=diff,values_diff,notes_diff,resource_diff` for revision comparison. For releases with `storageNamespace`, pass that value as `namespace`.	`namespace` (required: Helm storage namespace), `name` (required), `include` (optional: `values,history,operations,diff,values_diff,notes_diff,resource_diff`), `diff_revision_1` (required when `include` contains a diff token) / `diff_revision_2` (optional, defaults to current)
`list_namespaces`	List all namespaces with status	(none)
`get_subject_permissions`	Effective RBAC permissions of a ServiceAccount / User / Group. Without `verb`/`resource`, returns the existing bindings, deduplicated flat rules, and (for SAs) Pods using it. With both fields, runs an authoritative SubjectAccessReview for a ServiceAccount and returns a focused allow/deny result; this requires the caller itself to have `create subjectaccessreviews.authorization.k8s.io`.	`kind` (required: `ServiceAccount`, `User`, or `Group`), `namespace` (required for ServiceAccount; omit for User/Group), `name` (required), `verb` + `resource` (optional pair; ServiceAccount only), `group`, `resource_namespace` (defaults to subject namespace; explicitly empty for a cluster-scoped or cluster-wide API request, not aggregation of namespace-local grants), `subresource`, `resource_name` (optional check refinements)
`query_prometheus`	Execute PromQL against the cluster’s Prometheus (auto-discovered or `--prometheus-url`; works with PromQL-compatible backends: Thanos, VictoriaMetrics, Mimir). `type=instant` returns current values; `type=range` returns time-series history with automatic step adjustment. Empty results include a bounded list of related active metric names when a metric family can be inferred. Oversized results return a label-cardinality summary + suggested `topk` rewrite instead of raw data.	`query` (required), `type` (optional: `instant` default, `range`), `since` (optional, e.g. `30m`, `1h`, `24h`, `7d`; default `1h`), `start` / `end` (optional RFC3339, override `since`), `step` (optional, auto-calculated when omitted), `max_points` (optional, default 300, max 600), `timeout` (optional seconds, default 30, max 180)
`discover_metrics`	Discover exact metric names (enriched with type/help from Prometheus metadata) or values of one label before writing PromQL. Lists active series from the last hour; `truncated: true` means narrow the `match` selector.	`match` (PromQL series selector; required when `label` is empty), `label` (optional: list values of this label instead of metric names), `limit` (optional, default 100, max 500)
`get_prometheus_rules`	List Prometheus alerting/recording rules with PromQL definitions, state, labels, annotations, and active alert instances. Alert-investigation entry point: fetch the rule definition, then run its query with `query_prometheus`.	`type` (optional: `alert`, `record`), `name` / `group` (optional substring filters), `state` (optional: `firing`, `pending`, `inactive`), `limit` (optional, default 50, max 200)

API group is part of a resource’s identity. Radar infers the canonical group for built-in kinds, but callers should pass group for a supported CRD or whenever a Kind can exist in more than one group. For example, diagnose an Argo Rollout with:

{"kind":"Rollout","group":"argoproj.io","namespace":"prod","name":"checkout"}

This selects the Argo Rollout workload path; it does not imply that diagnose supports arbitrary custom resource shapes. For issues, read timing_summary when present; it explains timing combinations that are easy to misread without schema context. The raw provenance fields remain available for filtering. first_seen is an evidence-backed lower bound, onset_unknown means no contributing signal has a known onset, and resource_created_at is resource-age context rather than issue age. A missing first_seen is exposed to CEL as 0; require first_seen != 0 for any age filter, and also require onset_coverage_unknown == 0 when the whole row must have exact timing.

Write Tools

Tool	Description	Parameters
`apply_resource`	Create or update a Kubernetes resource from YAML. Supports multi-document YAML, per-document partial-failure results, server-side dry-run preview, and SSA ownership-conflict reporting.	`yaml` (required), `mode` (optional: `apply` or `create`, default `apply`), `dry_run` (optional, default false), `namespace` (optional, override), `verify` (optional, default true: real mutations return post-mutation state, submitted-vs-live diff, workload rollout/pods, and related issues; dry runs return a preview diff), `force` (optional, default false: take SSA field ownership from other managers)
`patch_resource`	Patch one existing Kubernetes resource with JSON Patch, JSON Merge Patch, or strategic merge patch. Use for precise field/list edits when you know the exact path and do not want to rewrite the full manifest or take broad server-side-apply ownership. Strategic patch is for built-in Kubernetes kinds and name-keyed list edits, such as changing one container.	`kind` (required), `name` (required), `namespace` (required for namespaced resources), `group` (optional), `patch_type` (optional: `json` default, `merge`, or `strategic`), `patch` (required JSON string), `dry_run` (optional), `verify` (optional, default true: real mutations return compact post-patch state and JSON Patch field checks; dry runs return a preview diff)
`manage_workload`	Restart, scale, or rollback a Deployment, StatefulSet, DaemonSet, or Argo Rollout. Note: `scale` is not supported for DaemonSets. On a Rollout, `rollback` rewrites the pod template and therefore starts a new rollout that re-runs every canary step, pause, and analysis - use `manage_rollout` `abort` to revert traffic immediately, or follow the rollback with `promote-full`.	`action` (required: `restart`, `scale`, `rollback`), `kind` (required), `namespace` (required), `name` (required), `replicas` (for scale), `revision` (for rollback - enumerate with `get_resource include=revisions`)
`manage_rollout`	Drive an Argo Rollout’s progressive delivery - the verbs with no Deployment equivalent. `abort` reverts traffic to the last stable version at once without touching spec and stays aborted until retried (the incident-response verb); `retry` clears an abort; `promote` clears the current pause to advance one step; `promote-full` skips all remaining steps, pauses, and analysis (emergency hotfix) - it waits for the controller to observe the current pod template first, so straight after a rollback it may report that the controller has not caught up, which is safe to retry; `skip-step` advances exactly one canary step (canary only). Rollback / restart / scale go through `manage_workload` with `kind=rollout`.	`action` (required: `abort`, `retry`, `promote`, `promote-full`, `skip-step`), `namespace` (required), `name` (required)
`manage_cronjob`	Trigger, suspend, or resume a CronJob	`action` (required: `trigger`, `suspend`, `resume`), `namespace` (required), `name` (required)
`manage_gitops`	Manage ArgoCD and FluxCD resources - sync, refresh, terminate, suspend, resume, rollback (Argo), reconcile (Flux), reconcile-with-source (Flux)	`action` (required), `tool` (required: `argocd` or `fluxcd`), `namespace` (required), `name` (required), `kind` (FluxCD only). For `sync`: `revision`, `prune`, `dry_run`, `force`, `apply_only`, `sync_options`. For `rollback` (Argo only): `history_id` (required), `prune`, `dry_run`. Per-action input validation rejects flags that don’t apply to the action (e.g. `force` on `suspend`) so callers fail loudly instead of silently.
`manage_node`	Cordon, uncordon, or drain a Kubernetes node	`action` (required: `cordon`, `uncordon`, `drain`), `name` (required), `delete_empty_dir_data` (optional, default true), `force` (optional), `timeout` (optional, seconds, default 60)

Available Resources

URI	Description
`cluster://health`	Cluster health summary (same data as `get_dashboard`)
`cluster://topology`	Full cluster topology graph
`cluster://events`	Recent warning events (up to 50)

Security

Safe by design - most read tools do not change cluster state and are annotated with readOnlyHint. On the full /mcp endpoint, the exception is diagnose(in_cluster=true) on network entry resources, which creates up to five self-deleting probe pods; that full diagnose tool carries neither readOnlyHint nor destructiveHint, so clients that prompt only on destructiveHint will not prompt for it. On /mcp-readonly, diagnose omits and rejects in_cluster and carries 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

Get started

Views

In-cluster capabilities

Integrations

Self-hosted setup

Cloud

Reference

Kubernetes MCP server

Why MCP instead of raw kubectl?

Enabling / Disabling

MCP Endpoint

Catalog Introspection

Setup Instructions

Claude Code

Claude Desktop

Cursor

Windsurf

VS Code Copilot

Cline

JetBrains AI

OpenAI Codex

Gemini CLI

MCP Registry / Docker

Diagnose evidence limits

Available Tools

Read Tools

Write Tools

Available Resources

Security

​Why MCP instead of raw kubectl?

​Enabling / Disabling

​MCP Endpoint

​Catalog Introspection

​Setup Instructions

​Claude Code

​Claude Desktop

​Cursor

​Windsurf

​VS Code Copilot

​Cline

​JetBrains AI

​OpenAI Codex

​Gemini CLI

​MCP Registry / Docker

​Diagnose evidence limits

​Available Tools

​Read Tools

​Write Tools

​Available Resources

​Security

Why MCP instead of raw kubectl?

Enabling / Disabling

MCP Endpoint

Catalog Introspection

Setup Instructions

Claude Code

Claude Desktop

Cursor

Windsurf

VS Code Copilot

Cline

JetBrains AI

OpenAI Codex

Gemini CLI

MCP Registry / Docker

Diagnose evidence limits

Available Tools

Read Tools

Write Tools

Available Resources

Security