Skip to main content
mcpSource-backed
Radar logo

Radar MCP Server

Built-in HTTP MCP server for Radar, the local-first Kubernetes UI that gives Claude token-optimized cluster topology, health, events, logs, audit, RBAC, GitOps, workload, and resource-management tools.

by Skyhook · submitted by oktofeesh1·added 2026-06-06·
Review first review before installing

Open the source and read safety notes before installing.

Citation facts

Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.

Source URLs
https://raw.githubusercontent.com/skyhook-io/radar/main/docs/mcp.md, https://github.com/skyhook-io/radar, https://radarhq.io
Brand
Radar
Brand domain
radarhq.io
Brand asset source
brandfetch
Safety notes
Radar MCP can inspect live Kubernetes resources, topology, warning events, logs, metrics, package inventory, audit findings, RBAC permissions, Helm releases, ArgoCD resources, and FluxCD resources., The MCP implementation includes mutating tools for applying YAML, patching resources, restarting or scaling workloads, triggering or suspending CronJobs, managing GitOps resources, and cordoning, uncordoning, or draining nodes., Mutating tools are RBAC-enforced and annotated as destructive-capable, but clients and operators should still require human review before running them., `apply_resource` with forced ownership can take server-side-apply fields from other managers such as Helm or GitOps controllers., `manage_node drain` can evict pods and affect live workloads., Radar provides flags and environment variables that disable MCP, disable exec/local terminal paths, or loosen localhost/origin protections; only relax those protections in trusted development contexts.
Privacy notes
Kubeconfig paths, cluster names, namespaces, resource names, manifests, labels, annotations, topology edges, metrics, events, logs, RBAC rules, Helm release data, GitOps metadata, and audit findings may be exposed to the MCP client and model provider., Radar's MCP docs state that Secret data is not exposed and environment/log values are redacted for known sensitive patterns, but metadata, key names, errors, and operational context can still be sensitive., Workload logs can contain credentials, customer data, request payloads, internal hostnames, incident details, or proprietary deployment context., In-cluster deployments without authentication make all MCP callers share the pod service account view, so restrict network access, enable auth, and scope RBAC before exposing shared endpoints.
Author
Skyhook
Submitted by
oktofeesh1
Claim status
unclaimed
Last verified
2026-06-06

Decision playbook

Review trust signals before you adopt

Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.

Compare context
Selected

0

Current score

63

Baseline

Delta

No baseline selected

No major trust-signal divergence detected in the current selection.

Source and provenance checks

Needs review

Confirm ownership and provenance before trusting install instructions.

  • Source link availableRequired

    Open the canonical repository and verify ownership.

    Done
  • Source provenance statusRequired

    Marked as source-backed.

    Done
  • Metadata reviewed

    No reviewed flag detected in metadata.

    Pending

Safety and privacy checks

Complete

Validate risk disclosures before installation or API wiring.

  • Safety notes presentRequired

    Review the listed safety guidance before running commands.

    Done
  • Privacy notes presentRequired

    Review data handling notes before connecting accounts or secrets.

    Done
  • Trust level risk gateRequired

    Trust level does not block evaluation.

    Done

Package and install checks

Needs review

Check package metadata and artifact integrity signals.

  • Install payload available

    Install or copy payload is available for review.

    Done
  • Package verification flag

    No package verification flag provided.

    Pending
  • Checksum metadata

    No checksum provided for downloaded artifact.

    Pending

Compare-driven decision checks

Needs review

Use compare context to validate trade-offs before adoption.

  • Compare tray has multiple entries

    Add at least one more entry to compare trust differences.

    Pending
  • Baseline comparison available

    No baseline peer selected yet.

    Pending
  • Diverging trust signals identified

    No major trust-signal divergence found.

    Pending

Setup at a glance

CLI install

Copy-ready — paste the snippet to get started.

20 minutes

Adoption plan

Balanced adoption plan

Current risk score 24/100. Use staged verification before broader rollout.

Risk 24

Pre-adoption checks

