Inspects the cluster and its Helm releases, and writes the manifests, charts and policies that go through Git rather than around it.
Built for: The platform engineer who owns three clusters and a repository that is supposed to describe all of them.
The button opens the checkout, where the 2 servers and 5 skills are listed one by one. Every member is free, so the checkout lists them and asks for no card.
The reason to buy a stack rather than five listings: each line below needs more than one member connected at the same time.
Read pods, events and logs in the namespaces you allow and name the workload that keeps restarting, with the Kubernetes server started read-only.
List Helm releases with their values and revision history, render the manifests a chart produces with new values, and prepare the rollback a person then runs.
Write a manifest or a chart with production defaults, NetworkPolicy and RBAC, and try it on a local KIND cluster first.
Hand the change over as a commit for the GitOps repository, in the shape Argo CD or Flux will reconcile.
What each part contributes, and why it was picked over the obvious alternative. Prices and permissions are read from the listings, so nothing here can disagree with the catalogue.
The containers project's Kubernetes and OpenShift server — pods, logs, events and resources — with --read-only and --disable-destructive for the days it should only look.
The Helm CLI as MCP tools: releases, values, manifests, history, lint and rollback, for the parts of the cluster that were installed as charts.
Deployments, Services, ConfigMaps and Secrets written to production defaults — probes, limits, labels — instead of copied from an old service.
Chart layout, values and templating for the service that is about to be installed in more than one environment.
NetworkPolicy, pod security and RBAC, so a new namespace starts closed rather than open.
The GitOps loop with Argo CD or Flux — what lives in Git, how it reconciles, how a change is promoted between environments.
OpenHands' skill for a throwaway KIND cluster in Docker, where a manifest is tried before it is proposed.
Every member is free, so the monthly figure is $0 whatever you do with the stack: nothing here is billed by the call, and only adding a paid member could change it.
| Part | What you are paying for | Monthly, as quoted |
|---|---|---|
| Kubernetes | Free | — |
| Helm | Free | — |
| Skills | ||
| Kubernetes Manifest Generator | Free · context cost only | — |
| Helm Chart Scaffolding | Free · context cost only | — |
| Kubernetes Security Policies | Free · context cost only | — |
| GitOps Workflow | Free · context cost only | — |
| Kubernetes Local Development with KIND | Free · context cost only | — |
| Everything above | $0 of servers plus $0 of skills, the same in a quiet month and a busy one | $0/mo |
Subscriptions at their monthly plan price; one-off licences spread over 12 months.
Install only these and the bill is nothing: 2 servers and 5 skills.
Nothing in this stack carries a call allowance, so nothing here can run out before the month does. The bill is decided when you install it, not when you use it.
The spend cap is one figure for the whole account, set in your dashboard and checked when an order is placed. On the call path what stops a retry loop is the plan's call allowance and its rate limit, and a refused call is never billed.
The steps below come before the install lines: what to decide and scope before connecting anything, in the order it matters. The lines themselves follow, part by part, for the client you pick.
npx mcprush@latest stack add cluster-desk writes all 2 servers into Claude Code’s config in one go — or run the lines below one by one. The 5 skills are not included — add them with lines 03–07.
# 01 · Kubernetes
claude mcp add --scope user containers-kubernetes-mcp '--' npx -y kubernetes-mcp-server
# 02 · Helm
claude mcp add --scope user scgis-wales-helm-mcp '--' uvx helm-mcp
# 03 · Kubernetes Manifest Generator
npx mcprush@latest skill add wshobson/kubernetes-manifest-generator
# 04 · Helm Chart Scaffolding
npx mcprush@latest skill add wshobson/helm-chart-scaffolding
# 05 · Kubernetes Security Policies
npx mcprush@latest skill add wshobson/kubernetes-security-policies
# 06 · GitOps Workflow
npx mcprush@latest skill add wshobson/gitops-workflow
# 07 · Kubernetes Local Development with KIND
npx mcprush@latest skill add openhands/kubernetes-local-development-with-kindnpx).uvx, docs.astral.sh/uv).Set-ExecutionPolicy -Scope CurrentUser RemoteSigned once, or type npx.cmd instead of npx (codex.cmd, gemini.cmd, grok.cmd likewise). PowerShell 7 needs neither.Nothing is connected until you approve it in Claude Code. mcprush is not in the path and meters nothing here.
Installed together, these tool surfaces add up. It is the first thing a security reviewer asks for, so what has been counted — and what nobody has counted yet — is on the page rather than in a PDF.
| Member | Tool surface | Write tools |
|---|---|---|
| Helm | not imported | not recorded |
| Kubernetes | not imported | not recorded |
A stack's blast radius is the union of its members, not the worst of them. That union cannot be taken here, because 2 members of 2 have no imported tool surface — so the figure a review asks for is missing rather than low, and a member marked not imported is one nobody has counted rather than one that cannot write.
A stack is a default, not a verdict. These are the substitutions the maintainer would make, and what each one costs or saves.
Where the rule is that nothing connected to the cluster may write, take a server that only lists pods, deployments, services, events and logs — there are no write tools to switch off.
Written by the maintainer, kept on the page rather than in a support thread.
It does not apply changes to a production cluster on its own account. Both servers can write when you let them; this desk expects them read-only and the change to arrive through Git.
It is not a monitoring system. Metrics and alerts belong to the observability and on-call desks.
The Helm member exposes the whole Helm CLI, install, uninstall and rollback included. The limit is the kubeconfig context and RBAC you give it, not the prompt.
A stack has an owner: whoever keeps it re-checks the combination when a member changes, and the members themselves are published by the people named on each row.
Tools to inspect code changes, run checks and prepare a pull request review.
Tools to investigate a bug report and work toward a reproducible test case.
Tools to investigate alerts, check recent changes and follow the runbook.