Kubernetes MCP server v0.1.2: Helm installs ignore the namespace argument, and some multi-document applies drop documents

Self-funded research by IsoKron, conducted and written with AI assistance. Not commissioned or endorsed by the maintainers of kubernetes-mcp-server or by Red Hat; IsoKron is not affiliated with them. IsoKron sells MCP server audits, and this article shows the method it sells.

We audited containers/kubernetes-mcp-server v0.1.2 (commit 66553fed, released 4 November 2026) between 10 and 12 November 2026, against a local kind cluster running Kubernetes 1.37.0. The project is young and moving fast: v0.1.x is an early release line, and by 11 November upstream main was already 25 commits past it. Every finding was tested in scripted probe runs with no model in the loop, each against a control: the same operation sent straight to the Kubernetes API, or through kubectl or the Helm CLI as the same identity.

The finding with the cleanest control is in helm_install. Given namespace: X, it stored the Helm release record in X but created the chart’s objects in the kubeconfig’s namespace, in 3 of 3 probe runs on v0.1.2 and 3 of 3 on main; helm install -n X as the same identity put everything in X. The second is in multi-document applies: a separator written as --- (trailing space) or --- # comment made resources_create_or_update write only the first document and report success, in 3 of 3 runs for each shape, where kubectl applied every document.

The register holds 17 bugs, 7 design gaps and 2 behaviors upstream intends. The bugs were reported on 12 November as 15 issues and one comment, each with a patch offered. In a before/after benchmark on six tasks committed to git before any change was designed, v0.1.2 and a research build with the bug fixes and 19 usability changes both completed 30 of 30 runs; the research build used 59.2% fewer tool calls and cost 37.0% less per verified success, most of it on one clean-up task.

Status as of 12 November 2026: all 15 issues are open, and fix pull requests for 10 of them are open. As of 12 November 2026 there was no maintainer response.

What this means for teams running the server#

• Helm (v0.1.2, and main as of 12 November): after helm_install, check where the chart’s objects landed. Charts that template {{ .Release.Namespace }} install correctly; others go to the kubeconfig’s namespace. Pointing the kubeconfig context at the target namespace should avoid it; we infer this from the cause and did not test it.
• Multi-document YAML: write separators as a bare --- and read the objects back after the apply. A partial failure does not say which documents were already applied.
• No dry run: the write tools have no dry-run argument and ignore unknown ones. Called with dryRun: true, the tool made a real write in 3 of 3 runs, where the API’s own dryRun=All stored nothing in 3 of 3.
• Concurrent edits: send only the fields you mean to change, or keep the resourceVersion you read in the body so a stale apply is refused.
• Annotations and filters: do not rely on disable_destructive or on confirmation rules keyed on destructiveHint to stop pods_run, which writes but is annotated non-destructive. RBAC is the boundary, as upstream’s own documentation says: give the server identity only what it needs.
• Configuration: check the served tool list after setting enabled_tools or disabled_tools; a misspelled tool name is accepted silently.

Setup and boundary#

Everything ran on a single-node kind cluster (kind v0.33.0) on one Mac, seeded with throwaway objects. No real cluster and no one else’s data was touched.

Every mutating request in a run’s namespace in the API audit log was matched to a recorded tool call or control step, so no server write went unrecorded. Token figures come in two kinds throughout: benchmark tokens and cost are provider-reported (input, output, cache writes and cache reads; USD), and sizes of what the server returns are cl100k estimates of the text.

Headline finding: helm_install ignores the namespace argument for chart objects (K8S-20)#

helm_install passes its namespace argument to Helm only for release storage. Helm’s kube client then falls back to the kubeconfig’s namespace (default when the context sets none) for every object whose template sets no metadata.namespace, which is most charts. The cause is in newAction in pkg/helm/helm.go; the Helm CLI sets the client’s namespace from --namespace.

• Observed and inferred. Our server identity could not write default, so every install failed loudly, and the API audit log shows the refused creates going there. With an identity that can write the kubeconfig namespace, the objects would land there and the call would report success; that follows from the code, but we did not run it. The failed release record also blocks the name until removed.
• What it does to an agent. In the native usability session the agent read the 403, concluded that the chart hard-coded namespace: default, and told the user to edit the chart’s templates. The chart was fine.
• Fix. Set the kube client’s namespace in newAction, as the CLI does: issue 1658. Objects installed before a fix stay where they landed, and the issue says so.

