
Kubeview
io.github.mikhae1Published by GitHub account mikhae1v2.3.0Updated Oct 25, 2026
Read-only Model Context Protocol MCP server enabling code-driven AI analysis of Kubernetes clusters.
Overview
A read-only MCP server that lets an assistant run sandboxed TypeScript to inspect Kubernetes clusters, Helm releases, Argo Workflows and Argo CD, returning only
- What you can do
- Run sandboxed TypeScript against a typed tools API to query clusters and return only the final answer, keeping intermediate payloads out of context (run_code).
- When to use it
- Useful when an assistant needs to diagnose Kubernetes workloads, correlate events, logs and Helm state, or compare several clusters without flooding its context with raw API payloads. Suited to read-only troubleshooting rather than cluster changes.
- Requirements
- Runs locally over stdio via npx; needs Node.js 22 or newer and cluster access through KUBECONFIG or an in-cluster service account. Optional HTTP mode needs MCP_TRANSPORT, host and port settings, and MCP_APPROVAL_STATE_SECRET plus MCP_APPROVAL_REPLAY_DIR.
Installation
In SourceWeft
- Open Kubeview in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
KubeView MCP
[npm version] [License: MIT] [Node.js] [MCP]
Read-only Model Context Protocol server for Kubernetes diagnostics. Instead of exposing dozens of tools, it gives the agent a sandboxed TypeScript runtime: a single run_code call can query Kubernetes, Helm, Argo Workflows, and Argo CD, correlate the results, and return only the answer. Intermediate payloads never pass through the model's context window. Based on the code execution with MCP pattern.
Background: Evicting MCP tool calls from your Kubernetes cluster
How it works
v2 publishes exactly two public tools: run_code and an approval-gated kube_pod_exec. Everything else is discovered inside the sandbox via tools.list(), tools.search(), and tools.help(), following the MCP progressive discovery and programmatic calling guidance.
run_code executes bounded TypeScript with top-level await. One call can list workloads, correlate events, fetch logs, and diff Helm state without shipping intermediate payloads back through the model:
- Sensitive isolation —
kube_pod_execis unreachable from sandboxed code. Top-level exec requires MCP elicitation, is bound to the argument digest, expires after 10 minutes, and fails closed.kube_port_forwardis never a top-level tool and is denied inside code mode by default.tools.disabled()reports which policy blocked a capability and whether that denial is configurable. - API-driven discovery — Argo Workflows and Argo CD are detected from the Kubernetes API, scoped to the active kube context, cached for 60 s. An unavailable optional API never blocks startup.
- Native reads — resources, metrics, logs, events, and network probes go through the Kubernetes API. Helm releases are parsed from cluster Secrets or ConfigMaps; a local
helmbinary is a fallback, not a prerequisite.
Quick start
Prerequisites: Node.js ≥ 22 and access to a cluster (KUBECONFIG or in-cluster service account).
In Cursor, /kubeview/code-mode injects the typed API into context.
Configuration
Cluster
Mode and capabilities
HTTP transport
Endpoint: http://127.0.0.1:3000/mcp. HTTP follows the MCP 2026-07-28 stateless core: a fresh server per request, no initialize, no Mcp-Session-Id. Each request carries protocol version, client identity, and capabilities in _meta; modern requests add Mcp-Method/Mcp-Name for gateway routing. 2025-era clients use the SDK's stateless fallback on the same endpoint. State that must survive across calls has to be passed as tool arguments or handles.
HTTP mode refuses to start without both approval variables. Multi-replica deployments need the same secret and a shared writable replay directory; the /tmp example is for a single process only. The published MCP registry entry still targets stdio.
Tool surfaces
Domain tools use an operation discriminator:
helm—list|get|debugargo—list|get|logs|cron_list(whenWorkfloworCronWorkflowis discoverable)argocd—list|get|resources|logs|history|status(whenApplicationis discoverable, or withARGOCD_SERVER+ARGOCD_AUTH_TOKEN)
Discovery is cached per kube context for 60 s. Missing optional APIs are omitted, not fatal. argo and argocd are registered when the API exists in the default context or in any exact context name listed in MCP_KUBE_CONTEXTS.
Multiple clusters
Every cluster tool accepts an optional context argument (a kubeconfig context name or an MCP_KUBE_CONTEXTS alias); kube_contexts lists the contexts you can target. Without it, calls behave as before: MCP_KUBE_CONTEXT, then the kubeconfig current-context. Context is per call rather than per session, which keeps HTTP mode stateless and lets one script query several clusters concurrently.
MCP_KUBE_CONTEXTS is a comma-separated list. Plain entries are context names with optional * wildcards; alias=context entries map a short name to a real context. Once set, only matching contexts, alias targets, and MCP_KUBE_CONTEXT are reachable, including for Helm/Argo/Argo CD CLI fallbacks, which receive --kube-context/--context for the resolved context. Add * to keep every context while defining aliases.
In run_code, set a default for the whole script with the context argument, or scope it with tools.withContext(); a per-call context always wins:
kube_pod_exec resolves the context before asking for approval; the approval prompt names it, and the approval is bound to it.
Code mode
Code mode is the default (MCP_MODE=code). The agent writes short TypeScript against a typed tools global instead of calling dozens of MCP tools.
Inside run_code:
- Typed
toolsnamespaces for Kubernetes, Helm, and any detected Argo capabilities, generated from live schemas so parameters cannot be hallucinated. - Progressive discovery:
tools.list(),tools.search(),tools.help(), andtools.disabled()(the last reports why a capability was blocked). - Multi-cluster access:
tools.kubernetes.contexts(),tools.withContext(name), and per-callcontextarguments (see Multiple clusters). - A locked-down runtime with only
consoleandtoolsin scope — no filesystem, no network, noprocess.
Pod exec approval uses MCP elicitation and fails closed. The standalone npm run code-mode launcher has no trusted approval UI, so it always denies pod exec.
Workload diagnosis
Diagnose Pods, Deployments, StatefulSets, DaemonSets, ReplicaSets, Jobs, and CronJobs in one code-mode call:
Resource types default to pod and accept case-insensitive singular or plural names. Namespace defaults to the current context, then default. Diagnosis follows controller ownership by UID and correlates status, events, required configuration keys, image-pull Secrets, PVCs, and failing-container logs. Configuration and Secret values are never returned. Log and event text honor MCP_HIDE_SENSITIVE.
To diagnose a Pod from the CLI:
For controllers, add --resourceType deployment (or another supported type). Add --namespace when the workload is outside the current namespace.
Results contain target, context, observedAt, health, summary, findings, evidence, and coverage. Findings reference evidence and distinguish historical failures from current problems; possible causes are separate from observed facts. Missing optional configuration is expected. Forbidden, unavailable, or missing required reads remain visible in coverage.errors; truncation and skipped reads appear in coverage.truncations. Health is healthy, degraded, or unknown; a confirmed failure can be reported even when collection is incomplete.
Customizing denials
MCP_CODE_MODE_DISABLED_TOOLS (comma-separated) controls which capabilities are blocked inside run_code. Resolution order:
MCP_CODE_MODE_DISABLED_TOOLSenv vardisabledToolsinkube-mcp.code-mode.json- Default:
["kube_port_forward"]
An empty env value clears the list. kube_pod_exec cannot be added — it is permanently blocked.
Protocol
MCP 2026-07-28:
- JSON Schema 2020-12 in/out contracts with server-side validation
- Machine-readable
structuredContentwith text fallback - Accurate
read-only,destructive,idempotent,open-worldannotations - Deterministic tool ordering with cache hints for fixed vs. discovery-dependent surfaces
- Stateless HTTP with discovery and header-based routing (
Mcp-Method,Mcp-Name) - Execution failures returned as tool errors; protocol errors reserved for malformed requests
Local development
Protocol tests pin the SDK v2 client to 2026-07-28 and route through the server handler in-process (no open ports):
Contributing
Contributions are welcome! Please feel free to submit an issue or a pull request.
License
MIT © mikhae1
Source: README.md at commit dc99d8f
Tools
0Version history
4- v2.3.0LatestOct 17, 2026
- v2.2.0Oct 10, 2026
- v2.0.2Sep 28, 2026
- v2.0.1Sep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts
