Skip to main content
Glama

helm breaking changes

helm_breaking_changes
Read-onlyIdempotent

Helm chart upgrade brief between two chart versions: default values.yaml diff (removed, added, changed keys and possible renames), chart changelog and breaking items from Artifact Hub and the chart repo, README upgrade sections, kubeVersion, subchart and appVersion changes, concrete edits for your values file, sources. Paid: $0.01 USDC per call via x402.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "chart": "<chart>",
      "from": "<from>"
    },
    "name": "helm_breaking_changes"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoTarget version: exact, or a major prefix meaning its first release. Default: latest
fromYesVersion you use now: exact or a major/minor prefix meaning its newest release
chartYesArtifact Hub <repository>/<chart>, e.g. 'bitnami/redis', 'ingress-nginx/ingress-nginx'
valuesNoOptional comma-separated value keys you override, to flag removed or changed ones
prereleasesNoInclude prerelease versions

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior4/5

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

Goes beyond the readOnly/idempotent/openWorld annotations by disclosing the data sources (Artifact Hub and the chart repo) and the pay-per-call cost ($0.01 USDC via x402), which an agent needs before invoking. It stops short of describing failure behavior for unknown charts or response size/latency for a multi-source aggregation.

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

Conciseness4/5

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

One front-loaded sentence establishes the deliverable, then the output contents are enumerated compactly with the pricing note last. The inline parenthetical list is dense but every clause maps to real returned content, so little is wasted.

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

Completeness4/5

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

With no output schema, the description carries the burden of describing return values and does so thoroughly (diff, changelog/breaking items, README, kubeVersion, subchart, appVersion, edits, sources). Only edge-case behavior (chart not found, partial source failures) is unaddressed.

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?

Schema coverage is 100%, so all five parameters including prefix semantics for 'from'/'to' are already documented. The description adds a little by explaining what 'values' is used for ('concrete edits for your values file', renames) but does not add syntax or resolution rules beyond the schema; baseline 3 applies.

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

Purpose5/5

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

States a specific verb and resource ('Helm chart upgrade brief between two chart versions') and enumerates exactly what the brief contains, so an agent knows the deliverable rather than just the topic. The Helm/Artifact Hub scoping cleanly separates it from the npm, pypi, crates, go and terraform siblings.

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

Usage Guidelines3/5

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

The two-version framing implies the upgrade-review scenario, and the 'values' key list hints at the personalization use case, but there is no explicit when-to-use statement, no exclusion, and no pointer to an alternative sibling (e.g. dependency_upgrade_plan for a full plan).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources