run_codeLABSCO SUMMARY
The dangerous capability is the one thing the sandbox cannot reach.
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.
What it is
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.
What you get
- 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.
- Node and pod metrics, events and network probes are read through the Kubernetes API, reached from inside run_code rather than as tools of their own.
- Container logs through kube_logs — a tool of its own when MCP_MODE is tools, and called from run_code otherwise, where one pass can pull the last hundred lines of every unhealthy pod.
- Port-forwarding (kube_port_forward) is never a top-level tool and is denied inside run_code by default; MCP_CODE_MODE_DISABLED_TOOLS is the setting that allows it.
- Helm state without a shell: releases are parsed from cluster Secrets or ConfigMaps, and the helm tool's list, get and debug operations 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 takes list, get, logs and cron_list, and argocd takes 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.
Requirements
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.
Setup effort
One command — npx -y kubeview-mcp
USE CASES
01
Working out why a pod keeps restarting
Start from the metrics that flagged it, read the resource with its events, then go to the container's own output.
02
Chasing one failure across every pod behind a deployment
Tail the whole workload at once by owner or label rather than pod by pod, with Kubernetes events merged into the same stream.
03
Proving whether a service is actually reachable from inside the cluster
Run the network probes through run_code from a pod that sits where the traffic does. Port-forwarding stays off unless you remove kube_port_forward from MCP_CODE_MODE_DISABLED_TOOLS.
04
Finding out what a Helm release actually put on the cluster
Read the values and manifest it was rendered from, then let the debug view line that up against what is running and which events warned.
05
Catching up on a pipeline that failed overnight
Filter workflows by status, open the one that failed, and pull its pod logs — with the scheduled cron workflows listed beside them.
06
Checking whether the cluster matches what Argo CD thinks it deployed
Read the application's status, its resources and its history in one place instead of clicking through the dashboard.
07
Answering a question no single call covers
Write the few lines of TypeScript that filter, correlate and join — for example every non-running pod in a namespace with its last hundred log lines — and get one answer back.
8 tools
Listed in project docs. Your client may show a different list.
kube_pod_execkube_listkube_getkube_logshelmargoargocdBEFORE YOU INSTALL
What to know first
Tools you get
8 tools named in the project's documentation. By default (MCP_MODE unset, code or all) only run_code and kube_pod_exec are exposed, with other tools reached inside run_code. MCP_MODE=tools exposes kube_list, kube_get, kube_logs, helm and kube_pod_exec, plus argo and argocd when the cluster has them.
Requires
npx on PATH
INSTALLATION
Connect your client
Server setup
TERMINAL
npx -y kubeview-mcpMCP Clients
Claude Code
CLAUDE CODE · TERMINAL
claude mcp add kubernetes -- npx kubeview-mcpCursor — stdio, Any MCP client — stdio
JSON
{
"mcpServers": {
"kubeview": {
"command": "npx",
"args": [
"-y",
"kubeview-mcp"
]
}
}
}HTTP server
HTTP SERVER · TERMINAL
mkdir -p /tmp/kubeview-mcp-approvals
MCP_APPROVAL_STATE_SECRET='<YOUR_MCP_APPROVAL_STATE_SECRET>' \
MCP_APPROVAL_REPLAY_DIR=/tmp/kubeview-mcp-approvals \
MCP_TRANSPORT=http MCP_HTTP_HOST=127.0.0.1 MCP_HTTP_PORT=3000 npx -y kubeview-mcp
