Your agent manages releases on a cluster.
MCP Helm lets your agent put applications onto a Kubernetes cluster and manage them over time. A chart is a packaged application, and a release is one running copy of it. The agent can install a chart as a named release, upgrade it, roll it back to an earlier revision and uninstall it. It can read a release's status, history and settings, check and preview a chart before it touches the cluster, and add, search and download from chart repositories. It talks to the cluster directly and keeps a record of every revision of a release.
It is a MAIT version of the Helm workflow, not the Helm program, and its chart support is deliberately narrow. It fills in only the release name, the namespace, the chart name and the chart version, and it does not evaluate settings, functions or conditions inside a chart. It fits charts written as plain Kubernetes files with those four fill-ins. Most public charts need preparing first, and a preview tells you before you install.
What you gain over typing Helm commands.
A release is a series of revisions on a live cluster, and the dangerous mistakes are repeats and half-finished changes. Short, clear requests and a recorded history keep each step checkable.
Releases by asking
You say "upgrade the demo release" and the agent makes one clear request that names exactly what it changes
- Typical alternative
- You type and adapt Helm commands and options
- Here
- Your agent installs, upgrades, rolls back, removes and reads releases, always naming the release and where it runs
Every revision is kept
The agent can see what was deployed and return to a revision that was verified
- Typical alternative
- A failed change leaves no trace of what was running
- Here
- Each install, upgrade and rollback is recorded, and the agent can list the revisions and read what each one contained
Preview before you apply
The agent reviews the exact resources first, and sees early when a chart is outside what the renderer supports
- Typical alternative
- A chart is installed to find out whether it works
- Here
- The agent checks a chart and shows the resources it would create, with no change to the cluster
No separate Helm program
The agent works in one place on the cluster you pointed it at, with nothing else to install
- Typical alternative
- A Helm program and its setup on every machine
- Here
- The server works with the cluster directly, using the cluster access settings it starts with
Find and download charts in one go
Finding a chart, downloading it and reviewing it follow each other without leaving the conversation
- Typical alternative
- Add, update, search and download as separate commands
- Here
- The agent adds a repository, searches it and downloads a chosen version within the same conversation
Compact results
The agent reads a few facts, not a log
- Typical alternative
- Long command output fills the conversation
- Here
- Each answer is a small summary, such as a release's name, place, revision and status
One binary, one entry to connect.
MCP Helm is not included in the MAIT image; install the binary supplied to you (Getting Started). Runs on Linux (amd64, arm64). On macOS and Windows, MCP Helm runs in the managed Linux environment that AIDC Launch provides. Your agent client starts it once you add one entry.
It needs a Kubernetes cluster it can reach, through your usual cluster access settings or, inside a pod, the account the pod runs as. It connects to the cluster before it offers any tool, so missing or invalid access settings stop it at the start. Choose the target explicitly: a single request carries no choice of cluster. Get started shows the setting.
You can also connect it through MCP Registry, so a single entry reaches all your tool servers.
Where it sits in the MAIT toolkit.
Where to read on.
- Get started, Use cases and Tools