Second finding: multi-document applies (K8S-06, K8S-15, K8S-01)#

resources_create_or_update splits multi-document YAML itself instead of using a YAML stream reader, and applies the documents one at a time.

• K8S-06 and K8S-15 (issue 1659) share one patch: split as kubectl’s YAML reader does, and skip empty and comment-only documents.
• K8S-01 (issue 1660): stopping at the first refusal is defensible; not saying which documents were already written is the bug, and our fix names them. The research build also dry-runs every document first and writes nothing if one is refused. That prevents the partial writes we tested, but it is not a transaction: the cluster can change between the dry run and the write.

Forced apply and lost updates: upstream’s choice, measured, not filed#

resources_create_or_update applies with server-side apply and force: true. Upstream chose this on purpose (issue 799); it has come up again in issues 445 and 1164 and pull request 1184. We measured what it means for an agent and did not file it.

The API has two protections for this edit: server-side apply without force refuses to take over fields another manager owns, and a resourceVersion in the body makes a stale write fail. Forcing switches off the first, so only the second remains, and only if the client keeps the resourceVersion it read.

Neither native session ever sent a resourceVersion. In the concurrent-edit job, another writer changed MAX_CONNECTIONS from 100 to 200 about half a second after the agent read the ConfigMap; four seconds later the agent’s forced apply set it back to 100, and the agent told the user that the other keys were unchanged. The research build adds resources_patch with an optional resourceVersion precondition, in the shape of upstream’s open proposal 1352, and makes apply without force the default. That reverses a deliberate upstream decision, so it is a proposal, not a fix.

Three more bugs that cross what an operator configures#

• K8S-25: vm_create renders workload unescaped (issue 1661). The tool fills a YAML text template and passes it to the multi-document apply, so a workload of the form <image>\n---\n<manifest> also applies the extra manifest, and the call answers “VirtualMachine created successfully”: 3 of 3 on v0.1.2 and on main. The bound on impact: the extra object is written with the server’s own identity, so RBAC still decides what it can be and denied_resources still applies; nothing bypasses RBAC or grants a permission. What breaks is the tool’s scope: with only vm_create enabled, an agent can still write any kind the identity may write. It is an argument-handling bug; upstream already describes tool filters as best-effort (pull request 1612).
• K8S-02: pods_run is annotated non-destructive but overwrites (issue 1662). Given a port, it force-applies a Service named like the Pod. Over an existing Service with the same port, the type became ClusterIP, the nodePort was dropped and the selector was replaced whole: 3 of 3. Annotated destructiveHint: false, it is the only writing tool still served under disable_destructive = true (16 tools), and confirmation rules keyed on that hint do not match it. We did not test any client’s confirmation flow.
• K8S-14: misspelled tool names are accepted (issue 1668). enabled_tools = ["resources_gett"] started a server with 0 tools; disabled_tools = ["pods_deleet"] served all 21. A misspelled toolset name stopped the server from starting, 3 of 3.

The other bugs, the design gaps and the intended behaviors are in the findings register at the end.

How the findings were checked#

K8S-17N has weaker validation than the rest. A refuter found it while checking K8S-17: when RBAC refuses the release lookup, helm_uninstall answers “Release X not found” as a success. It was never in a frozen probe series or the regression series. It rests on the refuter’s raw run and a reproduction outside the harness on 12 November, on v0.1.2 and on main; the fixed build and the Helm CLI returned the 403.

The refuters. The refuters saw the claims and source first, then our evidence and their own raw runs on the cluster. The model they ran on was not recorded. They limited K8S-25 to one argument and K8S-02 to a same-port Service, and reclassified K8S-04, K8S-05, K8S-10 and K8S-21 as design gaps, citing parity with kubectl or Helm’s defaults.