Validate source and review signals before any execution.

  • Confirm source provenanceRequired

    Source URL/provenance metadata is present.

    Done
  • Confirm metadata review state

    No review metadata found; increase manual validation.

    Pending
  • Verify install payload

    Install/config payload exists and can be inspected.

    Done

Security checks

Confirm safety, privacy, and package integrity signals.

  • Review safety notesRequired

    Safety notes are present.

    Done
  • Review privacy notesRequired

    Privacy notes are present.

    Done
  • Verify package integrity metadata

    No package verification/checksum metadata.

    Pending

Rollout

Adopt in controlled steps based on the selected plan.

  • Run in isolated sandbox firstRequired

    Use a constrained sandbox and observe behavior across multiple tasks.

    Pending
  • Roll out graduallyRequired

    Roll out to a small cohort before wider usage.

    Pending
  • Set monitoring and fallback

    Define rollback path and monitor errors after adoption.

    Pending

Evidence readiness

Evidence readiness matrix · balanced

Missing required evidence: Metadata review. Risk score 31.

Risk 31

Source provenance

Present

Source repository/provenance is listed.

Required in this preset

Metadata review

Missing

Review metadata is missing.

Required in this preset

Safety notes

Present

Safety notes are present.

Required in this preset

Privacy notes

Present

Privacy notes are present.

Optional in this preset

Package integrity

Missing

Package integrity metadata is missing.

Optional in this preset

Install payload

Present

Install payload is available.

Required in this preset

Required gaps: Metadata review

Decision timeline

Decision timeline · balanced

Blocking gaps: Check metadata review status. Risk 28.

Risk 28

triage

Confirm source provenanceRequired

Source/provenance metadata is available.

Done

triage

Check metadata review statusRequired

Review metadata is missing.

Pending

verify

Review safety notesRequired

Safety notes are available.

Done

verify

Review privacy notes

Privacy notes are available.

Done

verify

Validate package integrity metadata

Package integrity metadata is missing.

Pending

rollout

Verify install payload and commandsRequired

Install payload is available.

Done

Blockers: Check metadata review status

Prerequisite readiness

Prerequisite readiness

5 prerequisites to line up before setup. Have accounts and credentials ready first. Includes a review or approval gate.

0/5 ready
Account & credentials1Configuration1Network & hosting2Review & approval120 minutes

Safety & privacy surface

Safety & privacy surface

6 safety and 4 privacy notes across 6 risk areas. Review closely: credentials & tokens, permissions & scopes, third-party handling.

6 areas
  • SafetyPermissions & scopesRadar MCP can inspect live Kubernetes resources, topology, warning events, logs, metrics, package inventory, audit findings, RBAC permissions, Helm releases, ArgoCD resources, and FluxCD resources.
  • SafetyGeneralThe MCP implementation includes mutating tools for applying YAML, patching resources, restarting or scaling workloads, triggering or suspending CronJobs, managing GitOps resources, and cordoning, uncordoning, or draining nodes.
  • SafetyExecution & processesMutating tools are RBAC-enforced and annotated as destructive-capable, but clients and operators should still require human review before running them.
  • SafetyGeneral`apply_resource` with forced ownership can take server-side-apply fields from other managers such as Helm or GitOps controllers.
  • SafetyGeneral`manage_node drain` can evict pods and affect live workloads.
  • SafetyLocal filesRadar provides flags and environment variables that disable MCP, disable exec/local terminal paths, or loosen localhost/origin protections; only relax those protections in trusted development contexts.
  • PrivacyThird-party handlingKubeconfig paths, cluster names, namespaces, resource names, manifests, labels, annotations, topology edges, metrics, events, logs, RBAC rules, Helm release data, GitOps metadata, and audit findings may be exposed to the MCP client and model provider.
  • PrivacyCredentials & tokensRadar's MCP docs state that Secret data is not exposed and environment/log values are redacted for known sensitive patterns, but metadata, key names, errors, and operational context can still be sensitive.
  • PrivacyCredentials & tokensWorkload logs can contain credentials, customer data, request payloads, internal hostnames, incident details, or proprietary deployment context.
  • PrivacyPermissions & scopesIn-cluster deployments without authentication make all MCP callers share the pod service account view, so restrict network access, enable auth, and scope RBAC before exposing shared endpoints.

