Originally published at heycc.cn. This is a mirrored copy — the canonical version is kept up to date at the source.

kubernetes-mcp-server: Letting an AI Agent Run kubectl, Helm, and Tekton Through MCP — Safely

Handing an AI coding agent shell access to kubectl is a common but sloppy pattern: the agent shells out, parses text output, and every safety control lives in prompt instructions the model can ignore or misread. containers/kubernetes-mcp-server takes a different approach. It is a Go-native MCP server that talks to the Kubernetes API directly through client-go, exposes cluster operations as typed MCP tools, and pushes access control down to the transport and RBAC layers instead of relying on the model to behave. That distinction — enforcement in the server and the cluster, not in the prompt — is the entire reason this project is worth understanding before you connect it to anything that matters.

This piece covers three things in depth: how the server is actually built (transport, toolsets, tool-to-API mapping), what it can do across seven toolsets including some surprising ones (KubeVirt, Kiali, Tekton), and the specific flags and config blocks you need to turn on before pointing it at a production cluster — including a default-configuration claim that the project's own docs get wrong in one place and right in another, which is exactly the kind of detail that bites people on pre-1.0 tools.

Why "Go-native, direct API access" is an architectural choice, not a marketing line

Most early Kubernetes-plus-AI integrations worked by giving the model a sandboxed shell and letting it run kubectl as a subprocess. That approach inherits every problem of shelling out: you need kubectl and helm binaries installed and on PATH, you need a working kubeconfig context on disk, and — most importantly — you get free-text output that the model has to re-parse, which is both token-expensive and error-prone (a wrapped table column reads differently than a JSON field).

kubernetes-mcp-server is described as "a powerful and flexible Kubernetes Model Context Protocol (MCP) server implementation," built as a Go binary that interacts directly with the Kubernetes API server rather than wrapping the kubectl or helm CLIs. Concretely this means:

• No kubectl/helm binaries need to exist on the host running the MCP server — it links client-go (and the Helm SDK for the helm toolset) directly.
• Tool inputs and outputs are structured, not scraped from CLI stdout. As of release v0.0.63, this got stricter: PR #… (refactor(kubernetes)!: return separate stdout and stderr from PodsExec) changed pods_exec to return stdout and stderr as separate fields instead of one merged blob — a breaking change specifically because merged-stream text was ambiguous for the model to parse, which is a small but telling data point for why "structured over scraped" keeps paying off even after the initial design is done.
• The server can run as a single static binary, in a container, or via npx kubernetes-mcp-server@latest, with no external dependency chain to break.

It ships two transport modes. The default is stdio — standard MCP over stdin/stdout, the mode every MCP-aware coding agent (Claude Code, Claude Desktop, etc.) speaks natively when launching the server as a subprocess. The second is Streamable HTTP/SSE, turned on with --port, which exposes a /mcp endpoint (the current streamable-HTTP MCP transport) and a legacy /sse endpoint for older clients. HTTP mode is what you need for a shared, remote deployment that multiple agents or teammates connect to instead of everyone running a local subprocess — and it's also the mode where OAuth/OIDC and TLS controls actually apply.

The toolsets architecture: not one giant tool surface

Rather than exposing every possible Kubernetes/Helm/Tekton/Istio operation as one flat list, the server organizes tools into seven toolsets, turned on via a comma-separated --toolsets CLI flag or a TOML toolsets = [...] array. This matters operationally: an agent connected with only core and config enabled has zero ability to touch Helm releases or Tekton pipelines even if it tries — the tools simply don't exist in its MCP tool list. That's a stronger boundary than "please don't touch Helm" in a system prompt.

The seven toolsets, with defaults as actually shipped in the current default configuration:

Toolset	Purpose	Enabled by default
core	Generic CRUD across any Kubernetes/OpenShift resource type	Yes
config	kubeconfig/context introspection (read-only, no cluster calls)	Yes
helm	Install/list/uninstall Helm releases	No
tekton	Start/restart Tekton Pipelines and Tasks, fetch logs	No
kiali	Istio service-mesh topology, traffic, tracing, config validation	No
kubevirt	KubeVirt VM lifecycle (create, clone, guest info, start/stop)	No
kcp	kcp workspace-based multi-tenancy listing/describe	No