Regression and evidence. “As expected” means each bug’s tested cases stopped reproducing on both builds, and each design gap changed on the research build or, where the change is opt-in, stayed as it was. For 14 research-build runs the toolkit’s audit-log check failed because the log had outgrown what it could read at once; a streamed check written afterwards covers all 60 runs and is labeled post-hoc. Each series was recorded on a hash-chained log and anchored off-box, the benchmark at its freeze and the five earlier series later, on 11 November, once the anchor key was available. None is yet closed into an Evidence Pack, so none can be verified independently today; we will publish the packs when they are closed.

What held up#

• Optimistic concurrency where the server uses it. resources_scale sends the resourceVersion it read: an injected conflict came back as an error with nothing changed (3 of 3), and real contention surfaced 10 of 10 times.
• Unknown fields. On Kubernetes 1.37, server-side apply refused misspelled fields (3 of 3) and the tool passed the error through. CRDs that preserve unknown fields were not tested.
• Tekton cancel of a finished run. The admission webhook refused it and the tool reported the refusal, 3 of 3.
• RBAC. No probe produced a write the server identity’s RBAC did not allow; across the regression series it had 0 accepted writes outside the probe namespaces. This says nothing about tool filters, a separate, best-effort layer.
• Agent reports. Where a benchmark run failed, the agent usually said so: 4 of the 40 failed runs ended with a false “done”.

Usability pass: what the server costs an agent#

On 11 November, Claude Opus 5.5 used the unmodified server as an ordinary MCP client on 12 everyday jobs: one plain request each, no hints and no mention of an audit. A checker read the cluster at the agent’s answer and again 45 seconds later. A second session of seven targeted jobs exercised partial failures, bulk changes, many reads, a name collision and a concurrent edit. Together they cost $2.28.

Besides the Helm and concurrent-edit failures above, the clean-up job (delete every object with a label) took 60 tool calls and a quarter of the first session’s spend: with no list across kinds and no delete by selector, the agent tried 33 kinds one by one. The debug-pod job ended with a premature “done”, because the delete returned success while the pod was still terminating.

Of the 36,165 response tokens in the first session, 13,416 were data the jobs needed, 22,717 were echo (mostly write results returning the whole object, and list columns no job read), and 32 were a lookup of the available kinds. managedFields in write results alone was 6,373 tokens, 17.6% of everything the server returned.

The sessions produced a change list of 32 items: 29 built and 3 held back. Four of the 29 are bug fixes already in the register; the other 25 went into the 19 usability patches: results that say what happened (gone, pending on a finalizer, or terminating), batch and multi-get operations, resources_patch and a create-only mode, bounded waits instead of polling, trimmed write results, and better descriptions, annotations and argument checks.

Benchmark: v0.1.2 against the research build#

On 12 November (UTC) we ran 244 measured agent runs against v0.1.2 and the research build: v0.1.2 plus the 16 bug-fix patches and the 19 usability patches, with 25 tools against 21. Every run is counted: 204 passed, 40 failed, none inconclusive or stopped by the 40-turn limit. Correctness is a checker reading the cluster after the run, never the agent’s account. Runs went one at a time in a seeded shuffled order, each in a fresh namespace; they cost 18.88 USD.

First, the limits. Probe counts such as 3 of 3 show that a behavior occurs under the stated conditions, not how often. The benchmark runs each task 5 times per build, which shows spread, not a rate; no significance test is claimed. There was no bug-fixes-only arm. “Cost per verified success” is the total cost of all runs divided by the runs that passed.

Set A: tasks committed before the changes (K1 to K6)#

Scale and verify; change one ConfigMap key; apply a three-object manifest; roll back a bad image; label six of nine Deployments; delete every object with a label, one held by a finalizer for 20 seconds. The prompts were committed to git at 00:06 UTC on 11 November, before any change was designed (the first change list was committed at 01:48 UTC), and not edited since. They were frozen on the evidence chain only with the benchmark on 12 November, and K3’s manifest was written then from the draft’s description of its shape.

Opus 5.5, 30 runs per build:

With 30 of 30 on both builds, the Wilson 95% interval for completion is 0.89 to 1.00 on each.

The saving is concentrated. K6, the selective clean-up, accounts for 145 of the 173 fewer tool calls and 59.8% of the cost saving; K3, K5 and K6 together for 93.4%. Without K6, cost per verified success falls from 0.0695 to 0.0521 USD (−25.1%). On the single-object tasks K1 and K2 the research build used more tokens per success (+43.7% and +44.0%): the bigger catalog, with nothing to save.

