HE
Developer Tools

Helm Chart CLI MCP Server for AI Assistants

Enable AI assistants to manage Helm charts on Kubernetes with the MCP server, executing installs, repo management, and CLI commands via natural language.

View on GitHub
Quick Install
npx -y @jeff-nasseri/helm-chart-cli-mcp

Overview

The Helm Chart CLI MCP Server exposes Helm functionality to AI assistants through the Model Context Protocol (MCP). Instead of manually running helm commands, an assistant can submit natural-language requests which the MCP server maps to Helm CLI operations — for example adding repositories, installing or upgrading charts, rendering templates, or performing dry-runs. The server runs alongside Kubernetes access (via KUBECONFIG or in-cluster credentials) and acts as a safe, auditable bridge between a language model and cluster operations.

This is useful for operator automation, chatops, and building assistant workflows that need to manage applications on Kubernetes without exposing a full shell. Developers can integrate the MCP server with conversational agents, automated playbooks, or CI systems so that the agent executes only the intended Helm actions and returns structured results (logs, manifests, exit codes) for inspection.

Features

  • Map natural-language requests to Helm CLI actions via MCP
  • Support for common Helm operations: repo add/update, install, upgrade, uninstall, list, show, template, lint, rollback, history
  • Dry-run and –debug execution modes to preview changes
  • Return structured responses: command output, rendered manifests, exit codes, and errors
  • Support for KUBECONFIG or in-cluster service account credentials
  • Configurable execution policies and logging for auditability
  • Docker-friendly and can be deployed into Kubernetes

Installation / Configuration

Clone and build the project locally, or run from the provided Docker image.

Clone and build:

git clone https://github.com/jeff-nasseri/helm-chart-cli-mcp.git
cd helm-chart-cli-mcp
# If the project is in Go, build (example)
go build -o helm-mcp ./cmd/server

Build and run Docker image:

docker build -t helm-mcp:latest .
# Run with local kubeconfig volume mounted
docker run --rm -p 8080:8080 \
  -v $KUBECONFIG:/root/.kube/config:ro \
  -e PORT=8080 \
  helm-mcp:latest

Run in-cluster (Kubernetes):

  • Create a ServiceAccount and bind it to a Role/ClusterRole that grants the minimum Helm permissions required (create, update, list, delete on releases/resources).
  • Deploy the server container in a Deployment and configure RBAC, liveness/readiness probes, and resource limits.

Environment variables (example):

PORT=8080
LOG_LEVEL=info
HELM_BIN=/usr/local/bin/helm
ALLOW_DRY_RUN=true
MAX_CMD_RUNTIME=60s

Configuration tips:

  • Use a dedicated service account for the MCP server with least privilege.
  • Enable dry-run mode for new deployments to let the assistant preview changes.
  • Persist logs to a centralized store for auditing assistant-driven changes.

Available Resources

The MCP server exposes tools and endpoints that correspond to common Helm capabilities. Typical resources you can call from an assistant include:

  • repo.add(name, url)
  • repo.update()
  • chart.search(query)
  • release.install(name, chart, namespace, values)
  • release.upgrade(name, chart, values)
  • release.uninstall(name, namespace)
  • release.list(namespace?)
  • release.history(name)
  • release.rollback(name, revision)
  • chart.template(chart, values, namespace)
  • chart.lint(chart, values)

Example mapping (natural language → action):

IntentExample Command
“Add a repo”repo.add(“bitnami”, “https://charts.bitnami.com/bitnami”)
“Install chart”release.install(“my-app”,“bitnami/nginx”, “default”, {replicaCount:2})
“Preview manifest”chart.template(“my-chart”, values.yaml, “staging”)

The server returns structured JSON including stdout/stderr, rendered manifests (if requested), return code, and execution metadata.

Use Cases

  • ChatOps: Let a Slack/Teams assistant install or upgrade charts after user confirmation. Example: “Install the latest nginx chart in namespace staging with 2 replicas.” The assistant calls release.install and returns a dry-run first, then the real install upon confirmation.
  • Self-service developer workflows: Developers request a preview of a Helm template to validate values before opening a PR. Example: “Render manifests for chart X with these values” → chart.template (dry-run) → returns YAML.
  • Incident response: On-call assistant runs a rollback to a known-good revision: “Rollback release my-app to revision 3 in production” → release.rollback.
  • CI/CD gateway: A pipeline invokes the MCP server so that policy checks or human approvals happen in one place; the assistant performs the final helm upgrade only when checks pass.

Security & Best Practices

  • Use least-privilege RBAC for the server’s service account.
  • Prefer dry-run and –debug modes for exploratory actions.
  • Log all requests and command outputs; maintain an audit trail of assistant-driven changes.
  • Rate-limit and authenticate inbound MCP requests to prevent misuse.
  • Validate values and chart sources before installing untrusted charts.

Troubleshooting

  • Permission errors: ensure the server’s service account/KUBECONFIG has the required RBAC rules.
  • Timeouts: increase MAX_CMD_RUNTIME or tune Kubernetes readiness probes.
  • Helm binary errors: confirm HELM_BIN path and Helm version compatibility with charts.

For the full source, README, and issue tracker, see the project on GitHub: https://github.com/jeff-nasseri/helm-chart-cli-mcp.

Tags:developer-tools