Code inside the runtime sees only a console and the typed tools object — no filesystem, no network, no process — and the ability to run a command in a container is never exposed to it at all; at the top level that call asks the user each time, is bound to the exact arguments, and fails closed. The design bet everywhere else is on how much arrives per call: metrics come back with detected problems already flagged, a log tail merges Kubernetes events in, and the Helm debug view reconciles the stored release against live state instead of leaving you to compare them.
A diagnostics surface for a Kubernetes cluster and the tooling layered on it. By default the agent gets a sandboxed TypeScript runtime and discovers the cluster operations inside it, so a multi-step investigation runs in one pass instead of a dozen round trips; setting the mode to tools exposes the operations as ordinary MCP tools instead.
- run_code executes bounded TypeScript with top-level await against a typed tools global, so one call can list workloads, correlate events, fetch logs and diff Helm state without shipping the intermediate payloads back through the model.
- Resource reads: kube_list covers pods, services, deployments, nodes, RBAC objects, replicasets, statefulsets, daemonsets, jobs, cronjobs, hpa, pdb, endpoints, quotas and more, narrowed by label and field selectors; kube_get reads any resource including CRDs, close to kubectl describe, with events and diagnostics attached.
- kube_metrics returns node and pod CPU and memory in one shot with a summary and detected problems, scoped by namespace and optionally enriched from Prometheus.
- Logs at either scale: kube_logs pulls one pod container with container, tail, timestamps, previous instance and a since window; kube_log tails across pods discovered by name, label selector or owner, merging Kubernetes events into the stream.
- kube_net runs DNS resolution, internet egress and pod- and service-connectivity checks from a source pod, and kube_port opens a time-boxed port-forward for local probing.
- Helm state without a shell: releases are parsed from cluster Secrets or ConfigMaps, so helm_list, helm_get (values, manifest, notes, hooks, resources, status, history) and helm_debug work whether or not a helm binary is installed.
- Argo Workflows and Argo CD are detected from the Kubernetes API and appear only when they are there: argo_list, argo_get, argo_logs and argo_cron_list, plus argocd_app for list, get, resources, logs, history and status.
- Executing a command inside a container is kept apart from everything else — unreachable from sandboxed code, and at the top level it needs per-call approval bound to the arguments, expiring after 10 minutes.
Node.js 22 or newer and access to a cluster — a kubeconfig, or an in-cluster service account. Resources, metrics, logs, events and network probes go through the Kubernetes API directly, so kubectl is not needed. Over HTTP there are two more: the server refuses to start without a signing secret of at least 32 bytes and a writable directory for one-time approvals, shared by every replica.
One command — npx -y kubeview-mcp