Disclosure: Apache-2.0 open-source Kubernetes UI with a built-in MCP server. The upstream project also mentions Radar Cloud for hosted team use.

Safety notes

  • Radar MCP can inspect live Kubernetes resources, topology, warning events, logs, metrics, package inventory, audit findings, RBAC permissions, Helm releases, ArgoCD resources, and FluxCD resources.
  • The MCP implementation includes mutating tools for applying YAML, patching resources, restarting or scaling workloads, triggering or suspending CronJobs, managing GitOps resources, and cordoning, uncordoning, or draining nodes.
  • Mutating tools are RBAC-enforced and annotated as destructive-capable, but clients and operators should still require human review before running them.
  • `apply_resource` with forced ownership can take server-side-apply fields from other managers such as Helm or GitOps controllers.
  • `manage_node drain` can evict pods and affect live workloads.
  • Radar provides flags and environment variables that disable MCP, disable exec/local terminal paths, or loosen localhost/origin protections; only relax those protections in trusted development contexts.

Privacy notes

  • Kubeconfig paths, cluster names, namespaces, resource names, manifests, labels, annotations, topology edges, metrics, events, logs, RBAC rules, Helm release data, GitOps metadata, and audit findings may be exposed to the MCP client and model provider.
  • Radar's MCP docs state that Secret data is not exposed and environment/log values are redacted for known sensitive patterns, but metadata, key names, errors, and operational context can still be sensitive.
  • Workload logs can contain credentials, customer data, request payloads, internal hostnames, incident details, or proprietary deployment context.
  • In-cluster deployments without authentication make all MCP callers share the pod service account view, so restrict network access, enable auth, and scope RBAC before exposing shared endpoints.

Prerequisites

  • Radar installed from Homebrew, Krew, GitHub Releases, Scoop, or another upstream-supported path.
  • Running Radar server or `kubectl radar` session with the MCP endpoint enabled.
  • MCP client that supports Streamable HTTP server configuration.
  • Kubernetes kubeconfig, context, namespace scope, or in-cluster service account reviewed before connecting an AI client.
  • Human approval policy for apply, patch, workload, CronJob, GitOps, and node-management tools.

Schema details

Install type
cli
Troubleshooting
No
Source repository stats
Scope
Source repo
Collection metadata
Estimated setup
20 minutes
Difficulty
advanced
Tool listing metadata
Disclosure
Apache-2.0 open-source Kubernetes UI with a built-in MCP server. The upstream project also mentions Radar Cloud for hosted team use.
Full copyable content
claude mcp add radar --transport http RADAR_MCP_URL

About this resource

Content

Radar is a local-first Kubernetes UI from Skyhook. Its built-in MCP server lets Claude and other MCP clients query a running Radar session through Streamable HTTP, using curated tools rather than raw kubectl output.

The MCP surface is built for cluster troubleshooting and operations. It exposes token-optimized tools for dashboards, topology, neighborhoods, issues, events, logs, resource search, resource details, package inventory, Helm release inspection, RBAC review, and cluster audit findings. It also includes guarded write tools for Kubernetes resource changes, workload actions, GitOps actions, CronJob actions, and node management.

Source Review

These sources were reviewed on 2026-06-06. Prefer the live repository, Radar website, releases page, MCP guide, license, MCP handler source, tool registration source, and apply-tool source for current setup, transport, security controls, and tool behavior.

Features

  • Built into the Radar binary and enabled by default unless Radar starts with MCP disabled.
  • Streamable HTTP transport mounted on the running Radar server.
  • Client setup examples for Claude Code, Claude Desktop, Cursor, Windsurf, VS Code Copilot, Cline, JetBrains AI, OpenAI Codex, and Gemini CLI.
  • Read tools for dashboards, top resource usage, resource lists, resource detail, topology, neighborhoods, events, changes, pod logs, workload logs, cluster audit, package inventory, Helm releases, namespaces, search, and RBAC subject permissions.
  • Diagnostic tool that bundles resource context, logs, events, and startup blockers for a workload.
  • Write tools for applying YAML, patching resources, restarting, scaling, or rolling back workloads, managing CronJobs, managing ArgoCD/FluxCD resources, and cordoning, uncordoning, or draining nodes.
  • Secret-data suppression, environment/log redaction, RBAC-aware access, and destructive-tool annotations in the MCP implementation.
  • Local binary flow for personal cluster access and in-cluster deployment path for shared team access with authentication and RBAC planning.