Why tokens barely move while cost falls. The research catalog is 10,499 cl100k tokens against 6,807, 54% more, and the first turn’s context grew from about 11.8 thousand to 17.5 thousand provider tokens. The catalog is re-read from the prompt cache every turn, and cache reads are the cheapest class: for Opus, at the rates implied by the reported costs, 0.20 USD per million against 5.00 for a cache write and 20.00 for output. The research build saves output and cache writes and spends cache reads, so the cost result depends on this provider’s pricing; the tool-call result does not.

Sonnet and the observer arm. Sonnet 5.5 also completed 30 of 30 on both builds; tool calls fell from 7.40 to 3.70 per run and cost per verified success by 29.3%, while tokens per success rose 4.4%. With the server started directly instead of behind our capture proxy (24 runs), every run passed and the research build was still 29% cheaper per run.

Where the change comes from. An accounting model over the transcripts, not an ablation, splits the change by type (appendix). On set A the bug fixes contribute nothing, because every task already passed on v0.1.2. The larger catalog adds 28.7% of the baseline’s tokens per success but 3.9% of its cost. Of the 37.0% cost saving, 19.1 points are not attributed to any type, mostly shorter final answers and cache state carried between runs.

Set B: tasks from the usability sessions (secondary; favors the research build by construction)#

Set B is nine native session jobs with their prompts unchanged, plus F1b, a twin of K3 with --- # comment separators and one invalid Deployment. They were chosen after the changes were designed, from the sessions that produced them, so set B favors the research build by construction. Opus 5.5, 50 runs per build. The recorded verdicts are primary; the last column corrects our own F2 checker after the runs and is labeled post-hoc.

As recorded, completion rose by 20 percentage points (25/50 → 35/50) and cost per verified success fell 45.3%; with the post-hoc correction, by 28 percentage points (25/50 → 39/50) and 50.9%.

• F3, Helm into a namespace: 0 of 5 → 5 of 5. The K8S-20 fix, the only set B gain the model credits to a bug fix. All five baseline agents reported the failure.
• F9, concurrent edit: 0 of 5 → 5 of 5. Baseline agents lost the concurrent change every time; research agents used resources_patch.
• F2, debug pod: our checker was wrong. A criterion we added before the runs, “the server created a Pod”, counted only a create, but the server creates pods with a server-side apply PATCH; our pre-check made its pod with kubectl run and missed it. Every F2 run is recorded as failed. Re-scored from each run’s audit log with every other criterion as recorded, F2 is 0 of 5 on v0.1.2 and 4 of 5 on the research build, whose delete can wait until the pod is gone.
• F4 and F8 failed on both builds: no agent removed the test finalizer, and agents asked the user rather than write into another team’s ConfigMap. These are task-design questions, not server defects.
• Research agents used more tokens per run at the median (99,300 against 74,096): the bigger catalog, and tasks finished that baseline agents gave up on.

Benchmark limits#

• Five runs per task and build; repetitions measure spread within one prompt, not variety across Kubernetes work.
• Set A was committed to git before the changes but frozen on the evidence chain only with the benchmark. Set B favors the research build by construction, and F2’s corrected view is post-hoc.
• The research build is measured as a whole, with no bug-fixes-only arm; the by-type split is an accounting model with a large unattributed share.
• Prompt caching carries across runs; the shuffled order exposes both builds equally. Compaction was not tested.
• One client, two models, one cluster, agents running as the operator’s own user on macOS. Other clients and pricing will give other numbers.

Upstream status, 12 November 2026#

All 17 bugs were reported on 12 November 2026 in containers/kubernetes-mcp-server, as issues 1658 to 1672 and one comment on issue 1584, which has the same root cause as K8S-09. Checked on 12 November: all 15 issues were open, with no comments or labels yet, which is to be expected on the day of filing. Each issue was searched for duplicates first, credits related upstream work, and offers a patch with tests. Upstream asks for a DCO sign-off on every commit, so each pull request below carries one. The issues without a pull request (1660, 1661, 1662, 1663, 1668 and the comment on 1584) are held back until the maintainers agree on the approach.

