Radar is a Kubernetes visibility and management MCP server that enables AI assistants to query, diagnose, and manage Kubernetes clusters through pre-processed, token-optimized data.
Observability & Read
get_dashboard — Cluster/namespace health triage: resource counts, failing pods, unhealthy workloads, recent Warning events, and Helm release status in one call
issues — Live operational issues ranked by severity: CrashLoopBackOff, OOMKills, missing refs, scheduling blockers, GitOps sync failures, False CRD conditions
get_resource — Drill into a single resource with spec/status/metadata and relationship context
list_resources — List all resources of a given kind with health summaries
search — Find resources by content match across ConfigMaps, CRD fields, env refs, images, labels, annotations, and status messages
get_events — Recent Kubernetes Warning events filtered by namespace, kind, or resource name
get_pod_logs — Diagnostically filtered logs from a specific Pod/container
get_workload_logs — Aggregated logs across all pods of a Deployment/StatefulSet/DaemonSet, deduplicated and filtered to errors/warnings/panics
diagnose — One-call root-cause bundle for a broken workload or GitOps reconciler: spec, logs, events, startup blockers, and recent changes
get_changes — Recent meaningful spec/config changes ranked by relevance, with field-level diffs
get_topology — Full cluster or namespace topology graph (service routing or ownership hierarchy)
get_neighborhood — BFS-expanded dependency graph around a specific resource for cross-resource failure tracing
top_resources — Live CPU/memory metrics ranked like kubectl top, joined with pod status, restarts, requests, and limits
get_cluster_audit — Best-practice findings: security (privileged containers, dangerous capabilities, hostPath), reliability (missing PDB, single replicas), and efficiency (missing resource limits, orphaned resources)
get_subject_permissions — Effective RBAC permissions for a ServiceAccount, User, or Group including inherited group grants
list_namespaces — All Kubernetes namespaces and their status
list_helm_releases / get_helm_release — List all Helm releases or get detailed info including owned resources, values, revision history, and manifest diffs
list_packages — Unified view of all installed packages across Helm, CRDs, ArgoCD, and FluxCD
Write & Management
apply_resource — Create or update a resource from YAML, with dry-run, force field-ownership takeover, and multi-document support
patch_resource — Precise field mutations via JSON Patch, JSON Merge Patch, or strategic merge patch, with dry-run preview
manage_workload — Restart (rolling), scale, or rollback a Deployment/StatefulSet/DaemonSet
manage_gitops — Sync, refresh, terminate, rollback, suspend, or resume ArgoCD Applications and FluxCD resources
manage_cronjob — Trigger a manual Job run, suspend, or resume a CronJob schedule
manage_node — Cordon, uncordon, or drain a Kubernetes node
Provides support for monitoring ArgoCD GitOps workflows, including viewing status and managing resources.
Provides support for monitoring FluxCD GitOps workflows, including viewing status and managing resources.
Allows management of Helm releases in Kubernetes clusters, including viewing, upgrading, rolling back, and uninstalling releases.
Provides tools for exploring and managing Kubernetes cluster resources, including topology visualization, resource browsing, logs, and exec.
Allows querying Prometheus metrics from Kubernetes clusters for monitoring and visualization.
Allows querying VictoriaMetrics metrics from Kubernetes clusters for monitoring and visualization.
The missing open-source Kubernetes UI. Single binary. No account required. Free forever.
🌐 radarhq.io · Docs · Releases
Topology, resources, Helm, GitOps, traffic, audit, upgrade impact, and MCP context for AI agents — from your laptop or in-cluster.
Views — Topology · Resources · Image Filesystem · Timeline · Helm · Compare · TLS · GitOps · Traffic · Cost · Audit · Upgrade impact · RBAC · MCP · Auth
Install and run in 30 seconds:
curl -fsSL https://get.radarhq.io | sh && kubectl radarZero install on your cluster — runs on your laptop, talks to the K8s API directly
Single binary — no dependencies, no agents, no CRDs
Fast on big clusters — tested on tens of thousands of pods, with responsive views and live updates under real cluster churn
Private by design — your cluster data stays on your machine. No account, no agents, no cloud sync, no cluster telemetry
Airgapped-friendly — runs as a single binary against the Kubernetes API and works in locked-down environments with outbound egress blocked
Real-time — watches your cluster via informers, pushes updates to the browser via SSE
Works everywhere — GKE, EKS, AKS, minikube, kind, k3s, or any conformant cluster
AI-ready — built-in MCP server lets AI agents inspect, diagnose, and operate your cluster through Radar
In-cluster option — deploy with Helm for shared team access with RBAC-scoped permissions
"Have Radar deployed at work. As far as Kubernetes dashboards go, this is one of the best." — u/TheRealNetroxen
Related MCP server: LUMINO MCP Server
Quick Install:
curl -fsSL https://get.radarhq.io | shHomebrew:
brew install skyhook-io/tap/radarThen run: kubectl radar. Quick install, PowerShell, Homebrew, and Scoop also set up the radar shorthand. Krew and direct downloads use kubectl radar unless you add your own radar symlink.
Krew (kubectl plugin manager):
kubectl krew install radarScoop (Windows):
scoop bucket add skyhook https://github.com/skyhook-io/scoop-bucket
scoop install radarPowerShell (Windows):
irm https://get.radarhq.io/install.ps1 | iexDirect download — GitHub Releases for macOS, Linux, or Windows.
Native desktop app — no terminal needed.
Homebrew (macOS):
brew install --cask skyhook-io/tap/radar-desktopDebian/Ubuntu — download the .deb from GitHub Releases, then:
sudo apt install ./radar-desktop_*.debFedora/RHEL — download the .rpm from GitHub Releases, then:
sudo rpm -i radar-desktop_*.rpmScoop (Windows):
scoop bucket add skyhook https://github.com/skyhook-io/scoop-bucket
scoop install radar-desktopWindows (direct download) — GitHub Releases.
Deploy to your cluster for shared team access:
helm repo add skyhook https://skyhook-io.github.io/helm-charts
helm install radar skyhook/radar -n radar --create-namespaceSee the In-Cluster Deployment Guide for Gateway API and ingress exposure, authentication, and RBAC configuration.
# Opens browser automatically
kubectl radar
# Quick install, PowerShell, Homebrew, and Scoop also set up the bare command
radarTo inspect an in-cluster Radar Cloud installation without changing it:
radar cloud status
radar cloud status --context my-cluster
radar cloud status --context my-cluster --namespace radar --release radarThe command reports installation ownership, chart and image, agent readiness,
and Cloud configuration without printing the connection token. Passing both
--namespace and --release selects an exact installation. Live tunnel status
is reported by Radar Cloud using the token in the referenced Kubernetes Secret.
If the Secret or Hub is unavailable, local installation diagnostics still run.
Interactive terminals use restrained status colors; set NO_COLOR (or pipe the
output) for plain text. URLs, tokens, and suggested commands remain unstyled.
CLI Flags
The table below covers common startup flags. See the full CLI reference; radar --help is authoritative for the installed version.
Flag | Default | Description |
|
| Path to primary kubeconfig file |
| Comma-separated directories containing additional kubeconfig files | |
| (all) | Initial namespace filter (supports multi-select in the UI; also used as RBAC fallback for namespace-scoped users) |
| (all) | Initial namespace filters as a comma-separated list, e.g. |
|
| Pin namespaced informer caches to a single namespace for large clusters (scoping to multiple namespaces is not supported yet). Requires |
|
| Server port |
|
| HTTP listen address. Use |
| Serve Radar under a URL prefix such as | |
|
| Don't auto-open browser |
| Browser to use when opening the UI, e.g. | |
|
| Timeline storage backend: |
|
| Path to SQLite database (when using sqlite storage) |
|
| Maximum SQLite DB + WAL size before pruning oldest events (e.g. |
|
| Maximum events to retain in timeline (memory only) |
|
| Disable terminal and debug shell |
|
| Disable Helm write operations |
|
| Disable the host local terminal |
|
| Image for ephemeral debug containers and node debug pods. If built-in restricted PodSecurity rejects the default pod debug container, Radar retries with a restricted-compatible Linux security context using the target/pod non-root UID, or UID |
|
| Paginate the initial LIST of high-cardinality kinds (Pods, ReplicaSets) at this size. Helps very large clusters that fail to sync; only used when WatchList streaming is unavailable. Try |
|
| Maximum time a kubeconfig context switch may take. Widen on high-latency control planes — see Tuning for slow clusters. Env: |
|
| Hard upper bound on the initial critical-cache sync wait before Radar falls through to a partial-data render. Env: |
|
| Timeout for the cluster-wide namespace LIST used to decide if the user is RBAC-namespace-restricted. A timeout on a slow control plane is misreported in the UI as "Limited list — RBAC". Env: |
|
| Cap on the namespace-fallback probe fanout (used by accounts that can list namespaces cluster-wide but not list a specific kind cluster-wide). Raise above |
| (auto-discover) | Manual PromQL-compatible query URL, including Prometheus, VictoriaMetrics, Thanos, or Mimir (skips auto-discovery) |
| HTTP header sent with every Prometheus request, format | |
| HTTP header sent with every Prometheus request, sourced from an environment variable, format | |
| (auto-detect, then USD) | Override the ISO 4217 currency label for OpenCost values. Radar labels values but does not convert them. |
|
| Authentication mode: |
|
| Disable MCP server for AI tool integration |
|
| Start only the MCP catalog over stdio for registry introspection |
| Show version and exit |
See Configuration Guide for details on cluster connection precedence, multiple kubeconfig files, and context switching.
The default deadlines (30 s context switch, 5 m first-paint backstop, 5 s namespace LIST, 20 scope candidates) are tuned for healthy clusters reached over fast, low-latency connections. They are too tight for clusters reached over SSH tunnels, geographically distant control planes, or accounts subject to API-server throttling, where they surface as one of three symptoms:
"Context switch timed out" toasts when the cache eventually does sync
"Limited list — RBAC doesn't allow listing all namespaces" even though the account has cluster-wide list permission (the LIST timed out, not RBAC)
Kinds silently marked denied because the namespace they live in fell past the 20-entry candidate cap
Widen the four flags via CLI or via the matching environment variables
(RADAR_CONTEXT_SWITCH_TIMEOUT, RADAR_FIRST_PAINT_BACKSTOP,
RADAR_NAMESPACE_LIST_TIMEOUT, RADAR_MAX_SCOPE_CANDIDATES) — env vars
keep secrets out of ps and let in-cluster deployments source the values
from a ConfigMap:
# CLI
kubectl radar \
--context-switch-timeout=120s \
--first-paint-backstop=10m \
--namespace-list-timeout=30s \
--max-scope-candidates=200
# Environment (e.g. in a Deployment manifest)
RADAR_CONTEXT_SWITCH_TIMEOUT=120s \
RADAR_FIRST_PAINT_BACKSTOP=10m \
RADAR_NAMESPACE_LIST_TIMEOUT=30s \
RADAR_MAX_SCOPE_CANDIDATES=200 \
kubectl radarDefaults are preserved when neither the flag nor the env var is set, so existing deployments are unaffected.
Interactive graph showing how your Kubernetes resources are connected in real-time.
Two modes: Resources (full hierarchy) and Traffic (network flow path)
Group by namespace, app label, or view ungrouped
Filter by resource kind — click any node for full details
Auto-layout powered by ELK.js, live updates via SSE
Table-based resource browser with smart columns per resource kind.
Browse all resource types including CRDs
Search by name, filter by status or problems (CrashLoopBackOff, ImagePullBackOff, etc.)
Add custom columns from any label or annotation — sortable, filterable, and resizable
Click any resource for YAML manifest, related resources, logs, and events
Set regular or init-container images on Deployments, StatefulSets, DaemonSets, and Argo Rollouts, with live rollout progress in tables, drawers, workload views, and Applications
Inspect container image filesystems directly from the Pod view — no need to pull images locally or exec into containers.
Click any container image in a Pod to browse its complete filesystem
Tree view with file sizes, permissions, and symlink targets
Search files by name across the entire image
Download individual files for inspection
Works with public images (Docker Hub, Quay, GHCR) and private registries (GCR, ECR, ACR) using your cluster's ImagePullSecrets
Disk-based layer caching for fast repeated access
Unified timeline of Kubernetes events and resource changes.
Filter by event type (all or warnings only)
Resource change diffs showing what changed (replicas, images, etc.)
Real-time updates as new events occur
Manage Helm releases deployed in your cluster — inspect values and rendered manifests, diff revisions, identify failed upgrades and rollback-after-failure patterns, diagnose failed hooks, upgrade, rollback, and uninstall. Radar tracks available chart upgrades (from your configured repos or your own OCI registries) and lets you pick a specific target version. See Helm Support for the detailed behavior and limits.
View all releases across namespaces with status, chart version, app version, resource health, storage namespace, and Flux ownership
Inspect values, compare revisions across values/manifests/notes/resources, and view release history
Surface failed upgrades, stuck pending operations, rollback history, and inferred atomic-style rollbacks
Correlate failed/running hooks with remaining Job, Pod, Event, and redacted log evidence
Upgrade, rollback, or uninstall releases directly from the UI
Diff any two Kubernetes resources of the same kind side-by-side — like comparing a staging Deployment to its production sibling, or two pods that should be identical but aren't.
Two entry points: a Compare button in the resource detail drawer, or compare mode in the resource table (toggle, pick two rows, hit Compare)
Side-by-side or unified view, with one-click swap of A ↔ B
Diff-only mode collapses unchanged regions so you only see what differs
Spec-only mode drops status fields to focus on intent rather than observed state
Server-assigned noise (managedFields, resourceVersion, kubectl.kubernetes.io/last-applied-configuration) is stripped automatically so the diff stays signal — flip Raw metadata on if you actually want to see it
Same-namespace candidates are surfaced first in the picker — usually the resource you want to compare against
Shareable URLs: /compare?kind=&apiGroup=&a=ns/name&b=ns/name
View TLS certificate details and expiry dates across all namespaces — catch expiring certificates before they cause outages.
Parses TLS secrets to show certificate subject, issuer, and validity period
Dashboard-level certificate expiry overview
Available from the resource detail view for any TLS-type Secret
Monitor, diagnose, and manage FluxCD and ArgoCD resources from a dedicated GitOps workspace.
Fleet view + per-app detail page (Topology / Changes / Activity tabs) for ArgoCD (Application, ApplicationSet, AppProject) and FluxCD (GitRepository, OCIRepository, HelmRepository, Bucket, Kustomization, HelmRelease, Alert)
Diagnosis pipeline — field-level drift, recent events per resource, stuck-drift-loop detection, parsed operation-failures, structured one-click remediation
Lifecycle awareness — Terminating chip replaces stale Sync/Health badges; severity ramps with deletion age; mutating ops refuse on zombies
Cross-linked from the rest of Radar — Managed by chip in resource drawers, GitOps routing from Topology + Timeline + Helm view, Consumed by panel on Flux source CRs
MCP integration — manage_gitops exposes sync / suspend / resume / reconcile / rollback with lifecycle-aware refusal
See the GitOps guide for the full feature matrix, RBAC requirements, demo cluster, and single-cluster scope notes.
Visualize live network traffic between services using Hubble, Caretta, Istio, or Beyla.
Auto-detects Hubble (Cilium), Istio, Caretta, or Grafana Beyla as traffic data sources
Beyla (standalone or via Grafana Alloy) provides eBPF L4 + HTTP visibility with no service mesh, read from Prometheus
Beyla needs its network feature enabled, and per-port edges additionally need dst.port and transport named in attributes.select — both are off by default, and Radar says so in the Traffic view rather than showing partial edges silently
Animated flow graph showing requests per second between services
Filter by namespace, protocol, or status code
Setup wizard to install a traffic source if none is detected
Read-only diagnosis for Karpenter-managed fleets — why is my pod pending, which NodePool could take it, why aren't my nodes joining, what is disruption doing to my fleet? Appears automatically when Karpenter NodePools are detected (RBAC-gated).
Overview — fleet KPIs with claim lifecycle detail, a cluster scheduling-capacity bar (requests vs allocatable, in-flight beyond the edge, pending demand as an honest not-to-scale count), prioritized operational signals, and the NodePool inventory
NodePool detail — the capacity ledger (configured limit, provisioned, headroom, allocatable, scheduled requests, unallocated, actual usage), claim lifecycle, fleet composition, and workload attribution
Demand — pending pods grouped by scheduling signature, each group evaluated against every NodePool's declared constraints with per-predicate evidence; filterable by state, pool, and workload
Activity — provisioning / disruption / interruption episodes classified from Karpenter's exact event vocabulary, with per-evidence confidence
Every quantity carries per-value certainty (= ≥ ≤ ?) — unavailable is never rendered as zero, partial is never rendered as exact
Issues, Pending-pod drawers, and the Home posture card deep-link into the right diagnosis
See docs/capacity.md for the full reference.
Track Kubernetes spending from OpenCost metrics in a PromQL-compatible backend or a Kubecost 3 Aggregator. Auto mode keeps working Prometheus cost metrics, then discovers a local Kubecost Aggregator; a federated agent-only cluster can use its central Aggregator URL in Settings, config, or Helm. Radar reads the configured currency from a running OpenCost or Kubecost workload when available and otherwise uses USD. Source changes are tested and applied separately from the display-currency preference, which can be saved even when a source is unavailable. Radar labels values but does not convert them.
Allocated workload cost with namespace scope called out separately from cluster-wide node capacity cost
Cost trend charts with 6h/24h/7d range selector when Prometheus history is available
Namespace and workload-level cost breakdowns with efficiency scoring
Node costs with instance type and region pricing
Appears automatically when compatible Prometheus metrics or Kubecost current allocation data is detected
Proactive best-practices scanner with 31 checks across security, reliability, and efficiency — inspired by Polaris, Kubescape, Trivy, and NSA/CISA guidelines. Runs instantly against cached data with zero cluster-side installation.
Security: privileged containers, privilege escalation, dangerous/insecure capabilities, host namespaces, container runtime socket mounts, sensitive host paths, secrets in ConfigMaps, auto-mounted service account tokens
Reliability: missing probes, image tag latest, single-replica deployments, missing PDB/topology spread, pod HA risk (all replicas on same node), orphan services/ingresses, deprecated API versions
Efficiency: missing CPU/memory requests and limits, orphan ConfigMaps/Secrets
Check-grouped remediation queue with search and category, severity, and framework filters; expand a check to see affected resources
Each finding includes description and remediation guidance, with inline hide actions for a check or category
Configurable: ignored namespaces (with wildcard patterns), disabled checks, persisted across sessions
Framework labels: NSA/CISA, CIS benchmarks
MCP tool (get_cluster_audit) for AI-assisted cluster analysis
Hop-ordered diagnosis for Service, Ingress, HTTPRoute, GRPCRoute, and Gateway - answering "if traffic is sent toward this resource, does it reach a healthy process, and if not which hop breaks first?"
Composes the detections Radar already runs (missing backend Service, port mismatches, no-ready-endpoints, route not Accepted by parent Gateway, readiness probe targeting the wrong port) into a path shape ordered along the traffic flow
Upstreams (Ingresses / Routes pointing at a Service) are judged independently - one broken Ingress doesn't condemn the other delivery paths
First critical hop is named explicitly so the operator can localize the break without reading the whole list; each finding ships a kubectl reproducer
Optional one-shot reachability test runs DNS / TCP / TLS / HTTP probes against the declared path - direct TCP when Radar is in-cluster, K8s API server proxy when running from a laptop - so the same button works regardless of where Radar runs. Probes never override the static verdict; they add evidence.
NetworkPolicies that select the subject's pods are statically evaluated for their caller-independent ingress rules: a "would block" WARNING prediction when no rule admits the path's port, a source-restricted advisory, or an outbound egress note. It's a prediction, never a verdict - the CNI is the only enforcement authority, so the live in-cluster probe confirms or downgrades it
Static trace is pure functions over the in-memory informer cache. Active probing from a laptop uses the cluster's normal RBAC (get services/proxy, get pods/proxy); in-cluster mode goes directly to the data path.
Exposed via the Reachability tab in the resource detail view (and via the network branch of the MCP diagnose tool for AI consumers) - see docs/reachability.md
Open Checks → Upgrade impact before upgrading the control plane. Radar compares the current cluster with a target Kubernetes minor and orders evidenced compatibility, health, admission, drain, runtime, and configuration checks by required action. Release-specific checks appear only when their Kubernetes minor lies in the selected upgrade path; the current catalog is reviewed through Kubernetes 1.37.
Finds blockers such as skipped minor versions, APIs removed in the target release, unsupported kubelet or kube-proxy skew, overlapping PodDisruptionBudgets, the gitRepo volume driver disabled in Kubernetes 1.36, and removed or locked Kubernetes 1.37 feature gates or scheduling.k8s.io/v1alpha2 objects
Flags likely operational impact such as FlexVolume exposure and renamed control-plane metrics as warnings, while intent-dependent configuration such as deprecated Service externalIPs remains review
Inspects live resources, aggregated API availability, Helm release manifests, kubectl last-applied configuration, API server usage metrics, and PrometheusRule expressions
Distinguishes Passed, Review, Warning, Blocked, Incomplete, and Not applicable instead of flattening advisory findings, likely impact, and missing evidence into one state
Scans every namespace the current identity can read; the header namespace picker remains a browsing filter and does not narrow upgrade analysis
Shows the bundled catalog boundary and the evidence scope for sampled or unavailable data
See the Kubernetes upgrade impact guide for the check catalog, coverage semantics, and RBAC notes.
Inspect what any ServiceAccount can actually do — without three kubectl describe calls.
ServiceAccount detail: direct bindings, effective permissions (per-binding and deduplicated flat view), inherited grants via implicit groups (system:authenticated, system:serviceaccounts), and "Used by Pods" closing the loop
Pod detail: "Permissions" section showing the most-permissive rules the Pod's SA grants, plus a blast-radius alert when the SA has wildcards, cluster-admin, escalation verbs, or cluster-wide create pods
Workload detail (Deployment / StatefulSet / DaemonSet): same Permissions section framed at the workload level — every Pod the workload spawns inherits these grants
Namespace detail: RBAC summary with RoleBindings configured here + ClusterRoleBindings whose subjects reference this namespace
Role / ClusterRole detail: who is bound to this role, with subject summaries inline
RoleBinding detail: inline preview of the rules the binding grants + warnings when subjects include wide groups (system:authenticated, system:unauthenticated, system:masters)
"My Permissions" panel: namespace-scoped live SelfSubjectRulesReview for the current user — for fast "why can't I do X" debugging
MCP: get_subject_permissions tool exposes the same data to AI agents for "is this SA over-privileged?" / "blast radius if compromised?" queries
Read-only visibility ships first; the considered follow-ups (RBAC audit checks, verb × resource matrix, subject explorer, graph view, in-UI edits, "can-i" queries) are tracked in #1090.
Radar includes a built-in Model Context Protocol (MCP) server that lets AI agents — Claude, Cursor, Copilot, and others — inspect, diagnose, and operate your cluster through Radar.
Instead of raw kubectl output (verbose YAML that burns through LLM context windows), your AI gets pre-processed, token-optimized data: topology graphs, health assessments, deduplicated events, and filtered logs. Diagnosis is read-only by default; optional in-cluster route probing uses short-lived, self-deleting probe pods. Write operations such as restart, scale, apply, and rollback are identified for client confirmation and enforced through Kubernetes RBAC.
Enabled by default. Disable with --no-mcp. See the MCP Guide for setup instructions.
For shared in-cluster deployments, Radar supports optional user authentication with per-user Kubernetes RBAC.
Proxy mode — works with oauth2-proxy, Pomerium, Cloudflare Access, or any auth proxy that sets forwarded headers
OIDC mode — built-in login via Google, Okta, Dex, Keycloak, or any OIDC provider
Per-user namespace scoping and write authorization via K8s impersonation
UI adapts automatically — buttons only appear if the user has RBAC permission
No auth by default (local use). See the Authentication Guide for setup.
Radar auto-discovers any CRD in your cluster. Popular tools get dedicated integrations with topology edges, detail views, and AI summaries.
Default chart RBAC covers the built-in Kubernetes kinds listed below — Workloads, Networking (including NetworkPolicies and PodDisruptionBudgets), Configuration, Storage (PersistentVolumes, PersistentVolumeClaims, StorageClasses), HorizontalPodAutoscalers, ServiceAccounts, LimitRanges, ResourceQuotas, Nodes, Namespaces, and Events. On Kubernetes 1.37, Radar also surfaces the Workload, PodGroup, CompositePodGroup, PodCertificateRequest, and ClusterTrustBundle APIs when the API server advertises them; the scheduling APIs are feature-gated, while the certificate APIs are stable and enabled by default. These use the generic resource browser rather than dedicated renderers. RBAC objects (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings) are opt-in via rbac.viewRBAC=true. CRD-based integrations (Gateway API, VerticalPodAutoscaler, Calico, ArgoCD, FluxCD, cert-manager, etc.) need both the CRD installed in your cluster and read access granted — most groups are default-on under rbac.crdGroups.<name> (e.g. gatewayApi, verticalPodAutoscaler, calico); check values.yaml or add custom rules via rbac.additionalRules.
Upgrade impact also gets list-only access to CSIStorageCapacities, FlowSchemas, PriorityLevelConfigurations, and PodSecurityPolicies on clusters where those kinds are served. These reads inspect source-manifest evidence and do not add the kinds to Radar's resource browser.
Category | Resources |
Workloads | Deployments, DaemonSets, StatefulSets, ReplicaSets, Pods, Jobs, CronJobs |
Networking | Services, Ingresses, NetworkPolicies, Endpoints, EndpointSlices, PodDisruptionBudgets |
Configuration | ConfigMaps, Secrets (names only, values hidden), LimitRanges, ResourceQuotas |
Storage | PersistentVolumeClaims, PersistentVolumes, StorageClasses |
Autoscaling | HorizontalPodAutoscalers, VerticalPodAutoscalers |
Cluster | Nodes, Namespaces, ServiceAccounts, Events |
Other Kubernetes APIs | Workloads, PodGroups, CompositePodGroups, PodCertificateRequests, ClusterTrustBundles (only when served by the cluster) |
GitOps (FluxCD) | GitRepository, OCIRepository, HelmRepository, Kustomization, HelmRelease, Alert |
GitOps (ArgoCD) | Application, ApplicationSet, AppProject |
Argo Rollouts | Rollout |
Argo Workflows | Workflow, WorkflowTemplate |
cert-manager | Certificate, CertificateRequest, Order, Challenge, Issuer, ClusterIssuer |
Gateway API | Gateway, GatewayClass, HTTPRoute, GRPCRoute, TCPRoute, TLSRoute |
Istio | VirtualService, DestinationRule, Gateway, ServiceEntry, PeerAuthentication, AuthorizationPolicy |
Traefik | IngressRoute, IngressRouteTCP, IngressRouteUDP, Middleware, MiddlewareTCP, TraefikService, ServersTransport, ServersTransportTCP, TLSOption, TLSStore |
Contour | HTTPProxy |
Knative Serving | Service, Configuration, Revision, Route, DomainMapping |
Knative Eventing | Broker, Trigger, EventType, Channel, InMemoryChannel, Subscription |
Knative Sources | PingSource, ApiServerSource, ContainerSource, SinkBinding |
Knative Flows | Sequence, Parallel |
Knative Networking | Ingress, Certificate, ServerlessService |
Karpenter | NodePool, NodeClaim (+ provider-specific NodeClasses via auto-discovery) |
KEDA | ScaledObject, ScaledJob, TriggerAuthentication, ClusterTriggerAuthentication |
Prometheus Operator | ServiceMonitor, PodMonitor, PrometheusRule, Alertmanager |
Security (Trivy) | VulnerabilityReport, ConfigAuditReport, ExposedSecretReport, ClusterComplianceReport, SbomReport, RbacAssessmentReport, InfraAssessmentReport |
Velero | Backup, Restore, Schedule, BackupStorageLocation, VolumeSnapshotLocation |
External Secrets | ExternalSecret, ClusterExternalSecret, SecretStore, ClusterSecretStore |
CloudNativePG | Cluster, Backup, ScheduledBackup, Pooler |
Crossplane | Managed Resources (any provider), Composite Resources, Claims, Provider, ProviderConfig, Function, Configuration, Composition, CompositionRevision, XRD |
Kyverno | Policy, ClusterPolicy, PolicyReport, ClusterPolicyReport |
Sealed Secrets | SealedSecret |
Dynamic Resource Allocation | ResourceClaim, ResourceClaimTemplate, DeviceClass, ResourceSlice (resource.k8s.io, K8s 1.32+) |
NVIDIA GPU Operator | ClusterPolicy, NVIDIADriver |
Calico | NetworkPolicy, GlobalNetworkPolicy, StagedNetworkPolicy, StagedGlobalNetworkPolicy, StagedKubernetesNetworkPolicy, IPPool, HostEndpoint, Tier |
Kueue | ClusterQueue, LocalQueue, Workload, ResourceFlavor, AdmissionCheck (+ Cluster Autoscaler ProvisioningRequest) — basic |
KubeRay | RayCluster, RayJob, RayService, RayCronJob — basic |
KServe | InferenceService, ServingRuntime, ClusterServingRuntime, InferenceGraph, TrainedModel, LLMInferenceService — basic |
Inference Gateway | InferencePool (v1 + alpha groups), InferenceObjective — basic |
Batch | LeaderWorkerSet, JobSet, Volcano (Job/Queue/PodGroup/JobFlow/JobTemplate), Kubeflow (PyTorchJob/TFJob/MPIJob/TrainJob) — basic |
KAI Scheduler | Queue, PodGroup — basic |
Model serving | KAITO (Workspace, RAGEngine), NVIDIA NIM (NIMService/NIMCache/NIMPipeline), AMD GPU Operator (DeviceConfig) — basic |
Cost (OpenCost / Kubecost) | Namespace/workload/node cost via compatible Prometheus metrics or the Kubecost 3 Aggregator (no CRDs) |
CRDs | Any Custom Resource Definition in your cluster (auto-discovered) |
Shortcut | Action |
| Switch view — |
| Toggle dark/light theme |
| Show keyboard shortcuts |
| Open command palette |
| Focus search (context-aware) |
| Fit topology to screen |
| Zoom in / out / reset (topology) |
| Navigate rows (resources, helm) |
| Jump to first / last row |
| Open selected resource detail |
| Open YAML view |
| Open logs (pods/workloads) |
| Previous / next resource kind |
| Close panel/modal/search |
Topology: Pan (drag), Zoom (scroll), Select (click), Multi-select (Shift+click)
Radar reads your cluster through your own credentials and keeps cluster data local. It does not upload manifests, logs, events, metrics, or resource data to Skyhook, and it does not require an account, agent, or cloud backend. Found a vulnerability? Please report it privately to security@skyhook.io — see SECURITY.md for the process and response timelines.
See the Development Guide for building from source and contributing. For automation and integrations, see the HTTP API reference.
Quick start:
git clone https://github.com/skyhook-io/radar.git
cd radar
make deps
# Terminal 1: Frontend with hot reload (port 9273)
make watch-frontend
# Terminal 2: Backend with hot reload (port 9280)
make watch-backendContributions are welcome! Please read our Contributing Guide for details on the development workflow, pull request process, and coding standards.
Questions or ideas? GitHub Discussions is the place — or come say hi at radarhq.io/community.
Radar is built and maintained by Skyhook (YC W23) and is open source under Apache-2.0. The OSS version is fully featured and the recommended way to run Radar.
For teams that want hosted multi-cluster Radar with SSO and shared dashboards, we also offer Radar Cloud.
Apache 2.0 — see LICENSE
Create or update a Kubernetes resource from a YAML manifest. In 'apply' mode (default), performs a server-side apply with FieldManager=radar and reports field ownership conflicts instead of taking ownership by default. Set force=true only when you intend to take field ownership from other managers (Helm, Flux, GitOps controllers, kubectl). In 'create' mode, performs a strict create that fails if the resource already exists. Supports multi-document YAML separated by '---'. Use dry_run to validate without persisting changes and preview the server-side result. Multi-document failures return per-document status because earlier documents may already be applied. By default returns compact post-mutation state, submitted-vs-live spec differences, rollout/pod status for workloads, and current related issues; set verify=false only when you need a terse write result.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 'apply' (default, create-or-update) or 'create' (fail if exists) | |
| yaml | Yes | YAML manifest to apply (supports multi-document with --- separator) | |
| force | No | apply mode only: force server-side apply field ownership conflicts and take ownership from other managers. Default false; use only when you intend to override Helm/Flux/GitOps/kubectl ownership. | |
| verify | No | return compact post-mutation state, rollout/pod status, and related issues; on dry_run return a preview diff. Default true; set false for a terse write result. | |
| dry_run | No | validate and preview the server-side result without persisting changes | |
| namespace | No | override namespace for the resource |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses server-side apply with FieldManager=radar, conflict handling, multi-document failure behavior, and return content details, offering rich behavioral context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, with each sentence contributing distinct and useful information without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters and no output schema, the description comprehensively covers modes, conflict handling, dry_run, verification, multi-document behavior, and return format, making it fully complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the rationale behind force (field ownership), the effect of dry_run, and the multi-document behavior, enhancing comprehension beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates or updates a Kubernetes resource from a YAML manifest, with explicit details about modes and behavior that distinguish it from read-only sibling tools like get_resource and patch_resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use 'apply' vs 'create' modes and when to set force=true or dry_run, but does not explicitly name alternative sibling tools or state when not to use this tool in favor of others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the agent's decision is 'this workload or GitOps reconciler is broken — find the root cause / localize the failure'. For a single Pod/Deployment/StatefulSet/DaemonSet, bundles: the resource (Kubernetes-shaped detail) + diagnostic resourceContext (managedBy, exposes, selectedBy, uses, runsOn, issue/audit/policy rollups) + current AND previous container logs across the workload's pods + recent Warning events filtered to this resource + a recentChanges section for the workload and directly referenced ConfigMaps (no Secret content) + a startupBlockers section when the workload can't reach Running (unschedulable with the offending node constraint named, admission/quota rejection, or a post-bind CNI/volume stall). For Application/Kustomization/HelmRelease, returns the reconciler resource + GitOps status summary + related parsed issues (cause/action/remediation), without pod-log fan-out. Use for CrashLoopBackOff, OOMKills, failed deploys, image-pull errors, readiness flaps, scheduling failures, error-spewing services, GitOps sync/health failures, or any workload root-causing where you would otherwise call get_resource → events → get_pod_logs → get_pod_logs(previous=true) in sequence — this returns the same data in one round-trip. If you only need ONE facet (e.g. just spec, just logs), prefer the targeted tool. For other CRDs or non-workload kinds, use get_resource (with optional include=events).
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | kind to diagnose: a workload (pod, deployment, statefulset, daemonset) for logs+events+startup blockers, or a GitOps reconciler (application, kustomization, helmrelease) for sync/health summary + parsed failure cause | |
| name | Yes | resource name | |
| since | No | only fetch logs newer than this duration (e.g. 30s, 10m, 1h); empty = full available history | |
| container | No | specific container; defaults to all containers across the workload's pods | |
| namespace | Yes | resource namespace | |
| tail_lines | No | lines per pod/container per stream (current AND previous), default 100 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds valuable context beyond annotations: it discloses log stream capture (current AND previous), event filtering, exclusion of Secret content, and startupBlockers conditions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense but well-structured paragraph. It is front-loaded with the primary trigger, then methodically covers bundle contents, GitOps path, use cases, and alternatives. Every sentence contributes necessary context for a complex diagnostic tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema), the description is remarkably complete. It covers both workload and GitOps resource types, enumerates output sections, names failure scenarios, and directs to alternatives. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3 applies. The description does not add significant new parameter-level meaning; it restates the kind options (workload vs GitOps) but the schema already documents each parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly defines the tool's purpose: 'find the root cause / localize the failure' for broken workloads or GitOps reconcilers. It enumerates the exact data bundles included for workloads and GitOps resources, distinguishing it from sibling tools like get_resource or get_pod_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use when' triggers with concrete scenarios (CrashLoopBackOff, OOMKills, etc.). Also gives clear exclusions: 'If you only need ONE facet... prefer the targeted tool' and 'For other CRDs or non-workload kinds, use get_resource'. This is exemplary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the symptom is 'this worked earlier' or 'something broke after a deploy/config change.' Returns recent meaningful changes ranked with spec/config changes first, including field-level diffs for Deployment env/probes and structured ConfigMap data when available. This is often faster than reading ReplicaSet histories or individual audit/log streams, especially when issues are empty or dominated by baseline failures. Pair with since to bound the window; filter by namespace, kind, or name when you know the scope. Omit namespace when the relevant change may be outside the app namespace.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | filter to a resource kind (e.g. Deployment, Pod) | |
| name | No | filter to a specific resource name | |
| limit | No | max changes to return (default 20, max 50) | |
| since | No | duration to look back, e.g. 1h, 30m, 24h (default 1h) | |
| namespace | No | filter to a specific namespace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only. The description adds valuable behavioral context: ranking order (spec/config changes first), best-effort field-level diffs ('when available'), and a performance comparison. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense, purposeful sentences. The most important usage signal is front-loaded, and every sentence adds either use-case context, behavioral detail, or parameter strategy. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no output schema, the description covers the when, what, why, and how: identifies symptoms, explains return content and ranking, gives performance tradeoffs versus alternatives, and offers filtering strategies. It is fully sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description goes beyond the schema by explaining how to use parameters: 'Pair with since to bound the window', 'filter by namespace, kind, or name', and the important tip to 'Omit namespace when the relevant change may be outside the app namespace.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns recent meaningful changes ranked with spec/config changes first, including field-level diffs.' This is a specific verb+resource combination that distinguishes it from siblings like get_events or get_resource, which focus on raw events or static resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description opens with explicit symptoms ('this worked earlier' or 'something broke after a deploy/config change') and names alternatives directly: 'This is often faster than reading ReplicaSet histories or individual audit/log streams.' It also provides concrete parameter guidance, including when to omit namespace.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the agent's decision is 'is this cluster well-configured / compliant?' — STATIC CONFIG POSTURE, not live operational state. Returns best-practice findings: Security (runAsRoot, privileged containers, dangerous capabilities, hostPath/hostNetwork, secret-in-ConfigMap), Reliability (single replicas, missing PDB, missing TopologySpread, podHARisk, Service/Ingress without matching backends, stuckTerminating, deprecatedAPIVersion), and Efficiency (missing resource requests/limits, orphaned ConfigMaps/Secrets, under/over-utilization). Each finding has remediation guidance. INDEPENDENT of operational health: a healthy pod can have many audit findings (badly configured but working), a crashing pod can have zero (cleanly configured but failing). For 'what's broken right now?' use the issues tool. Respects user's audit settings (ignored namespaces, disabled checks). Filter by namespace, category, or severity. Resources absent from findings should NOT be reported as non-compliant — empty findings for a scope means no violations, not a failed check.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max audit violation findings to return (default 30, max 100). This limits findings only; compliant resources are not returned. | |
| category | No | filter by category: Security, Reliability, or Efficiency | |
| severity | No | filter by severity: danger or warning | |
| namespace | No | filter to a specific namespace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, but the description adds crucial behavioral context: audit findings are independent of operational health, empty findings mean no violations (not a failed check), and it respects user audit settings. This goes beyond annotations and prevents misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but every sentence earns its place, front-loading the primary use case and then layering critical caveats. It is well-structured with categories and explicit contrast to sibling tools, making it highly informative without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of audit semantics, the description fully covers interpretation guidance (empty findings = no violations, not non-compliant), independence from operational health, and respect for user settings. No output schema exists, so this level of behavioral detail is essential and provided comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters with descriptions. The description only re-states filtering by namespace, category, severity, and doesn't add additional semantic value beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: assessing static config posture/compliance, and explicitly contrasts it with operational health. It names the specific categories (Security, Reliability, Efficiency) and provides concrete examples, distinguishing it from siblings like 'issues'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use: when deciding 'is this cluster well-configured / compliant?', and when not: for 'what's broken right now?' use the issues tool. This gives clear alternatives and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for inventory-style cluster or namespace health triage, like kubectl get all plus detected problems and warning events in one call. Returns resource counts, failing pods, unhealthy workloads, recent Warning events, and Helm release status so you can rank likely suspects before calling get_resource or logs. Routing: unknown broken thing -> issues; content/name search -> search; service routing/dependencies -> get_topology or get_neighborhood; inventory/counts/Helm/events overview -> get_dashboard. Use namespace for app-local triage; omit it when the root may be cluster-scoped.
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | filter to a specific namespace. Use when triaging one app/tenant namespace before drilling into individual resources. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the safety profile is known. The description adds behavioral context by explaining that it returns an overview for ranking suspects before drilling into get_resource or logs, and describes the scope (cluster vs namespace). It does not mention any limitations like permission requirements or performance, but given the annotation coverage, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense with useful information but not bloated. Every sentence adds value: purpose, return content, routing, and namespace guidance. The structure with a routing list is efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by enumerating what the tool returns. It covers when to use, how to decide among siblings, and parameter semantics. For a single-optional-parameter tool, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema description already explains the namespace filter. The description adds usage nuance: 'Use namespace for app-local triage; omit it when the root may be cluster-scoped.' This goes beyond the schema and clarifies when to set vs omit the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's purpose: inventory-style cluster/namespace health triage, analogous to `kubectl get all` plus problem detection. It specifies the exact returned content (resource counts, failing pods, unhealthy workloads, Warning events, Helm status) and distinguishes it from siblings by naming what it is NOT for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit routing rules: 'unknown broken thing -> issues; content/name search -> search; service routing/dependencies -> get_topology or get_neighborhood; inventory/counts/Helm/events overview -> get_dashboard.' Also gives namespace usage guidance (use for app-local, omit for cluster-scoped), which is exceptionally clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for recent Kubernetes Warning events after an overview points at a namespace or resource, or when the symptom is scheduling, pulling images, restarts, failed mounts, readiness, or controller errors. Events are deduplicated and sorted by recency with reason, message, and count. For a ranked issue list that includes problems/conditions, use issues first.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | filter to events involving this resource kind (e.g. Pod, Deployment) | |
| name | No | filter to events involving this resource name | |
| limit | No | max 100, default 20 | |
| namespace | No | filter to a specific namespace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only behavior. The description adds that events are deduplicated, sorted by recency, and include reason, message, and count. This provides useful behavioral context beyond the schema and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose and usage scenarios, and efficiently covers what the tool returns and when to use alternatives. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple event-listing tool, the description covers the key aspects: what it returns (deduplicated events with reason, message, count), when to use it, and how it differs from 'issues'. It lacks an explicit time range for 'recent', but the limit parameter addresses pagination. Overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all parameters. The description does not add new semantic details about parameters but does provide usage context (e.g., 'after an overview points at a namespace'). This is adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The tool's purpose is clearly stated: to retrieve recent Kubernetes Warning events for troubleshooting specific symptoms. It distinguishes itself from the sibling tool 'issues' by noting that 'issues' provides a ranked list of problems, whereas this tool returns raw events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: after an overview points at a namespace/resource or when symptoms like scheduling errors occur. Also advises to use 'issues' first for a ranked issue list, providing clear differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Helm release including owned resources and their status. Optionally include values, revision history, or manifest diff between revisions using the 'include' parameter (comma-separated: values, history, diff). diff_revision_1 and diff_revision_2 are only used when include contains diff.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | release name | |
| include | No | comma-separated extras to include: values, history, diff. Example: values,history | |
| namespace | Yes | release namespace | |
| diff_revision_1 | No | first revision for diff; only used when include contains diff | |
| diff_revision_2 | No | second revision for diff; only used when include contains diff, defaults to current |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the description does not need to repeat safety info. It adds value by disclosing that the tool returns owned resources and status, and that diff_revision_1/2 only take effect when 'include' contains 'diff'. This enriches the behavioral profile without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, followed by concise, high-signal details about optional parameters. There is no redundancy or filler; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with 5 parameters and no output schema, the description covers the main purpose, optional enhancements, and conditional parameter behavior. It does not explain the response format, but that is typically not required without an output schema, and the read-only annotation reduces risk. The description is sufficiently complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description goes beyond the schema by explaining the accepted values for 'include' (values, history, diff) and the conditional semantics of diff_revision_1 and diff_revision_2. This adds meaningful usage guidance beyond parameter names and basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving detailed information about a specific Helm release, including owned resources and their status. This distinguishes it from sibling tools like list_helm_releases (which lists releases) and get_resource (generic resource access). The verb 'Get' and the resource 'Helm release' provide a specific, actionable purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for a single named Helm release rather than listing all releases, and it explains optional includes (values, history, diff) that can be requested. However, it does not explicitly name alternative tools or state when not to use this tool, so it slightly misses a full 'alternatives' clause.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when investigating cross-resource failures around a known resource: service routing, targetPort/selector/endpoints problems, dependency timeouts, config/secret refs, owner chains, or traffic not reaching pods. Returns the BFS-expanded topology neighborhood around one root, which is usually cheaper and clearer than get_topology once you have a suspect. Typical flow: issues/search/list_resources identify a Service or workload, then get_neighborhood traces its upstream/downstream Services, workloads, Pods, refs, and owners. Profile auto (default) picks a bounded edge set from the root kind; profile all expands every edge type and is heavier, use it only when auto produced a too-narrow neighborhood. Hops defaults to 1 and maxes at 2. Nodes are RBAC-filtered; denied neighbors appear only as aggregate omitted counts.
| Name | Required | Description | Default |
|---|---|---|---|
| hops | No | BFS depth. Default 1, max 2. | |
| kind | Yes | resource kind: pod, deployment, service, application, etc. | |
| name | Yes | resource name | |
| group | No | API group required to disambiguate kinds that collide across groups. Examples: serving.knative.dev for KNative Service (vs core/v1 Service), cluster.x-k8s.io for CAPI Cluster (vs CNPG Cluster), networking.istio.io for Istio Gateway (vs gateway.networking.k8s.io Gateway). Omit for kinds with no known collisions. | |
| profile | No | neighborhood breadth: auto or all. Default: auto (picks a bounded edge set from the root kind). all expands every edge type and is heavier; use only when auto produced a too-narrow neighborhood. | |
| max_nodes | No | node-budget cap. Default 25. When the cap is hit mid-expansion, truncated=true is set and the partial subgraph is returned. | |
| namespace | No | resource namespace; omit for cluster-scoped kinds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals non-obvious behavioral details beyond the annotations: 'Nodes are RBAC-filtered; denied neighbors appear only as aggregate omitted counts.' It also discloses performance/characteristics like 'cheaper' and how profile all is 'heavier.' These traits are not present in annotations (readOnlyHint, openWorldHint) and add valuable context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized for a complex tool. It front-loads the primary use case, then explains the return behavior, profile options, and RBAC filtering in a compact, information-dense paragraph. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of an output schema, the description is thorough: it explains the BFS-expanded neighborhood, typical usage flow, profile behavior, hop limits, and RBAC filtering. It covers the necessary operational context without needing to restate parameter details already in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of parameter descriptions, including defaults and behavior for hops, profile, max_nodes, etc. The tool description largely repeats this information (e.g., 'Hops defaults to 1 and maxes at 2') without adding materially new parameter-level semantics. Baseline of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Returns the BFS-expanded topology neighborhood around one root.' It specifies the resource type (topology around a root) and distinguishes it from the sibling tool get_topology by noting it is 'usually cheaper and clearer ... once you have a suspect.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use when investigating cross-resource failures around a known resource...' and lists concrete scenarios (service routing, targetPort/selector problems, etc.). It also gives alternatives and exclusions, such as preferring get_topology in other situations and advising to use profile all only when auto yields a too-narrow result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use only after narrowing to a specific Pod/container. Returns diagnostically relevant log lines (errors, panics, stack traces, warnings) or falls back to recent tail lines. Set grep to server-side filter like kubectl logs | grep PATTERN when you know an error string, request path, service name, or trace id. For broad incidents, first use issues, get_dashboard, search, list_resources, or get_neighborhood to avoid reading logs from many unrelated pods. If the target is a config value, feature flag, CRD field, env ref, or YAML/spec content, use search rather than logs.
| Name | Required | Description | Default |
|---|---|---|---|
| grep | No | optional regular expression to keep matching log lines before diagnostic filtering, like kubectl logs | grep PATTERN | |
| name | Yes | pod name | |
| since | No | only return logs newer than this duration (e.g. 30s, 10m, 1h), like kubectl logs --since | |
| previous | No | return logs from the previous terminated container instance (e.g. for CrashLoopBackOff diagnosis), like kubectl logs -p | |
| container | No | container name, defaults to first container | |
| namespace | Yes | pod namespace | |
| tail_lines | No | number of lines to fetch from the end (default 200) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that logs are filtered to diagnostically relevant lines and may fall back to tail lines, which is a behavioral trait beyond the readOnlyHint annotation. It also explains the grep parameter's server-side filtering behavior. While it does not detail output format or edge cases, it adds meaningful context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense. It front-loads the primary usage condition ('Use only after narrowing'), followed by the core behavior, grep usage, and alternatives. Every sentence adds value without redundancy, achieving high clarity in limited space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description sufficiently conveys the return type ('log lines') and fallback behavior. It covers when to use, how to use (grep, since, previous via schema), and when to avoid, making it complete for the tool's complexity. The schema covers parameter details, and the description fills behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds extra semantics for the grep parameter, suggesting when to set it: 'when you know an error string, request path, service name, or trace id' and equating it to `kubectl logs | grep PATTERN`. This goes beyond the schema's minimal description and aids effective usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Returns diagnostically relevant log lines (errors, panics, stack traces, warnings) or falls back to recent tail lines.' It uses a specific verb ('returns'), names the resource (pod logs), and differentiates from related tools by emphasizing use for a specific Pod/container after narrowing scope, contrasting with broad incident tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use only after narrowing to a specific Pod/container.' It also states when not to use it, listing alternatives: 'For broad incidents, first use issues, get_dashboard, search, list_resources, or get_neighborhood' and 'If the target is a config value... use search rather than logs.' This clearly distinguishes this tool from siblings and gives concrete conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use AFTER narrowing to one resource. Returns the resource's Kubernetes-shaped spec/status/metadata plus resourceContext when available (relationships, refs, issue/audit/policy rollups). This is the drill-down tool, not the best first call for broad incidents. Start with issues, get_dashboard, search, or list_resources to rank candidates; then call get_resource for the exact object. If you are looking for a string across ConfigMaps, CRD specs, env refs, or object content, use search instead of fetching resources one by one. Use the group parameter for ambiguous kinds such as Knative Service vs core Service.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | resource kind, e.g. pod, deployment, service | |
| name | Yes | resource name | |
| group | No | API group when the kind is ambiguous (e.g. cluster.x-k8s.io for CAPI Cluster vs CNPG Cluster) | |
| context | No | resourceContext tier: 'basic' (default; attaches managedBy / exposes / selectedBy / uses / runsOn / issueSummary / auditSummary rollups) or 'none' (bare minified resource). For full diagnostic tier with logs + events bundled, use the diagnose tool instead. | |
| include | No | optional supplemental data after narrowing to this object: events, metrics, changes. include=changes follows the existing comma-separated include pattern. Separate from context. For logs use get_pod_logs / get_workload_logs (container, previous, since, grep) or diagnose for the full workload bundle. | |
| namespace | No | namespace for namespaced kinds. Leave empty for cluster-scoped kinds (Node, ClusterRole, ClusterRoleBinding, IngressClass, PriorityClass, StorageClass, etc.). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds useful behavioral context beyond that: it mentions optional resourceContext rollups, describes the context tier options ('basic' vs 'none'), and clarifies it is not the best first call for broad incidents. This adds value without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with usage guidance and key output details. Every sentence earns its place; no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's read-only nature, 6 parameters, and no output schema, the description covers purpose, usage order, alternatives, parameter behavior, and expected return content. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for all 6 parameters. The description adds a few examples (e.g., ambiguous kinds for group) and cross-references to diagnose for full tier, but largely relies on schema. Baseline 3 is appropriate since the schema already carries most parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states what the tool does: 'Returns the resource's Kubernetes-shaped spec/status/metadata plus resourceContext when available (relationships, refs, issue/audit/policy rollups).' It clearly positions itself as 'the drill-down tool' and distinguishes from first-call tools and search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use AFTER narrowing to one resource.' It names alternatives: 'Start with issues, get_dashboard, search, or list_resources to rank candidates; then call get_resource for the exact object.' Also instructs to use search for string lookups and group param for ambiguous kinds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the effective RBAC permissions of a Kubernetes subject (ServiceAccount, User, or Group) — what can this principal do across the cluster. Returns: the bindings that grant access (each pointing at its Role/ClusterRole), a deduplicated flat rule list, and (for ServiceAccounts) the Pods running as this SA. Use this to answer 'is this SA over-privileged?', 'why can X do Y?', or 'what's the blast radius if this Pod is compromised?'. For ServiceAccount, namespace is required. For User/Group, omit namespace (those are external identities, not namespaced resources). Inherited grants from implicit group memberships (system:authenticated, system:serviceaccounts) are included for ServiceAccount subjects with the inheritedFromGroup field set per binding so you can distinguish direct from inherited grants.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | subject kind: ServiceAccount, User, or Group | |
| name | Yes | subject name | |
| namespace | No | namespace (required for ServiceAccount, omit for User/Group) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though readOnlyHint is true, the description adds substantial behavioral context: it explains the return structure (bindings, rule list, Pods for ServiceAccounts), the inclusion of inherited grants, and the `inheritedFromGroup` field to distinguish direct from inherited grants. This exceeds the annotation's minimal information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise for the complexity of the tool, with clear front-loading of purpose and use cases. Each sentence provides relevant information (returns, use cases, parameters, inheritance behavior), but it is slightly dense and could be tightened without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description fully covers what the tool returns and how to invoke it correctly. It also addresses edge cases (User/Group namespace omission) and inherited permissions, making it complete for an AI agent to select and use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the conditional requirement for namespace and the distinction between ServiceAccount versus User/Group, which is not fully captured in the schema alone. This justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets effective RBAC permissions for a Kubernetes subject, using the specific verb 'Get' and identifying the resource. It distinguishes itself from sibling tools by focusing on RBAC permissions, a unique capability among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('is this SA over-privileged?', 'why can X do Y?', 'what's the blast radius...') and provides parameter-specific guidance (namespace required for ServiceAccount, omitted for User/Group). This gives clear context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use to map a multi-service incident or dependency graph, preferably scoped to a namespace. Returns Kubernetes resource nodes and edges (Services, workloads, Pods, Ingresses, ConfigMaps, Secrets, owners) so you can see service-to-workload traffic and ownership relationships instead of inspecting resources one by one. Use view=traffic for routing/connectivity questions and view=resources for ownership/deployment hierarchy. Always specify namespace unless you specifically need a cross-namespace graph. If you already know the suspicious root, use get_neighborhood for a smaller focused graph.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | view mode: traffic for service routing/connectivity or resources for ownership hierarchy | |
| format | No | output format: graph (default, full node/edge data) or summary (text description of resource chains) | |
| namespace | No | filter to a specific namespace for a multi-service incident map; recommended unless you need cross-namespace topology |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds behavioral context by listing the types of nodes and edges returned (Services, workloads, Pods, etc.) and the two view modes. It also implies that without a namespace the graph is cross-namespace, adding a scoping behavior not present in the schema. This goes beyond the annotations without over-explaining.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently written and front-loaded with the primary use case. Every sentence earns its place: it explains purpose, return value, view modes, namespace guidance, and points to an alternative tool. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, existing annotations, and absence of an output schema, the description is remarkably complete. It covers what the tool returns, how to scope it, which view to choose, and when to use an alternative. It adequately explains the output for an agent to invoke it correctly without needing additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter descriptions in the schema fully document each field. The description repeats the view modes and namespace recommendation but adds no new parameter syntax or format details. Per the baseline for high schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool maps multi-service incidents or dependency graphs, returning Kubernetes resource nodes and edges. It distinguishes itself from get_neighborhood, which is for smaller focused graphs, and contrasts with inspecting resources one by one, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: use for incident/dependency mapping, prefer scoped namespaces, choose view=traffic for routing/connectivity questions and view=resources for ownership/hierarchy. It also directs users to get_neighborhood when the suspicious root is already known, naming an alternative. This fully addresses when and when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregated logs from all pods of a workload (Deployment, StatefulSet, or DaemonSet). Logs are collected from all matching pods concurrently, then server-side filtered to errors, warnings, panics, and stack traces using deterministic regex patterns and deduplicated. Set grep for additional server-side filtering before that summary stage, like kubectl logs | grep PATTERN. More useful than get_pod_logs when you need logs across all replicas of a workload. If the target is a config value, feature flag, CRD field, env ref, or YAML/spec content, use search rather than logs.
| Name | Required | Description | Default |
|---|---|---|---|
| grep | No | optional regular expression to keep matching log lines before diagnostic filtering, like kubectl logs | grep PATTERN | |
| kind | No | workload kind: deployment, statefulset, or daemonset. Defaults to deployment when omitted. | |
| name | Yes | workload name | |
| since | No | only return logs newer than this duration (e.g. 30s, 10m, 1h), like kubectl logs --since | |
| previous | No | return logs from the previous terminated container instance (e.g. for CrashLoopBackOff diagnosis), like kubectl logs -p | |
| container | No | specific container name, defaults to all containers | |
| namespace | Yes | workload namespace | |
| tail_lines | No | lines per pod (default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, but description provides valuable details: concurrent collection, server-side filtering to error/warning/panic/stack traces, deterministic regex, deduplication, and grep stage. This goes well beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise yet complete: intentional use case, behavioral details, comparison to sibling, and exclusion guidance. Every sentence adds informational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description explains the filtering and aggregation behavior sufficiently for an agent to anticipate results. Minor omission: no mention of line limits or pagination, but these are in schema and less critical for the tool's core purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers all 8 parameters with descriptions (100% coverage). The description adds context for grep behavior and defaults for kind, but most parameter meaning remains schema-driven. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets aggregated logs from all pods of a workload, naming supported kinds (Deployment, StatefulSet, DaemonSet). Distinguishes from get_pod_logs, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this over get_pod_logs ('when you need logs across all replicas'), and directs config/spec searches to the 'search' tool. Provides a concrete kubectl analogy for grep.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the agent's decision is 'what's broken right now?' — LIVE OPERATIONAL STATE, not config posture. Returns a ranked list of currently failing resources: failing Deployments/StatefulSets/CronJobs/HPAs/Nodes/Jobs/PVCs, dangling-reference errors like Pod→missing PVC/CM/Secret/SA, HPA→missing scaleTargetRef, Ingress→missing backend Service, RoleBinding→missing Role, webhook→missing Service, pod startup blockers — why a Pod can't reach Running: unschedulable (arch/taint/resources/affinity), admission-rejected (quota/PodSecurity/webhook), or stuck post-bind (CNI/volume), and False .status.conditions on CRDs from Argo/Flux/Knative/Crossplane/cert-manager/KEDA. Severity normalized to critical/warning. This is one curated stream — there is no source filter; each row carries a source label (problem|missing_ref|scheduling|condition) you can slice on via the CEL filter= if needed. Some rows include diagnostic_context: deterministic facts such as explicit missing refs, selected backend issues, or workload rollups; treat these as triage context, not proof of root cause. When recent_changes is present, consider it if the issue list does not explain the reported symptom; recent_changes_reason says why Radar attached it. It lists recent spec/config changes that may explain failures not yet visible as runtime issues, or help distinguish creation-time baseline failures from the active incident. For raw Kubernetes Warning events use get_events; for static best-practice / security-posture findings (runAsRoot, missing PDB, no probes, missing resource limits) use get_cluster_audit — a separate axis that must never be conflated (a healthy pod can have many audit findings; a crashing pod can have zero). Kyverno PolicyReport violations are not in either — they surface per-resource via get_resource's resourceContext policy rollup. After identifying a suspect issue, call diagnose when the affected resource is a workload (Pod/Deployment/StatefulSet/DaemonSet) or GitOps reconciler (Application/Kustomization/HelmRelease). For other non-workload kinds, call get_resource. Use get_neighborhood when the failure likely crosses Services/workloads/Pods/dependencies. Use namespace for app-local triage; omit it when the root may be cluster-scoped or outside the app namespace.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | comma-separated kind filter (e.g. Deployment,Pod) | |
| limit | No | max issues returned (default 200, max 1000) | |
| filter | No | optional CEL boolean expression run against each composed Issue. Bindings: severity (critical|warning), category (e.g. crashloop, image_pull_failed, missing_config_ref, gitops_sync_failed), category_group (startup|runtime|scheduling|configuration|networking|storage|scaling|security|control_plane; runtime here is an issue taxonomy group, not issue_timing), source (problem=built-in Radar detector, missing_ref=dangling by-name reference, scheduling=pod startup blocker, condition=False controller/CRD condition), kind, group, ns (the namespace — use 'ns', not 'namespace' which is a CEL reserved word), name, reason, message, cause, action, remediation_kind, remediation_target, count (int, the affected-resource fan-out), grouping_scope (workload|service|node|…), restart_count (int), last_terminated_reason, operation_retry_count (int, a GitOps controller's sync-operation retries — distinct from restart_count), stuck (bool, issue not expected to self-recover), issue_timing (string timing evidence: 'started_at_resource_creation' = evidence places the failing state during resource creation or first reconciliation; 'started_after_resource_was_healthy' = evidence shows a meaningful healthy window before the failing condition appeared; absent = Radar has no clean signal, do NOT infer timing from age alone; this is timing evidence, not a root-cause verdict), issue_timing_basis (string: evidence used — 'condition' | 'owner_condition' | 'pod_creation' | 'deletion' | 'phase' | 'spec'), first_seen + last_seen (unix seconds — prefer first_seen for onset/age; last_seen churns to compose-time). For cross-cluster scoping use clusters= (not a CEL predicate). Examples: 'severity == "critical" && count > 5', 'category_group == "startup"', 'restart_count > 10', 'remediation_kind == "create-namespace"', 'stuck && operation_retry_count >= 5', 'issue_timing == "started_after_resource_was_healthy"', 'first_seen < timestamp("2026-05-01T00:00:00Z").getSeconds()' | |
| severity | No | comma-separated: critical,warning | |
| namespace | No | filter to one namespace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite readOnlyHint, the description adds essential behavioral context: no source filter, each row carries a source label, diagnostic_context is 'triage context, not proof of root cause', and recent_changes/reason explain why it was attached. It also clarifies the separate axis of audit findings and PolicyReport violations, preventing misinterpretation. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long and dense, but every clause serves a distinct purpose, and it is front-loaded with the primary use case. It loses a point for being a large unbroken paragraph with semicolon-separated clauses, which is harder to scan than structured bullets, but there is no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no output schema, the description thoroughly covers what issues are returned, severity normalization, source categories, diagnostic_context, and the relationship to recent_changes. It also explains the broader workflow with siblings, making it complete for an agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds guidance beyond the schema: it explains the 'source' label is sliceable via the CEL filter and gives namespace usage advice ('Use namespace for app-local triage; omit it when the root may be cluster-scoped'). This enriches the meaning of the namespace and filter parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description has an explicit verb and resource: 'Returns a ranked list of currently failing resources' and clearly frames it as LIVE OPERATIONAL STATE with a specific decision trigger. It enumerates a detailed scope of failure modes and explicitly distinguishes itself from get_events and get_cluster_audit, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('what's broken right now?') vs. config posture, and names alternatives: 'For raw Kubernetes Warning events use get_events; for static best-practice / security-posture findings ... use get_cluster_audit'. It also provides post-issue routing guidance (diagnose, get_resource, get_neighborhood) and scoping advice for the namespace parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Helm releases in the cluster with their status and health. Returns release name, namespace, chart, version, status (deployed/failed/pending), and resource health (healthy/degraded/unhealthy). Use to get an overview of what's deployed via Helm before inspecting individual releases.
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | filter to a specific namespace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already establishes safety, but the description adds valuable behavioral detail about the return fields (status and health values) and the cluster-wide scope. It does not overpromise or hide any side effects, and there is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, followed by return-value details and a usage recommendation. No redundant or filler content; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional parameter, the description covers the purpose, output, and usage context. Annotations cover the read-only safety, and no output schema is needed given the explicit field list. It is fully complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (namespace) has a complete schema description with 100% coverage. The tool description adds no new semantics for the parameter beyond confirming it filters results, which is already clear from the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all Helm releases in the cluster, with specific output fields (release name, namespace, chart, version, status, health). The verb 'List' and resource 'Helm releases' are specific, and it naturally distinguishes itself from sibling tool get_helm_release which inspects individual releases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it 'to get an overview of what's deployed via Helm before inspecting individual releases,' indicating when this tool is appropriate and implying the alternative for deeper inspection. It lacks an explicit 'when not to use' statement, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Kubernetes namespaces with their status. Use to discover available namespaces before filtering other queries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety and completeness aspects. The description adds that the tool returns namespaces 'with their status' and frames it as a discovery operation, but does not disclose anything about output shape, pagination, or authorization, so it only modestly extends beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core action and result. Every word adds value: it names the resource, specifies the scope, mentions status, and gives a use case. There is no fluff or redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description covers what it does and when to use it. It might be slightly richer if it mentioned the return format, but given the tool's simplicity and the annotations, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the base score is 4. The description does not need to explain parameters, and the input schema confirms no parameters exist. No additional semantic information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and the resource (Kubernetes namespaces), and specifies the scope ('all') and included detail (status). This distinguishes it from sibling tools like list_resources or list_helm_releases, which target different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use the tool: 'Use to discover available namespaces before filtering other queries.' This provides clear context for usage, though it does not explicitly name alternatives or when not to use it, which would merit a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List installed packages (Helm releases, label-managed workloads, CRDs, Argo Applications, Flux HelmReleases + Kustomizations) with their sources, versions, and health. Each row carries a sources array (H=Helm API, L=workload labels, C=CRD registrations, A=Argo declaration, F=Flux declaration) so the caller can see WHY this package is detected; the MCP response also includes sourceLegend mapping those stable codes to readable meanings, plus a contributors array with per-source detail (each source's view of health/version, plus the GitOps controller resource identity in declarationName/declarationNamespace for sources A and F). Aggregated row-level health is worst-of contributors; row-level version is first-source-priority — read contributors to detect same-cluster disagreement. Use to answer 'what's installed?' / 'what version of cert-manager is running?' / 'are there orphaned operators?' in a single call instead of combining list_helm_releases + list_resources + manual merge. Filter by namespace, source, or chart substring. Response includes sourcesErrored listing any sources that failed (e.g. RBAC denied for Helm release secrets, Helm client not initialized, GitOps informer errors other than the controller's CRDs being absent). When this is non-empty, results are still returned but are partial — fewer rows than expected may indicate a dropped source rather than nothing installed. ArgoCD/FluxCD CRDs that are simply not installed in the cluster do NOT appear in sourcesErrored.
| Name | Required | Description | Default |
|---|---|---|---|
| chart | No | case-insensitive substring filter on chart name. | |
| source | No | limit to rows where this source contributed. Stable response codes are H (Helm API), L (workload labels), C (CRDs), A (Argo Application), F (Flux HelmRelease/Kustomization); this MCP tool also accepts verbose aliases helm, labels, crds, argocd, and fluxcd. The response includes sourceLegend so agents do not have to remember the single-letter codes. The response field sourcesErrored lists sources that failed (e.g. RBAC denied for Helm release secrets) — fewer rows than expected may mean a source dropped out, not that nothing is installed. | |
| namespace | No | limit to packages in this namespace (release-namespace match). Default: all namespaces. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint and openWorldHint, so the description carries the burden of explaining output semantics. It discloses the sources array codes, contributors array, worst-of health aggregation, first-source version priority, and sourcesErrored behavior with partial-result handling—far beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long due to the tool's complexity, but it is front-loaded with the core purpose and every subsequent sentence adds meaningful detail about output, usage, filters, or error semantics. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully explains return values (row-level fields, sources legend, contributors), aggregation rules, filter options, and failure handling. It is self-contained for an agent to use correctly without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions already present. The main description adds context around filter usage but does not significantly exceed the schema's parameter explanations; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists installed packages across multiple sources (Helm, labels, CRDs, Argo, Flux) with versions and health. It distinguishes itself from siblings like list_helm_releases and list_resources by explicitly framing this as an aggregation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('what's installed?', version lookups, orphaned operators) and names the alternative of combining list_helm_releases + list_resources. Also clarifies filtering by namespace/source/chart and explains behavior when sources fail, giving clear context for selecting this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for a jq-like namespace sweep when you know the resource kind (pods/po, deployments/deploy, services/svc, configmaps/cm, CRDs). Returns compact Kubernetes-shaped rows plus summaryContext by default (managedBy, health, issueCount) so you can compare many similar resources and pick suspects before calling get_resource. For unknown kind/name searches, use search. For broad health triage, use get_dashboard or issues first.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | resource kind to list for a broad sweep, e.g. pods/po, deployments/deploy, services/svc, configmaps/cm. Prefer this before get_resource when comparing many same-kind objects. | |
| group | No | API group when the kind is ambiguous (e.g. serving.knative.dev for Knative Service vs core Service) | |
| context | No | per-row context: default attaches summaryContext (managedBy + health + issueCount) for suspect ranking; 'none' returns bare rows | |
| namespace | No | filter to a specific namespace for app-scoped triage |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context: it returns 'compact Kubernetes-shaped rows plus summaryContext by default (managedBy, health, issueCount)' and mentions a 'context' parameter option for 'none' to get bare rows. This goes beyond the annotation by clarifying the output shape and default enrichment, though it omits details like pagination or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with a clear use case, then output shape, then alternatives. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately covers the return format (compact rows + summaryContext fields). It also provides usage boundaries. Slight gap: no mention of pagination, sorting, or error cases, but for a list tool with a moderate complexity this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 4 parameters have descriptions). The description adds nominal value by naming example kinds ('pods/po, deployments/deploy...') and mentioning the default context behavior, but the schema already captures this. Baseline 3 is appropriate since the schema carries the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('list') and resource scope ('jq-like namespace sweep' for known resource kinds like pods/deployments/services). It also distinguishes from siblings by explicitly naming get_resource as a follow-up and search for unknown kind/name searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: 'when you know the resource kind' and 'before calling get_resource' to compare many similar resources. Also gives exclusions: 'For unknown kind/name searches, use search' and 'For broad health triage, use get_dashboard or issues first.' This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform operations on a Kubernetes CronJob. Supported actions: 'trigger' creates a manual Job run from the CronJob's template, 'suspend' pauses the CronJob schedule (no new Jobs will be created), 'resume' re-enables a suspended CronJob's schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | cronjob name | |
| action | Yes | action to perform: trigger, suspend, or resume | |
| namespace | Yes | cronjob namespace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=true, and the description adds valuable behavioral context by explaining the consequences of each action: trigger creates a manual Job run, suspend pauses the schedule (no new Jobs), resume re-enables the schedule. This goes beyond the bare annotation and informs the agent of the operational impact, though it does not discuss error handling or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and then lists the supported actions with concise explanations. Every clause adds information, with no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple management tool with three parameters, no output schema, and destructiveHint annotated, the description covers the essential behavior. It explains what each action does and the impact on the CronJob. Minor gaps include lack of information on preconditions (e.g., CronJob existing) or idempotency, but overall it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema already describes each parameter, the description adds substantial meaning to the action parameter by explaining what each action does. This helps the agent understand the semantic difference between trigger, suspend, and resume beyond the enum-like schema description. Name and namespace are self-explanatory, so no further detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs operations on a Kubernetes CronJob and enumerates the exact supported actions (trigger, suspend, resume) with their effects. This distinguishes it from sibling tools like manage_workload or manage_node by specifying the resource and the precise operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when a user needs to trigger, suspend, or resume a CronJob. It clearly defines the scope of actions, but does not explicitly mention alternatives or exclusions (e.g., 'use patch_resource for other modifications'). This is clear context without explicit exclusions, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform operations on GitOps resources (ArgoCD or FluxCD). For ArgoCD: actions are 'sync' (trigger deployment), 'refresh', 'terminate', 'rollback', 'suspend' (disable auto-sync), 'resume' (re-enable auto-sync). Resource kind is always Application. For FluxCD: actions are 'reconcile' (trigger sync), 'sync-with-source', 'suspend', 'resume'. Requires 'kind' parameter (kustomization, helmrelease, gitrepository, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | resource kind (FluxCD only): kustomization, helmrelease, gitrepository, etc. | |
| name | Yes | resource name | |
| tool | Yes | gitops tool: argocd or fluxcd | |
| force | No | sync only — kubectl --force; required for some immutable-field changes. | |
| prune | No | sync/rollback — delete resources no longer in source. Default true for sync, false for rollback. | |
| action | Yes | action: sync, refresh, terminate, rollback (ArgoCD only), reconcile or sync-with-source (FluxCD), suspend, or resume | |
| dryRun | No | sync/rollback — preview only, do not apply. | |
| revision | No | sync only — branch/tag/commit. Empty = use targetRevision. | |
| applyOnly | No | sync only — skip PreSync/PostSync/SyncFail hooks. | |
| historyId | No | rollback only — history entry ID to roll back to (from get_resource Application status.history). | |
| namespace | Yes | resource namespace | |
| syncOptions | No | sync only — Argo SyncOption strings, e.g. Replace=true, ServerSideApply=true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint:true, which covers the destructive nature. The description adds semantic detail for each action (e.g., 'sync' triggers deployment, 'suspend' disables auto-sync) without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two dense sentences that pack all essential usage rules: scope, per-tool action lists, and kind requirements. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 params, multiple action sets per tool) and lack of an output schema, the description covers core decision points like which actions are valid for ArgoCD vs FluxCD and when kind is required. It could mention return values, but that is not strictly required when no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 12 parameters, but the description adds cross-cutting information: ArgoCD always uses Application kind, while FluxCD requires a kind parameter (kustomization, helmrelease, etc.). This relationship is not visible in the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Perform operations on GitOps resources (ArgoCD or FluxCD)' and enumerates action types for each tool, making it distinct from sibling management tools like manage_workload or apply_resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear scope (GitOps resources only) and differentiates actions by tool, which is sufficient context for selection. However, it does not explicitly mention alternatives or cases where another tool should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform operations on a Kubernetes node. Supported actions: 'cordon' marks the node as unschedulable (no new pods will be scheduled), 'uncordon' marks the node as schedulable again, 'drain' cordons the node and evicts all non-DaemonSet pods. Drain options: 'delete_empty_dir_data' (allow evicting pods with emptyDir volumes), 'force' (evict pods not managed by a controller), 'timeout' (seconds, default 60).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | node name | |
| force | No | force evict pods not managed by a controller (default false) | |
| action | Yes | action to perform: cordon, uncordon, or drain | |
| timeout | No | drain timeout in seconds (default 60) | |
| delete_empty_dir_data | No | evict pods with emptyDir volumes (default true, set false to skip them) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description thoroughly discloses the behavioral impact: cordon prevents new pod scheduling, drain evicts all non-DaemonSet pods, and the options (force, delete_empty_dir_data, timeout) specify edge cases. This is rich, actionable behavioral detail that annotations alone would not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and then systematically lists actions and drain options. No redundant wording; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, 3 actions), the description fully explains the tool's behavior, parameter semantics, and safety implications. No output schema is present, but the description sufficiently covers what the agent needs to invoke it correctly. Annotations complement the description rather than leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema covers 100% of parameters, the description adds significant meaning by explaining what each action does and how the drain options modify behavior (e.g., 'drain cordons the node and evicts all non-DaemonSet pods'). This goes well beyond the schema's terse property descriptions and helps the agent select correct parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Perform operations on a Kubernetes node' and enumerates the supported actions (cordon, uncordon, drain) with specific effects. This distinguishes it from sibling tools like manage_workload or patch_resource, which target different resources or generic patching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to cordon, uncordon, or drain a node) without explicitly naming alternatives or exclusions. The uniqueness of the actions makes usage clear, but it stops short of saying 'use this instead of X', so it's a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform operations on a Kubernetes workload (Deployment, StatefulSet, or DaemonSet). Supported actions: 'restart' triggers a rolling restart, 'scale' changes the replica count (requires 'replicas' parameter), 'rollback' reverts to a previous revision (requires 'revision' parameter). Use list_resources or get_dashboard first to identify the target.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | workload kind: deployment, statefulset, or daemonset | |
| name | Yes | workload name | |
| action | Yes | action to perform: restart, scale, or rollback | |
| replicas | No | target replica count (required for scale) | |
| revision | No | target revision number (required for rollback) | |
| namespace | Yes | workload namespace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=true, so the description adds action-specific behaviors: restart triggers a rolling restart, scale changes replica count, and rollback reverts to a previous revision. It also ties parameters to actions, but does not detail side effects like pod termination or revision history limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the main purpose, second enumerates actions and provides a discovery hint. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all supported operations, parameter requirements, target kinds, and the discovery step. The destructive nature is already provided by annotations. For a mutation tool with no output schema, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters (100% coverage), but the description explicitly states that 'replicas' is required for scale and 'revision' for rollback, adding conditional requirement semantics not fully captured in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies that the tool performs operations on Kubernetes workloads and enumerates the three supported actions (restart, scale, rollback), distinguishing it from sibling tools like manage_cronjob or manage_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises using list_resources or get_dashboard first to identify the target, providing a clear prerequisite. However, it does not contrast with alternative mutation tools like apply_resource or patch_resource, so no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Patch one existing Kubernetes resource with JSON Patch, JSON Merge Patch, or strategic merge patch. Use this for precise field/list mutations such as removing a bad dnsConfig, hostPort, initContainers field, sidecar container, nodeSelector, or replacing one scalar value. Prefer this over apply_resource when you know the exact field to mutate and do not want to rewrite the full manifest or take broad server-side-apply ownership. For patch_type=json, patch must be an RFC 6902 JSON Patch array. For patch_type=merge, patch must be a JSON object. For patch_type=strategic, use a JSON object against built-in Kubernetes kinds when you need name-keyed list merging, such as editing one container. By default returns compact post-patch state and dry-run preview diffs; JSON Patch calls also include per-operation field checks. Set verify=false only when you need a terse write result.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | resource kind, e.g. Deployment, Service, ConfigMap | |
| name | Yes | resource name | |
| group | No | API group when the kind is ambiguous, e.g. apps for Deployment or serving.knative.dev for Knative Service | |
| patch | Yes | JSON patch body. For patch_type=json, pass an array like [{"op":"remove","path":"/spec/template/spec/dnsConfig"}]. For merge/strategic, pass an object. | |
| verify | No | return compact post-patch state; on dry_run return a preview diff. JSON Patch calls also include field checks. Default true; set false for a terse write result. | |
| dry_run | No | validate and preview the server-side result without persisting changes | |
| namespace | No | namespace for namespaced resources; omit for cluster-scoped resources | |
| patch_type | No | json (default, RFC 6902 JSON Patch array), merge (JSON Merge Patch object), or strategic (built-in Kubernetes kinds only) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint=true, but the description enriches this by explaining default return behavior ('compact post-patch state and dry-run preview diffs'), the effect of verify=false, and that JSON Patch calls include per-operation field checks. It also details the format requirements for each patch_type, adding significant transparency beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence delivers useful information: usage context, patch type specifics, and return behavior. It is front-loaded with the core purpose, then branches into details. Slightly long, but no redundancy, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and destructive annotations, the description covers the essential decision points: when to use it, how to choose patch_type, what the patch payload should look like, and what the response contains. It also mentions verify and dry_run behavior, making it complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. However, the description adds meaning by providing concrete examples for json and merge patch types and clarifying how patch format relates to patch_type ('For patch_type=json, patch must be an RFC 6902 JSON Patch array'). This goes beyond the schema's generic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Patch one existing Kubernetes resource with JSON Patch, JSON Merge Patch, or strategic merge patch.' It clearly distinguishes itself from the sibling apply_resource by naming it and explaining when patch_resource is preferred, which goes beyond a generic statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Use this for precise field/list mutations') and when to prefer an alternative ('Prefer this over apply_resource when you know the exact field to mutate and do not want to rewrite the full manifest or take broad server-side-apply ownership'). This gives clear context and an exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find resources by content/term match when you do not know which object contains a string, config key, env ref, image, label/annotation value, ConfigMap data, CRD field, or status message. Tokens are AND'd. Secret content is intentionally NOT indexed — Secret names match by metadata, but data values won't appear in snippets to avoid leaking secret material through search results. Examples: readinessProbe user-service, image:flagd, kind:Pod label:app=cart error. Modifiers such as kind:Pod, ns:foo, label:app=bar, and image:redis narrow a term match; modifier-only queries are enumeration, so use list_resources when you already know the kind/namespace. Returns ranked hits with snippets and summaryContext. Use CEL filter for structural predicates. Searches typed kinds plus warmed CRDs; cold CRDs need list_resources first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max hits returned (default 50, max 500) | |
| query | Yes | search query for unknown resources or broad content scans. Free tokens AND'd. Matches identity plus searchable object content. Examples: adServiceFailure, kind:NetworkChaos delay, kind:ConfigMap flagd, image:flagd. Modifiers: kind:Pod, kind:NetworkChaos, ns:foo, label:k=v, image:redis | |
| filter | No | optional CEL boolean expression run against each candidate K8s object. Bindings: kind, apiVersion, metadata, spec, status, labels, annotations. Use has(x.y) before optional fields. Examples: 'kind == "Pod" && status.phase == "Failed"', 'labels["app"] == "cart"', 'has(status.readyReplicas) && status.readyReplicas == 0' | |
| context | No | per-hit context: default attaches summaryContext (managedBy + health + issueCount) for suspect ranking; 'none' returns bare hits | |
| include | No | per-hit detail: summary (default), raw, or none |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint=true annotation by disclosing security-sensitive behavior: Secret content is intentionally not indexed to avoid leaking data through snippets. It also reveals query semantics (tokens AND'd), ranking, return format (ranked hits with snippets and summaryContext), and the limitation regarding warmed CRDs. No contradiction with annotations; it enriches them substantially.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place: purpose, security caveat, examples, modifier vs. enumeration guidance, CEL recommendation, return description, and CRD limitation. It is front-loaded with the primary purpose and structured logically, with zero filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, subtle query semantics), the description is complete: it explains what is searched, what is not (Secret values), how queries combine, how to narrow results, when to use alternatives, and what the response contains. No significant behavioral caveat is left undisclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema_description_coverage is 100%, the description adds high-value semantics beyond the schema: explicit query syntax (modifiers like kind:Pod, ns:foo), AND logic, examples, and guidance for filter/context parameters. This transforms dry parameter metadata into actionable usage knowledge, exceeding the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb 'Find' and defines the resource scope as 'resources by content/term match' when the user does not know which object contains a string. It clearly distinguishes itself from siblings by explicitly routing enumeration queries to list_resources and structural predicates to CEL filters, making it unmistakable what unique role this tool serves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('when you do not know which object contains...') and when not to ('modifier-only queries are enumeration, so use list_resources', 'Use CEL filter for structural predicates'). It also provides a practical prerequisite ('cold CRDs need list_resources first'), giving clear decision guidance versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when investigating high CPU, memory pressure, OOMKills, slow services, noisy pods, or uneven node load. Returns live metrics ranked like kubectl top pods|nodes | sort, joined with Kubernetes context: pod status, readiness, restarts, owner workload, requests, and limits. kind=pods ranks individual Pods, kind=workloads aggregates Pods to Deployments/StatefulSets/DaemonSets/Jobs, and kind=nodes ranks Nodes. Use before reading logs when the symptom mentions CPU, memory, GC, OOM, latency, or load.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | what to rank: pods (default), workloads, or nodes | |
| sort | No | sort by cpu (default) or memory | |
| limit | No | max rows returned, default 20, max 100 | |
| namespace | No | filter pods/workloads to a namespace. Required for namespace-restricted users unless they have cluster-wide namespace access. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: it returns live metrics, joins with Kubernetes context, and explains that kind=workloads aggregates Pods from Deployments/StatefulSets/DaemonSets/Jobs. It does not contradict annotations, and while it omits rate limits or auth, the read-only nature is well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the most critical usage guidance. Sentences are compact and information-dense; every clause earns its place, covering when to use, what it returns, and how the kind parameter behaves, without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description adequately explains the return shape (ranked metrics with pod status, readiness, restarts, owner workload, requests, limits). It also covers all kind variants and parameter behavior, making it complete for an agent to select and invoke the tool successfully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, establishing a strong baseline. The description adds further semantic value by explaining how 'kind=workloads' aggregates Pods to specific workload types, which is not fully captured in the parameter description. This goes beyond the schema's basic field definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Returns live metrics ranked like kubectl top pods|nodes | sort' and explicitly differentiates from siblings by positioning it as a pre-log investigation tool. It clearly defines the three kind variants, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description opens with explicit use cases ('Use when investigating high CPU, memory pressure, OOMKills, slow services, noisy pods, or uneven node load') and provides an alternative guidance ('Use before reading logs when the symptom mentions CPU, memory, GC, OOM, latency, or load'). This tells the agent when to choose this tool over log-focused siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct concern: get_dashboard and issues for triage, diagnose for deep root-cause, get_pod_logs vs get_workload_logs for log scope, search for content lookup, and manage_* for explicit actions. Even where overlap exists (e.g., diagnose bundles get_resource+events+logs), the descriptions explicitly tell the agent which to use and when, eliminating ambiguity.
The majority follow a clear verb_noun pattern: get_* for reads, list_* for enumeration, manage_* for actions, apply_resource/patch_resource for writes. Minor deviations like 'issues' and 'diagnose' act as situational verbs (state analysis) and are still distinct and readable, so the set remains predictable overall.
25 tools is at the heavy end of the recommended range, but the breadth is justified for a Kubernetes diagnostics platform covering reads, writes, logs, metrics, events, RBAC, Helm, GitOps, and topology. Each tool serves a unique purpose with no gratuitous duplication, so the count is appropriate for the domain's complexity.
The surface covers discovery (list_*, search), troubleshooting (issues, diagnose, logs, events, metrics), management (apply/patch, manage_*), and specialized views (topology, neighborhood, RBAC, GitOps). The most notable gap is the absence of a delete resource tool, but the read/manage/act coverage is strong enough that agents won't hit dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The Google GKE MCP server is a managed Model Context Protocol server that provides AI applications with tools to manage Google Kubernetes Engine (GKE) clusters and Kubernetes resources. It exposes a structured, discoverable interface that allows AI agents to interact with GKE and Kubernetes APIs, enabling them to inspect cluster configurations, retrieve Kubernetes resource YAMLs, monitor operations like cluster upgrades, diagnose issues, and optimize costs—all without needing to parse text output or use complex kubectl commands.
MCP observability. Query live traffic, errors, duration, and alerts from your AI agent.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/skyhook-io/radar'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
