Skip to main content
Glama

helm-install

Install Helm charts on Kubernetes clusters to deploy applications using specified releases, charts, namespaces, and configuration values.

Instructions

Install a Helm chart

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesThe name of the release
chartYesThe chart reference (repo/chart or path)
namespaceNoThe namespace to install into (optional, defaults to current context namespace)
valuesNoValues to override (YAML string)
versionNoChart version to install

Implementation Reference

  • Handler that executes the helm install command based on input parameters using execAsync.
    case "helm-install": {
      const { name, chart, namespace, values, version } = args;
      const nsArg = namespace ? `-n ${namespace}` : "";
      const versionArg = version ? `--version ${version}` : "";
      const valuesArg = values ? `-f <(echo '${values}')` : "";
      const cmd = `helm install ${name} ${chart} ${nsArg} ${versionArg} ${valuesArg}`;
      const { stdout } = await execAsync(cmd);
      return {
        content: [{ type: "text", text: stdout || `Helm chart ${chart} installed as ${name}` }]
      };
    }
  • Schema definition for the helm-install tool, including input parameters and requirements.
      name: "helm-install",
      description: "Install a Helm chart",
      inputSchema: {
        type: "object",
        properties: {
          name: { 
            type: "string",
            description: "The name of the release"
          },
          chart: { 
            type: "string",
            description: "The chart reference (repo/chart or path)"
          },
          namespace: { 
            type: "string",
            description: "The namespace to install into (optional, defaults to current context namespace)"
          },
          values: { 
            type: "string",
            description: "Values to override (YAML string)"
          },
          version: { 
            type: "string",
            description: "Chart version to install"
          }
        },
        required: ["name", "chart"]
      }
    },
  • server.js:1392-1394 (registration)
    Registration of all tools including helm-install via the ListToolsRequestSchema handler that returns the tools array.
    server.setRequestHandler(ListToolsRequestSchema, async () => {
      return { tools };
    });
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure but provides almost none. 'Install a Helm chart' implies a write/mutation operation but doesn't disclose whether this requires specific permissions, what happens on conflicts, whether it's idempotent, or any side effects. For a deployment tool with zero annotation coverage, this is a critical gap in behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is maximally concise with just three words that directly convey the core function. There's zero wasted language, no unnecessary elaboration, and it's perfectly front-loaded. This is an excellent example of efficiency in tool description writing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex deployment tool with no annotations and no output schema, the description is severely incomplete. It doesn't explain what a Helm chart is, what installation entails, what the expected output looks like, or any behavioral characteristics. The combination of mutation nature, technical complexity, and lack of structured metadata means the description should provide much more context than it does.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds no parameter information beyond what's already in the schema, which has 100% coverage with clear descriptions for all 5 parameters. The baseline score of 3 is appropriate since the schema fully documents parameters like 'name', 'chart', 'namespace', 'values', and 'version'. The description doesn't compensate but doesn't need to given the comprehensive schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Install a Helm chart' clearly states the action (install) and resource (Helm chart), making the purpose immediately understandable. It distinguishes from siblings like helm-list, helm-uninstall, and helm-upgrade by specifying the installation action. However, it doesn't explicitly differentiate from other installation tools like apply or create-namespace, which slightly limits sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose helm-install over helm-upgrade, when to use it versus kubectl apply, or any prerequisites like having Helm configured. The agent must infer usage from the tool name alone, which is insufficient for optimal tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/thekaranpargaie/kube-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server