Installation

Install Radar through an upstream-supported path such as Homebrew, Krew, GitHub Releases, Scoop, or the desktop installers. For Homebrew:

brew install skyhook-io/tap/radar

Start Radar with access to the intended Kubernetes context:

kubectl radar

Then configure an HTTP-capable MCP client with the Radar MCP endpoint for your chosen host and port:

{
  "mcpServers": {
    "radar": {
      "url": "RADAR_MCP_URL"
    }
  }
}

Use a local endpoint for personal development. For shared or in-cluster deployments, review Radar authentication, Kubernetes RBAC, namespace scoping, and network exposure before connecting AI clients.

Use Cases

  • Ask Claude what is broken in a Kubernetes namespace before drilling into a failing workload.
  • Summarize topology relationships around a Service, Deployment, Pod, or GitOps-managed application.
  • Pull focused pod or workload logs after Radar has narrowed the affected resource.
  • Review audit findings, RBAC permissions, package inventory, and warning events from one MCP surface.
  • Investigate recent changes that may explain an incident.
  • Trigger a reviewed restart, scale, rollback, CronJob run, GitOps action, or node operation only after confirming the exact scope.
  • Use Radar's minified resource output when raw Kubernetes YAML would be too noisy for an LLM context window.

Safety and Privacy

Radar MCP can operate against real Kubernetes clusters. Start with the smallest namespace and RBAC scope that supports the workflow, and require human approval before any apply, patch, workload action, CronJob action, GitOps action, or node-management call. Be especially careful with server-side apply ownership, node drains, production rollbacks, and actions that interact with Helm, ArgoCD, or FluxCD state.

Treat cluster metadata as sensitive. Even with Secret data suppression and redaction controls, manifests, labels, annotations, logs, events, metrics, repository references, namespace names, RBAC rules, and topology edges can reveal customer data, security posture, incident details, or internal architecture. Keep the MCP endpoint local or authenticated, and do not expose unauthenticated in-cluster deployments to untrusted clients.

Duplicate Check

No skyhook-io/radar, Radar MCP Server, radarhq.io, or kubectl radar entry was found in content/mcp or README.md. Existing Kubernetes and Argo CD MCP entries cover different direct server implementations; the TrendRadar entry is an unrelated news and RSS monitoring project.

Source citations

Add this badge to your README

Show that Radar MCP Server is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.