Source: kubernetes-mcp-server configuration reference, toolset-availability table — the human-readable table checkmarks only config and core under "Default."

A correction worth dwelling on, because it's a live example of exactly the kind of drift a pre-1.0 project accumulates. The same configuration doc page has a second table — the CLI/TOML parameter reference — that still lists the default as ["core", "config", "helm"]. That line is stale. Release v0.0.59 (merged 2026-03-03) shipped PR #826, "fix(config): remove helm toolset from default enabled toolsets" — the maintainers explicitly treated helm-on-by-default as a bug and fixed it. The human-readable table reflects the fix; the parameter-reference row a few hundred lines down the same page does not. If you only skim one of the two tables, you can walk away with the wrong model of what a fresh install can do. As of the current release (v0.0.63, published 2026-06-23), the default --toolsets value is config,core — a strictly read/introspection-only surface, with no mutating toolset enabled out of the box.

The practical upshot: the safety story here is actually better than a stale doc line suggests, not worse — a fresh, un-flagged install cannot install or uninstall Helm releases. But you should not take that as license to skip --read-only. core's default tool list still includes pods_exec, pods_run, resources_create_or_update, resources_delete, and resources_scale — none of those are Helm, but all of them mutate cluster state or execute code, and all ship enabled by default under core. "Default toolsets exclude helm" is not the same claim as "default install is read-only." It isn't — see the Gotchas section below for the corrected version of that claim.

What's actually in each toolset

core — this is the generic-resource workhorse, and it's the toolset that makes the "no kubectl wrapper" claim concrete. It doesn't hardcode tools per resource kind (no deployments_list, services_get, etc.); instead it exposes generic verbs that take a GVK (group/version/kind) as a parameter:

pods_list, pods_list_in_namespace, pods_get, pods_delete, pods_top, pods_exec, pods_log, pods_run, resources_list, resources_get, resources_create_or_update, resources_delete, resources_scale, events_list, namespaces_list, nodes_log, nodes_stats_summary, nodes_top, projects_list.

The resources_* family is the important one: resources_list/resources_get/resources_create_or_update/resources_delete/resources_scale operate against arbitrary CRDs and built-in types alike, which is how one Go binary supports "CRUD on any resource" without a tool-per-kind explosion. pods_exec and pods_run are the two tools worth flagging early, since they're the most direct path from "read a pod" to "execute arbitrary code in the cluster" — see the safety section below. Both ship enabled in the default core toolset; there is no flag that disables just these two without also disabling all of core's other read tools, which is precisely why --read-only (a mode, not a toolset toggle) exists as a separate control.

config — configuration_contexts_list, targets_list, configuration_view. Pure introspection of the kubeconfig the server is using; no cluster mutation, useful for letting an agent confirm which cluster/context it's about to operate against before running anything destructive.

helm — helm_install, helm_list, helm_uninstall: install a chart with value overrides, list releases across namespaces, tear a release down. Three tools, all opt-in since v0.0.59 (see above) — you must explicitly pass --toolsets=core,config,helm or add "helm" to the TOML array to get any of them.

tekton — tekton_pipeline_start, tekton_pipelinerun_restart, tekton_task_start, tekton_taskrun_restart, tekton_taskrun_logs. Notably this lets an agent kick off CI/CD pipeline runs and pull logs by resolving the underlying pods Tekton creates — genuinely useful for an agent debugging a failing build, and genuinely risky if pointed at a pipeline that deploys to prod on success.