Fix pull requests, opened on 12 November 2026:

• Pull request 1675 for issue 1658: open
• Pull request 1676 for issue 1659: open
• Pull request 1677 for issue 1664: open
• Pull request 1678 for issue 1665: open
• Pull request 1679 for issue 1666: open
• Pull request 1680 for issue 1667: open
• Pull request 1681 for issue 1669: open
• Pull request 1682 for issue 1670: open
• Pull request 1683 for issue 1671: open
• Pull request 1684 for issue 1672: open

The bug-fix patches apply to main as of 13bfb96f; one (K8S-14) needed a fix-up for main’s new opt_in_tools option. On 12 November main had moved to ec37a146; none of its four new commits touched a file the issues cite. Design gaps were not filed, and neither was the change to forced apply. We will record maintainer responses and fixes in the changelog below.

Rebuild the builds#

The patch series and the research build are published in the experiment repository isokron-ai/kubernetes-mcp-writepath-experiment. The baseline is v0.1.2 built from source (931b5f5a…); the fixed build (bac15e14…) adds the 16 bug-fix patches, and the research build (167a5a65…) adds the 19 usability patches. The fixed and research builds each gave the same binary hash when built twice, and upstream’s test suite (go test -race ./...) passes on all three. The patch series add 20, 4 and 41 test methods. The research build is an experiment, not an upstream release, and changes behavior users rely on, such as forced apply; use upstream’s server for real work.

Limitations#

• One cluster distribution (kind), one Kubernetes version (1.37.0; no claim for later releases), one node. Not tested: OpenShift Route code paths, running VirtualMachines (KubeVirt findings rest on the CRDs), the kiali, kcp, netobserv and observability toolsets, the HTTP transport, and load.
• Fault injection served the probes only; no agent met an injected API fault or retried after a timeout.
• K8S-20’s silent case, where the install reports success, follows from the code but was not run.
• K8S-17N was never in a frozen series; 14 regression runs rely on a post-hoc audit-log check.
• The findings were found with AI assistance, the refuters’ model is not recorded, and the run records are not yet closed into verifiable Evidence Packs. The benchmark’s limits are under Benchmark limits.

About this research#

IsoKron performs fixed-price MCP server audits with this method: probes against a pinned build with raw-API controls, a native agent usability pass, clean-context refutation, re-checks against upstream main, tested patches and filing upstream; the before/after benchmark is an optional, quoted add-on. Details: MCP server audits.

Appendix: findings register#

K8S-nn is a register item; K8S-17N is the candidate a refuter raised while checking K8S-17. K1 to K6 and F1a to F9 are benchmark tasks. Severity is our judgment of operational impact, not a security rating; where a refuter narrowed a finding, the wording is the narrowed one. “Main” means the same probe reproduced on main 13bfb96f.

17 bugs, reported upstream on 12 November 2026:

Sixteen rows, seventeen bugs: K8S-06 and K8S-15 share an issue and a patch. K8S-09 and K8S-19 also have a design-gap half that is not in the issue: ignored unknown arguments (the dryRun: true case), and stderr hidden behind non-empty stdout, discussed upstream in pull request 1174.

7 design gaps, not filed (as in our earlier audits, issues are for bugs only):

2 intended by upstream: K8S-17 (helm_uninstall of a release that does not exist returns success, asserted by an upstream test; the RBAC-refused case is the bug K8S-17N) and K8S-18 (read tools return the object as text and as structuredContent, per pull request 1232 and the MCP specification).

Where the change comes from#

Each tool call in the transcripts gets one role (recovery after a failed call, wait or poll, batch, multi-get, edit, or other), and its share of the run’s tokens and cost follows from where it sits in the conversation; result tokens are estimated as characters divided by 3. Only the combined build was measured, so this is an accounting model, not an ablation. Each share is the type’s change as a percentage of the baseline value, so the rows add up to the total; negative is a saving. Set B is shown as recorded.

“Smaller results” is slightly positive because per call the research build’s results are a little larger; the echo saving shows up as fewer calls, booked under batch and edit.

Changelog#

• 12 November 2026: published.