Listed on HeyClaude
[![Listed on HeyClaude](https://heyclau.de/badge/mcp/radar-mcp-server.svg)](https://heyclau.de/entry/mcp/radar-mcp-server)

How it compares

Radar MCP Server side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.

1 trust signal differ across this comparison (Submitter).

Field

Built-in HTTP MCP server for Radar, the local-first Kubernetes UI that gives Claude token-optimized cluster topology, health, events, logs, audit, RBAC, GitOps, workload, and resource-management tools.

Open dossier

Manage Docker and Kubernetes infrastructure from Claude — list environments, inspect containers, manage GitOps workflows, troubleshoot resources, and proxy Docker/K8s API calls — with the official Portainer MCP server generated from the Portainer OpenAPI spec.

Open dossier

MCP server for Coolify infrastructure management, diagnostics, deployments, logs, projects, environments, applications, databases, services, env vars, storage, scheduled tasks, private keys, cloud tokens, teams, and docs search.

Open dossier

Google Cloud gcloud MCP server from googleapis that lets Claude run approved gcloud CLI commands with allowlist and denylist controls for cloud resource inspection, automation, and operations.

Open dossier
Next steps
Trust
Review statusNot reviewedNot reviewedNot reviewedNot reviewed
Package trustPackage not verifiedPackage not verifiedPackage not verifiedPackage not verified
Source provenanceSource-backedSource-backedSource-backedSource-backed
SubmitterDiffersoktofeesh1oktofeesh1oktofeesh1
Install riskReview firstReview firstReview firstReview first
Notes Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓
BrandRadar logoRadarKubernetes logoKubernetesCoolify MCP Server logoCoolify MCP Servergcloud MCP Server logogcloud MCP Server
Categorymcpmcpmcpmcp
SourceSource-backedSource-backedSource-backedSource-backed
AuthorSkyhookPortainerStuart MasonGoogle APIs
Added2026-06-062026-06-182026-06-062026-06-06
Platforms
Harness
Source repo
Safety notesRadar MCP can inspect live Kubernetes resources, topology, warning events, logs, metrics, package inventory, audit findings, RBAC permissions, Helm releases, ArgoCD resources, and FluxCD resources. The MCP implementation includes mutating tools for applying YAML, patching resources, restarting or scaling workloads, triggering or suspending CronJobs, managing GitOps resources, and cordoning, uncordoning, or draining nodes. Mutating tools are RBAC-enforced and annotated as destructive-capable, but clients and operators should still require human review before running them. `apply_resource` with forced ownership can take server-side-apply fields from other managers such as Helm or GitOps controllers. `manage_node drain` can evict pods and affect live workloads. Radar provides flags and environment variables that disable MCP, disable exec/local terminal paths, or loosen localhost/origin protections; only relax those protections in trusted development contexts.The server exposes the full Portainer REST API — including container start/stop/delete, stack deployment, and Kubernetes resource management. The API proxy tools forward requests directly to your Docker/Kubernetes API — review before executing any destructive operations. For team deployments over HTTP, the container requires TLS (either BYO certificates or a TLS-terminated reverse proxy) — do not expose plaintext on the public internet.Coolify MCP Server can start, stop, restart, redeploy, cancel deployments, update env vars, create or delete projects, environments, applications, databases, services, backups, storages, scheduled tasks, private keys, GitHub apps, and cloud tokens depending on API permissions. Batch tools such as `restart_project_apps`, `bulk_env_update`, `stop_all_apps`, and `redeploy_project` can affect multiple production services at once. Deployment, control, backup, storage, private key, cloud token, GitHub app, and scheduled-task operations should require explicit confirmation. Custom `--header` values may carry auth-proxy secrets; never let an agent invent, log, or modify them casually. Test on non-production projects or staging resources before allowing Claude to operate live Coolify infrastructure.gcloud MCP Server executes gcloud CLI commands with the permissions of the active gcloud account. Allowed commands can create, update, delete, deploy, scale, list, export, or configure Google Cloud resources depending on IAM permissions and selected services. The server blocks command substitution, pipes, redirection, SSH-style commands, interactive commands, and a default set of sensitive command prefixes, but allowed gcloud commands can still have real infrastructure, billing, IAM, and data impact. Use allowlists for narrow workflows and service account impersonation with limited roles when possible. Require human approval for IAM, billing, networking, firewall, storage, database, secret, deployment, delete, and production-impacting commands.
Privacy notesKubeconfig paths, cluster names, namespaces, resource names, manifests, labels, annotations, topology edges, metrics, events, logs, RBAC rules, Helm release data, GitOps metadata, and audit findings may be exposed to the MCP client and model provider. Radar's MCP docs state that Secret data is not exposed and environment/log values are redacted for known sensitive patterns, but metadata, key names, errors, and operational context can still be sensitive. Workload logs can contain credentials, customer data, request payloads, internal hostnames, incident details, or proprietary deployment context. In-cluster deployments without authentication make all MCP callers share the pod service account view, so restrict network access, enable auth, and scope RBAC before exposing shared endpoints.Container names, environment configurations, Docker/Kubernetes resource details, and GitOps credentials from your Portainer instance are surfaced in Claude's context. Your Portainer API key grants the same access as your Portainer user account — treat it as a secret.Coolify access tokens, base URLs, custom headers, application UUIDs, server IPs, domains, logs, env vars, deployment logs, private keys, cloud-provider tokens, GitHub app data, team membership, backups, database metadata, and service configuration can be exposed to the MCP client. Application and deployment logs may contain secrets, customer data, build output, container metadata, private repository details, and runtime errors. Environment variable and cloud-token tools can reveal or mutate sensitive infrastructure credentials. Documentation search is local to the server, but Coolify API calls contact the configured Coolify instance. Keep tokens and auth-proxy headers in local MCP client configuration only, and avoid sharing transcripts that include infrastructure identifiers or logs.gcloud output can reveal project IDs, resource names, regions, IAM bindings, service accounts, logs, errors, labels, metadata, URLs, secrets references, billing context, and infrastructure topology. Authentication state, ADC files, service account impersonation details, access tokens, project IDs, and local gcloud configuration should stay out of prompts and repository files. Command output may be retained by the MCP client, model provider, terminal logs, shell history, and chat transcripts. Avoid broad listing or export commands against production projects unless data handling and retention have been reviewed.
Prerequisites
  • Radar installed from Homebrew, Krew, GitHub Releases, Scoop, or another upstream-supported path.
  • Running Radar server or `kubectl radar` session with the MCP endpoint enabled.
  • MCP client that supports Streamable HTTP server configuration.
  • Kubernetes kubeconfig, context, namespace scope, or in-cluster service account reviewed before connecting an AI client.
  • A running Portainer instance (CE or Business Edition).
  • A Portainer API key: My Account → Access tokens → Add access token.
  • Python with `uv` installed: `pip install uv` or `brew install uv`.
  • Match the MCP server minor version to your Portainer instance minor version (e.g., `mcp-portainer~=2.42.0` for Portainer 2.42.x).
  • Running Coolify instance with API access enabled.
  • Coolify API access token scoped to the resources Claude may inspect or manage.
  • Node.js 20 or newer for the published npm server.
  • Review of which servers, projects, applications, databases, services, deployments, env vars, private keys, teams, cloud tokens, and scheduled tasks the token can access.
  • Node.js 20 or newer with npm or another compatible package runner.
  • Google Cloud CLI installed and authenticated.
  • Active gcloud account, project, and configuration scoped to the intended environment.
  • Least-privilege user or service account impersonation for the allowed cloud actions.
Install
brew install skyhook-io/tap/radar
claude mcp add portainer -e PORTAINER_URL=https://portainer.example.com -e PORTAINER_API_KEY=ptr_xxxxx -- uvx --from "mcp-portainer~=2.42.0" mcp-portainer
npx -y @masonator/coolify-mcp
npx -y @google-cloud/gcloud-mcp
Config
{
  "mcpServers": {
    "radar": {
      "url": "RADAR_MCP_URL"
    }
  }
}
{
  "mcpServers": {
    "portainer": {
      "command": "uvx",
      "args": ["--from", "mcp-portainer~=2.42.0", "mcp-portainer"],
      "env": {
        "PORTAINER_URL": "https://portainer.example.com",
        "PORTAINER_API_KEY": "ptr_xxxxx",
        "PORTAINER_TLS_VERIFY": "0"
      }
    }
  }
}
{
  "mcpServers": {
    "coolify": {
      "command": "npx",
      "args": [
        "-y",
        "@masonator/coolify-mcp"
      ],
      "env": {
        "COOLIFY_BASE_URL": "https://your-coolify-instance.example",
        "COOLIFY_ACCESS_TOKEN": "your-api-token"
      },
      "type": "stdio"
    }
  }
}
{
  "mcpServers": {
    "gcloud": {
      "command": "npx",
      "args": [
        "-y",
        "@google-cloud/gcloud-mcp"
      ],
      "type": "stdio"
    }
  }
}
Citations
ClaimUnclaimedUnclaimedUnclaimedUnclaimed
Open 4 picks in the interactive comparison tool

Signals

Loading live community signals…

More like this, weekly

A short, calm digest of reviewed Claude resources. Unsubscribe any time.