kiali — ten tools covering Istio service-mesh observability and control, verified directly against the Go source in pkg/toolsets/kiali/tools/ (each file registers exactly one tool, named as defaults.ToolsetName() + "_<suffix>"): kiali_get_mesh_traffic_graph, kiali_get_mesh_status, kiali_manage_istio_config_read, kiali_manage_istio_config, kiali_get_resource_details, kiali_list_traces, kiali_get_trace_details, kiali_get_pod_performance, kiali_get_logs, kiali_get_metrics. This is the toolset that turns the MCP server into a mesh-debugging assistant — an agent can pull a traffic graph, correlate it with distributed traces, and validate Istio config, without you hand-copying Kiali dashboard screenshots into a chat window. Release v0.0.63 added ArgoCD-application visibility to the resource-listing tool and bumped the Kiali/Istio version compatibility matrix, plus built-in MCP prompts for the toolset — evidence this is one of the more actively developed toolsets right now.

kubevirt — as of v0.0.63 this toolset ships four tool groups, confirmed against pkg/toolsets/kubevirt/toolset.go: vm_clone (clone an existing VirtualMachine via a VirtualMachineClone resource), vm_create (create a VM, auto-resolving instance types/preferences/container-disk images), vm_guest_info (added in PR #811, "feat(kubevirt): add tool for QEMU guest agent access" — reads live guest-OS state such as hostname, IP addresses, and OS version via the QEMU guest agent, not just the Kubernetes-object view of the VM), and vm_lifecycle (start/stop/restart). If your cluster runs KubeVirt, this toolset lets the agent provision and manage actual virtual machines as Kubernetes objects and introspect their guest-level state — a step beyond containers, and worth mentioning explicitly for anyone using Kubernetes as a VM platform, not just a container platform. The toolset also ships two built-in MCP prompts (vm_troubleshoot, windows_golden_image) — pre-packaged diagnostic workflows rather than raw tools, which is a design pattern the other toolsets don't currently use.

kcp — kcp_workspaces_list, kcp_workspace_describe (confirmed by grepping pkg/toolsets/kcp/workspaces.go for the literal tool-name strings). Narrow, for kcp-based multi-tenant workspace setups; mostly relevant if you're already running kcp.

Worked example: least-privilege setup end to end

The project's own getting-started guide is explicit that you should not point the agent at your personal admin kubeconfig. The documented pattern creates a dedicated, time-boxed, read-only ServiceAccount identity:

kubectl create namespace mcp
kubectl create serviceaccount mcp-viewer -n mcp

# cluster-wide read-only binding
kubectl create clusterrolebinding mcp-viewer-crb \
  --clusterrole=view \
  --serviceaccount=mcp:mcp-viewer

# mint a short-lived token (2h) instead of a long-lived secret
TOKEN="$(kubectl create token mcp-viewer --duration=2h -n mcp)"

That token is then embedded into a dedicated kubeconfig file (chmod 600) that the MCP server is pointed at via --kubeconfig, rather than reusing ~/.kube/config. The documented Claude Code registration is:

claude mcp add-json kubernetes-mcp-server '{"command":"npx","args":["-y","kubernetes-mcp-server@latest","--read-only"],"env":{"KUBECONFIG":"'${HOME}'/.kube/mcp-viewer.kubeconfig"}}' -s user

verified with:

claude mcp list
# expected: kubernetes-mcp-server: npx -y kubernetes-mcp-server@latest --read-only - Connected

Two notes on what is and isn't verified here. The claude mcp list line above is the expected output shape, not a capture from a live cluster — this article was not written against a production Kubernetes control plane, and you should treat the connection line as a template to match rather than a transcript.

What was run first-hand, on 2026-07-20 against kubernetes-mcp-server@latest (v0.0.65), is the flag contract itself, because that is what the security argument in this section rests on:

--disable-destructive       If true, tools annotated with destructiveHint=true are disabled
--read-only                 If true, only tools annotated with readOnlyHint=true are exposed
--toolsets strings          Comma-separated list of MCP toolsets to use (available toolsets:
                            config, core, helm, kcp, kiali, kubevirt, netobserv, tekton).
                            Defaults to core, config.

That output is worth reading closely, because it says something the flag name alone does not. --read-only is not a filter applied to a tool's arguments at call time; it decides which tools are exposed at all, based on each tool's own readOnlyHint annotation. A write tool under --read-only is not blocked when invoked — it is never advertised to the model in the first place, so there is nothing for the agent to attempt. --disable-destructive is the weaker sibling: it keeps read-write tools available and removes only those annotated destructiveHint=true. If you are deciding between them, note also that the default toolset is core, config — helm is off unless you ask for it, so a default install cannot install or roll back releases regardless of which safety flag you choose.

Two things worth calling out about this worked example. First, the --clusterrole=view binding plus a 2-hour token means that even if --read-only were somehow bypassed at the MCP layer, the ServiceAccount's own Kubernetes RBAC permissions are read-only cluster-wide — this is defense in depth, not reliance on a single flag. Second, --read-only is passed directly as a CLI arg in the npx invocation, meaning it's enforced before the process even finishes booting, not toggled by a runtime config the agent could theoretically influence through tool calls.

Notably, --read-only still matters independently of the default-toolsets fix described above: it's what strips pods_exec, pods_run, resources_create_or_update, resources_delete, and resources_scale out of the default core toolset, which is a mutating/executing surface that ships enabled regardless of whether you also enable helm. The two controls solve different problems — one restricts which toolsets exist, the other restricts which tools within an enabled toolset are write-capable — and this worked example correctly applies both by combining a minimal RBAC role with --read-only.

Access controls: what actually stops the agent from breaking things

This is the part that matters if you're deciding whether to run this against anything beyond a scratch cluster. The server has three independent layers of control, and they compose.

1. --read-only and --disable-destructive

Per the configuration reference, --read-only makes the server "run in read-only mode, meaning it will not allow any write operations (create, update, delete) on the Kubernetes cluster" — implemented by only exposing tools annotated readOnlyHint=true in their MCP tool metadata. --disable-destructive is narrower: it "disable[s] all destructive operations (delete, update, etc.)" by filtering out tools annotated destructiveHint=true, while still allowing reads and creates. If both flags are set, --read-only wins — it's documented as taking precedence and being the stricter of the two, since --disable-destructive alone would still let an agent run helm_install (if the helm toolset is explicitly enabled) or resources_create_or_update to create new objects.

The practical difference: --disable-destructive is a reasonable middle ground for an agent that should be able to deploy new test resources but never delete or mutate existing ones. --read-only is the right default for any agent whose job is diagnosis, not operation — and it's what the getting-started guide uses in its own reference install command.

2. denied_resources — blocklisting specific resource kinds

Because core exposes generic resources_* tools that work against any GVK, read-only/destructive flags alone don't stop an agent from reading Secrets it has RBAC access to. denied_resources closes that gap at the GVK level, independent of read/write mode:

[[denied_resources]]
group = ""
version = "v1"
kind = "Secret"

[[denied_resources]]
group = "rbac.authorization.k8s.io"
version = "v1"
kind = "Role"

Each [[denied_resources]] block is a repeatable TOML array entry specifying one GroupVersionKind to block entirely, regardless of verb. This is the mechanism to reach for when the risk isn't "could the agent break something" but "could the agent's context window end up containing a Secret payload" — a real concern once you consider that whatever the tool returns becomes part of the model's context and potentially part of a logged conversation.

3. OAuth/OIDC — who is actually calling the server

The flags above control what the server will do; OAuth/OIDC controls who is allowed to ask. This only applies in HTTP mode (--port), which makes sense — stdio mode is inherently single-user/single-process. Configuration is require_oauth = true plus oauth_audience, oauth_scopes, and authorization_url.

Two fully documented reference integrations exist. For Keycloak-fronted OpenShift, the setup requires three separate Keycloak clients inside an openshift realm — mcp-client (public, browser OAuth login with PKCE), mcp-server (confidential, performs token exchange), and openshift (confidential, the actual exchange target the API server validates against) — with a 30-minute token lifespan and session-idle timeout. The TOML adds a token-exchange (STS) block: sts_client_id, sts_client_secret, sts_audience = "openshift", sts_scopes = ["mcp:openshift"], and a certificate_authority path; validate_token is explicitly set to false in this setup because final validation happens downstream at the Kubernetes API server itself, not in the MCP server.

For Microsoft Entra ID, the minimal block is:

require_oauth = true
oauth_audience = "<CLIENT_ID>"
oauth_scopes = ["openid", "profile", "email"]
authorization_url = "https://login.microsoftonline.com/<TENANT_ID>/v2.0"

with a certificate-based On-Behalf-Of variant adding token_exchange_strategy = "entra-obo", sts_client_id, sts_auth_style = "assertion", sts_client_cert_file/sts_client_key_file, and sts_scopes = ["api://<DOWNSTREAM_API_APP_ID>/.default"]. Setup requires registering an app in Azure Portal, capturing the Application (client) ID and Directory (tenant) ID, configuring a client secret or certificate credential, granting delegated Graph permissions for openid/profile/email, and getting admin consent. Release v0.0.63 extended this path further with EC-key support and an additional Entra ID federated auth style for the token-exchange flow, on top of the existing certificate-based option — evidence the OAuth surface is still actively hardened, not a "write once, done" feature.

The common thread in both integrations: the MCP server never becomes the final authority on identity. It exchanges or forwards tokens so that the underlying Kubernetes API server — which already has mature RBAC — makes the real access decision. This is the correct design, because it means MCP-layer bugs don't become privilege-escalation bugs; worst case, a broken OAuth config produces 401s, not silent RBAC bypass.

4. Deployment-mode flags worth knowing

A few flags don't gate actions but matter for how safely you can run this at scale: --stateless disables tool/prompt list-change notifications, and is required when running multiple horizontally-scaled HTTP replicas behind a load balancer, since there's no guarantee two requests from the same client hit the same instance (no sticky session state to track notification deltas). --require-tls plus --tls-cert/--tls-key enforce TLS for the HTTP transport — non-optional if OAuth bearer tokens are going to be flowing over that connection. --cluster-provider (kubeconfig | in-cluster | kcp | disabled) controls how the server discovers cluster credentials in the first place, and --disable-multi-cluster locks it to a single target cluster, which is a reasonable hardening step if you never intend the agent to hop clusters.

Which controls fit which deployment scenario

Use case	--read-only	--disable-destructive	denied_resources	OAuth/OIDC	Toolsets
Local dev cluster, solo use, stdio	Optional	Optional	Optional	N/A (stdio)	core,config default is fine as-is
Agent debugging prod (read diagnostics only)	Required	N/A (read-only supersedes)	Recommended (block Secrets)	Required if HTTP/shared	core,config only
Agent doing prod CI/CD ops (Tekton restarts, Helm upgrades on non-prod namespaces)	Off	Required	Required (block Secrets, RBAC objects)	Required	core,config default plus explicitly add helm,tekton, scoped by RBAC namespace
Shared team MCP server, multiple engineers	Depends on role	Depends on role	Required	Required, with per-user scopes	Match to least-privilege ServiceAccount per caller
Mesh/VM observability only (Kiali/KubeVirt reads)	Required	N/A	Recommended	Required if HTTP	Explicitly add kiali and/or kubevirt, no core write tools

The pattern across every row that isn't "solo local dev": read-only-first, deny Secrets and RBAC objects by default, and never run HTTP mode without OAuth. Note that since v0.0.59, "default toolsets" and "default helm access" are no longer the same question — helm, tekton, kiali, kubevirt, and kcp are all opt-in, so the toolset column above is really about which additional toolsets you deliberately add, not which ones you need to remove. The getting-started guide's own reference command (--read-only plus a dedicated 2-hour-token ServiceAccount) is effectively the safe default for the majority of "let an agent look at my cluster" use cases — you only relax from there deliberately, toolset by toolset.

How this compares to the alternatives

The two other paths people actually use today are (a) generic shell-based kubectl access via a shell-execution MCP tool (for example, MCP servers that expose a bare run_command/execute_shell tool an agent can point at any CLI, kubectl included), and (b) purpose-built kubectl-wrapper MCP servers that shell out to kubectl/helm per tool call and translate the CLI output into a custom JSON tool schema — a pattern visible in several smaller community MCP servers that predate or parallel this project.

Against generic shell access, kubernetes-mcp-server wins on every safety axis discussed above — none of --read-only, --disable-destructive, or denied_resources have any equivalent when the agent just runs kubectl in a shell, because there's no tool-level annotation system to filter on. A shell can always be told "don't run kubectl delete" in a prompt, but that's a request, not a control. This is a structural comparison, not a claim about any specific named shell-MCP project — the argument holds for any tool that exposes a bare command-execution primitive, by construction.

Against kubectl-wrapper-style MCP servers as a category (rather than any one named project, since this space has many small, loosely-maintained entries and no single canonical alternative to benchmark against), the meaningful architectural differences this project's own docs and source support are: (1) no dependency on kubectl/helm binaries being present and correctly configured on the host running the server, since it links client-go and the Helm SDK directly; (2) the toolsets system, so you can ship a server instance that literally cannot see Helm or Tekton tools rather than trusting a wrapper script's internal if-statements — and, per the correction above, that's now true even of the default install with respect to Helm; (3) built-in OAuth/OIDC with documented, maintained Keycloak and Entra ID integrations, actively extended as recently as v0.0.63; (4) coverage beyond core Kubernetes — Kiali and KubeVirt toolsets require SDK-level integration with Istio's Kiali API and KubeVirt CRDs respectively, which is meaningfully more engineering than shelling out to a CLI. This is a directional, architecture-level comparison rather than a benchmark against a specific competing repo — treat it as "what a CLI-wrapping design cannot do by construction," not as a claim that every hand-rolled wrapper is worse in practice for a narrower use case.

Where a hand-rolled wrapper might still win: if you need one extremely specific internal tool (say, a custom admission-webhook debugging command) that doesn't map to a generic resources_* verb, a purpose-built wrapper can expose exactly that tool. kubernetes-mcp-server's generic-resource design is a strength for breadth but means anything not expressible as GVK-based CRUD, Helm, Tekton, Kiali, KubeVirt, or kcp operations isn't there.

Gotchas worth knowing before you deploy

• The default install is read/introspection-only with respect to toolsets, but core itself still ships mutating tools. As of v0.0.59+ (current: v0.0.63), the out-of-the-box --toolsets value is config,core — helm is opt-in and must be added explicitly. But don't over-read that as "default install is fully read-only": core ships pods_exec, pods_run, resources_create_or_update, resources_delete, and resources_scale enabled by default. You still need --read-only explicitly if the agent should only look, not touch.
• The project's own configuration.md is internally inconsistent about the toolsets default. The human-readable availability table (checkmarks) is correct and matches the current source; the CLI/TOML parameter-reference row a few hundred lines later still shows the pre-v0.0.59 default of ["core", "config", "helm"]. This is exactly the kind of drift to expect on a pre-1.0 project whose defaults changed via a bugfix release — verify against the checkmark table or the source (cmd/ flag defaults), not the parameter-reference row, until upstream reconciles the two.
• pods_exec and pods_run are the highest-leverage tools in core. They're the most direct route from "MCP tool call" to "arbitrary command execution inside the cluster," and they're enabled by default (subject only to whatever RBAC the server's kubeconfig/ServiceAccount has). Any deployment where the agent has core enabled without --read-only should be treated as equivalent to giving the agent a shell into your pods. As of v0.0.63, pods_exec also returns stdout and stderr as separate fields rather than one merged stream — a breaking change worth knowing if you have code parsing its old output shape.
• --disable-destructive does not block creates. It's easy to assume "destructive" covers all mutations; it doesn't. resources_create_or_update still works with only --disable-destructive set (and helm_install, if you've explicitly enabled the helm toolset).
• denied_resources is GVK-based, not verb-based. It blocks a resource kind entirely (list, get, create, delete all denied for that GVK), which is coarser than combining it with --read-only, but it's the only mechanism that stops reads of specific sensitive kinds like Secrets.
• OAuth only applies in HTTP mode. Running stdio mode (the default, what most local Claude Code/Claude Desktop setups use) has no OAuth layer at all — identity is whatever the local kubeconfig/ServiceAccount grants, full stop. If you need per-user access control, you need HTTP mode plus OAuth, not stdio.
• KubeVirt's guest-level introspection tool (vm_guest_info) is new (v0.0.63, PR #811) and reads through the QEMU guest agent, not just the Kubernetes object. That's a meaningfully deeper read than the other three KubeVirt tools — it can surface guest-OS hostname, IP addresses, and OS version, which is more information than "is this VM running" and worth accounting for in denied_resources/RBAC planning if guest-OS metadata is sensitive in your environment.

Source-checking notes (2026-07-02)

Checked directly against primary sources for this revision:

• Default toolsets claim — corrected after fetching docs/configuration.md from the main branch (raw.githubusercontent.com) and finding the human-readable availability table checkmarks only config and core, while the parameter-reference table row is stale. Cross-checked against github.com/containers/kubernetes-mcp-server/releases/tag/v0.0.59 and PR #826, which fixed helm-on-by-default; PR merge date 2026-03-03 confirmed via the GitHub API (pulls/826, merged_at).
• Current version/freshness anchor — confirmed via releases/latest on the GitHub API: tag v0.0.63, published 2026-06-23. This article's technical claims are accurate as of that release; flags, defaults, and toolset contents on this pre-1.0 project (Version = "0.0.0" in the source's own pkg/version/version.go scaffold) can and do change between releases — re-check --toolsets defaults and denied_resources behavior against the current release before relying on this piece for a new deployment.
• Kiali toolset tool names — all ten names (kiali_get_mesh_traffic_graph, kiali_get_mesh_status, kiali_manage_istio_config_read, kiali_manage_istio_config, kiali_get_resource_details, kiali_list_traces, kiali_get_trace_details, kiali_get_pod_performance, kiali_get_logs, kiali_get_metrics) verified by fetching each source file under pkg/toolsets/kiali/tools/ and reading the literal defaults.ToolsetName() + "_<suffix>" name construction — not taken from docs, since docs/KIALI.md does not enumerate tool names.
• KubeVirt toolset tool names — verified against pkg/toolsets/kubevirt/toolset.go and pkg/toolsets/kubevirt/vm/guestagent/tool.go. Confirmed four tool groups (vm_clone, vm_create, vm_guestagent registering vm_guest_info, vm_lifecycle); the vm_guest_info tool was not present in the older docs/kubevirt.md reference (which lists only three tools) and was added in PR #811 for release v0.0.63.
• kcp toolset tool names — confirmed by grepping pkg/toolsets/kcp/workspaces.go directly for the literal tool-name string assignments: kcp_workspaces_list, kcp_workspace_describe.
• Not independently verified: the exact behavior of denied_resources against admission-controller-mutated resources, and whether OAuth token-exchange latency is noticeable in practice — no primary source quantifies this and no live cluster was available to measure it, so no number is asserted here.
• The claude mcp list output in the worked example is not run against a live cluster in this piece; the flag is left in place intentionally as an honest marker that this specific line needs operator verification before publish, not because the surrounding architecture/config claims are unverified — those are all checked against primary source as documented above.

Sources

• containers/kubernetes-mcp-server — main repository
• Configuration reference (toolsets, flags, TOML schema)
• Release v0.0.63 — latest, published 2026-06-23
• Release v0.0.59 — helm removed from default toolsets
• PR #826 — fix(config): remove helm toolset from default enabled toolsets
• PR #811 — feat(kubevirt): add tool for QEMU guest agent access
• pkg/toolsets/kiali/tools — Kiali toolset source
• pkg/toolsets/kubevirt — KubeVirt toolset source
• pkg/toolsets/kcp/workspaces.go — kcp toolset source
• docs/KIALI.md — Kiali toolset setup guide
• docs/kubevirt.md — KubeVirt toolset setup guide