Kubeview README

KubeView 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:

const pods = await tools.kubernetes.list({ namespace: 'payments' });
const unhealthy = pods.items.filter((p) => p.status?.phase !== 'Running');

return Promise.all(
  unhealthy.map(async (pod) => ({
    pod: pod.metadata?.name,
    logs: await tools.kubernetes.logs({
      namespace: 'payments',
      podName: pod.metadata?.name,
      tailLines: 100,
    }),
  })),
);

• Sensitive isolation — kube_pod_exec is 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_forward is 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 helm binary is a fallback, not a prerequisite.

Quick start

Prerequisites: Node.js ≥ 22 and access to a cluster (KUBECONFIG or in-cluster service account).

npx -y kubeview-mcp

# Claude Code
claude mcp add kubernetes -- npx kubeview-mcp

{
  "mcpServers": {
    "kubeview": {
      "command": "npx",
      "args": ["-y", "kubeview-mcp"]
    }
  }
}

In Cursor, /kubeview/code-mode injects the typed API into context.

Configuration

Cluster

Mode and capabilities

HTTP transport

mkdir -p /tmp/kubeview-mcp-approvals
MCP_APPROVAL_STATE_SECRET='replace-with-at-least-32-random-bytes' \
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

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 | debug
• argo — list | get | logs | cron_list (when Workflow or CronWorkflow is discoverable)
• argocd — list | get | resources | logs | history | status (when Application is discoverable, or with ARGOCD_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.

MCP_KUBE_CONTEXT=dev \
MCP_KUBE_CONTEXTS='dev,staging-*,prod=arn:aws:eks:eu-west-1:123456789012:cluster/prod' \
npx -y kubeview-mcp

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:

const staging = tools.withContext('staging-eu');
const [stagingApi, prodApi] = await Promise.all([
  staging.kubernetes.diagnose({ resourceType: 'deployment', name: 'api', namespace: 'shop' }),
  tools.kubernetes.diagnose({ resourceType: 'deployment', name: 'api', namespace: 'shop', context: 'prod' }),
]);
return { staging: stagingApi.summary, prod: prodApi.summary };

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 tools namespaces 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(), and tools.disabled() (the last reports why a capability was blocked).
• Multi-cluster access: tools.kubernetes.contexts(), tools.withContext(name), and per-call context arguments (see Multiple clusters).
• A locked-down runtime with only console and tools in scope — no filesystem, no network, no process.

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:

return await tools.kubernetes.diagnose({
  resourceType: 'deployment',
  name: 'payments-api',
  namespace: 'payments',
  includeLogs: true,
});

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:

npm run command -- kube_diagnose --name monitor-eks-aid-847484f765-4hwzz

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:

1. MCP_CODE_MODE_DISABLED_TOOLS env var
2. disabledTools in kube-mcp.code-mode.json
3. 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 structuredContent with text fallback
• Accurate read-only, destructive, idempotent, open-world annotations
• 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

git clone https://github.com/mikhae1/kubeview-mcp.git
cd kubeview-mcp && npm install

npm run build      # compile
npm start          # build + run
npm test           # jest suite
npm run typecheck  # tsc --noEmit

# Invoke a tool directly
npm run command -- kube_list --namespace=default

Protocol tests pin the SDK v2 client to 2026-07-28 and route through the server handler in-process (no open ports):

npm test -- --runInBand \
  tests/server/StreamableHttpTransport.integration.test.ts \
  tests/server/StreamableHttpRuntime.test.ts \
  tests/server/TransportConfig.test.ts \
  tests/compat/McpSdkCompatibility.test.ts

Contributing

Contributions are welcome! Please feel free to submit an issue or a pull request.

License

MIT © mikhae1