This is a read-only MCP server for Kubernetes diagnostics that lets an agent run sandboxed TypeScript against live cluster capabilities, with a single high-risk pod-exec tool gated behind per-call user approval.
run_code: execute bounded TypeScript (top-level await) in a locked-down sandbox with only console and a typed tools global; no filesystem, network, or process.
Progressive discovery inside run_code: tools.list(), tools.search(), tools.help(), and tools.disabled() to explore Kubernetes, Helm, Argo, and Argo CD capabilities generated from live schemas.
Typed tools namespaces cover Kubernetes reads (list/get/logs), Helm (list/get/debug), and detected Argo/Argo CD operations (list/get/logs/cron/resources/history/status).
kube_pod_exec: execute a command in a pod container (no kubectl), capturing stdout/stderr; requires per-call user approval (10-minute, argument-bound) and fails closed; can use argv, args[], or a shell command, plus optional stdin, TTY, container, namespace, and timeout.
Read-only, idempotent, non-destructive behavior for run_code; kube_pod_exec is marked destructive and open-world.
Supports MCP 2026-07-28 protocol with JSON Schema 2020-12 validation, structured content with text fallback, and accurate annotations.
Denial configuration: MCP_CODE_MODE_DISABLED_TOOLS (default blocks kube_port_forward, which is never exposed top-level; kube_pod_exec is permanently blocked inside run_code).
Enables management of Argo Workflows and Argo CD applications, including listing and inspecting workflows and applications via the Kubernetes API or CLI.
Allows inspection of Helm releases, including values, manifests, notes, hooks, status, and history, primarily via the Kubernetes API with CLI fallback.
Provides read-only tools to inspect, diagnose, and debug Kubernetes clusters, including listing/getting resources, fetching metrics, streaming logs and events, executing commands in containers, port-forwarding, and network diagnostics.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@kubeview-mcp show me all pods in the default namespace"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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
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.
Related MCP server: Kubernetes Tools MCP Server
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.
Variable | Description | Default |
| Kubeconfig path |
|
| Kubernetes context; defaults to the active context | unset |
| Skip TLS verification for the Kubernetes API ( |
|
| Default operation timeout in ms | plugin default |
| Mask sensitive data globally |
|
| Disable the Kubernetes plugin ( | unset |
| Disable the Helm plugin ( | unset |
Variable | Description | Default |
|
|
|
| Comma-separated code-mode denials; empty enables all | JSON/default |
| Argo override: |
|
| Argo CD override: |
|
|
|
|
| Force | unset |
Variable | Description | Default |
|
|
|
| HTTP bind (when |
|
| Streamable HTTP endpoint path |
|
| Prefer JSON over SSE (drops mid-call notifications) |
|
| Host allowlist (required when binding to | local defaults |
| Origin allowlist for HTTP | unset |
| Shared 32+ byte signing secret; required for HTTP approvals | ephemeral (stdio) |
| Absolute shared-volume directory for one-time HTTP approvals | unset |
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-mcpEndpoint: 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.
| Exposed tools |
unset / |
|
|
|
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.
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).
A locked-down runtime with only console and tools in scope — no filesystem, no network, no process.
Capability | Inside | Top-level tool |
| Never available | Requires per-call user approval (10 min, argument-bound) |
| Denied by default (configurable) | Never exposed |
Everything else | Available | Only when |
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.
MCP_CODE_MODE_DISABLED_TOOLS (comma-separated) controls which capabilities are blocked inside run_code. Resolution order:
MCP_CODE_MODE_DISABLED_TOOLS env var
disabledTools in kube-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.
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
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=defaultProtocol 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.tsContributions are welcome! Please feel free to submit an issue or a pull request.
MIT © mikhae1
Execute a command in a container of a pod via the Kubernetes API (no kubectl). Captures stdout/stderr and returns them when the command completes.
| Name | Required | Description | Default |
|---|---|---|---|
| tty | No | Allocate a TTY (default false) | |
| args | No | Exact argv to execute without a shell, e.g., ["/bin/ls","-la"]. Provide this OR command. | |
| argv | No | Whitespace-separated argv to execute without a shell (e.g., "/usr/bin/env printenv"). Convenience for CLI; prefer args[] when possible. | |
| shell | No | Shell binary used when command is provided (default /bin/sh) | |
| stdin | No | Optional data to write to process stdin before closing it | |
| command | No | Shell command to run. Defaults to trying /bin/bash first, then /bin/sh, then other common shells. Provide this OR args[]. | |
| podName | Yes | Name of the target Pod | |
| container | No | Container name (optional; defaults to first container) | |
| namespace | No | Kubernetes namespace (defaults to "default") | |
| timeoutSeconds | No | Maximum time to wait for command completion (default 60s) |
| Name | Required | Description |
|---|---|---|
| status | No | |
| stderr | Yes | |
| stdout | Yes | |
| command | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose mutation (readOnlyHint=false) and destructiveness (destructiveHint=true). The description adds meaningful behavioral context by stating that stdout/stderr are captured and returned only when the command completes, which implies blocking behavior and output aggregation. This goes beyond the structured annotations without contradicting them.
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 concise sentences that front-load the core action ('Execute a command in a container of a pod') and immediately add the key behavioral detail about output capture. Every word earns its place, with 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 complexity (10 parameters, a oneOf construct, output schema, and annotations covering safety), the description covers the essential context: what it does and how it returns output. It could add more usage differentiation vs. run_code, but the clear title and schema make it adequate for an annotated 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?
The input schema has 100% description coverage, detailing all 10 parameters including the oneOf alternatives for args/argv/command. The description itself contributes no parameter-specific information, but the schema fully explains semantics, so the baseline 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 explicitly states the tool executes a command in a pod container via the Kubernetes API, with the phrase 'no kubectl' distinguishing it from a kubectl-based approach. It clearly identifies the verb (execute), resource (pod container), and method, and further notes output capture, providing a complete 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 implies usage for Kubernetes pod execution via the Kubernetes API, but it does not explicitly compare to the sibling tool run_code or offer when/when-not guidance. The 'no kubectl' designation provides a minor usage hint but is not a clear alternative comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute bounded TypeScript with top-level await against progressively discovered Kubernetes capabilities. Use tools.list(), tools.search(), tools.help(), and typed namespaces; inspect tools.disabled() for policy denials. Return a value from the script. Full documentation and types are available through the code-mode prompt and file:///sys/global.d.ts.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | TypeScript code to execute via the sandboxed runtime. Top-level await is supported. | |
| input | No | Optional input payload available to the script. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| result | No | |
| stderr | No | |
| stdout | No | |
| isError | No | |
| success | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations, such as 'bounded' execution, top-level await, 'progressively discovered' capabilities, and the ability to inspect tools.disabled() for policy denials. It does not contradict the readOnly, non-destructive, idempotent hints, and it enhances understanding of the sandboxed runtime.
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 three sentences, front-loaded with the core purpose in the first sentence. Every sentence earns its place: the second explains how to interact with the environment, and the third points to additional documentation. There is no redundancy or 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?
Given the tool's complexity (arbitrary code execution in Kubernetes) and the presence of an output schema, the description is quite complete. It covers the execution model, discovery mechanism, policy-denial introspection, and where to find full docs. It does not explicitly address when to prefer this over kube_pod_exec, but the different purposes are implicit. Overall, it is sufficient for an agent to 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% for the two parameters, so the baseline is 3. The description adds minor clarification (e.g., 'Return a value from the script' implies the code parameter should produce a return value), but it largely repeats what the schema already states (TypeScript code, top-level await support). It does not add substantial parameter-level semantics beyond 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 states the tool executes bounded TypeScript with top-level await against Kubernetes capabilities, using a specific verb ('Execute') and resource ('bounded TypeScript'). It distinguishes itself from the sibling tool kube_pod_exec by focusing on analysis code rather than command execution in pods.
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 guidance on how to use the tool: use tools.list(), tools.search(), tools.help(), and typed namespaces, and inspect tools.disabled() for policy denials. It implies this is the tool for exploring and analyzing Kubernetes capabilities, but does not explicitly compare it to the sibling or state when not to use it, so it falls short of a full when/when-not guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.0.0kube_pod_execrun_codeScored across 2 tools
run_code and kube_pod_exec have clearly distinct purposes: one executes TypeScript scripts against Kubernetes APIs, the other runs commands inside pod containers. There is no functional overlap, so agents should not confuse them.
Both names follow a verb_noun pattern, but their styles diverge: run_code uses a bare verb and object, while kube_pod_exec uses a kube_ prefix and a more specific compound noun. This inconsistency is minor but noticeable.
With only two tools, the server is on the thin side. However, one tool is a flexible code-execution interface, so the count might be acceptable for a narrow, specialized scope.
The server is named kubeview, yet there are no viewing or resource-list tools. run_code can potentially interact with Kubernetes capabilities, but it does not provide a direct, discoverable surface for typical read operations, leaving significant gaps for a toolset claiming to be a Kubernetes viewer.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
Provides read access to your GKE and Kubernetes resources.
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mikhae1/kubeview-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
