Helm MCP
Server Details
Give your AI assistant access to real Helm chart data. No more hallucinated values.yaml files.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- kubedoll-heavy-industries/helm-mcp
- GitHub Stars
- 0
- Server Listing
- mcp-helm
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose: searching charts, listing versions, retrieving values, notes, and dependencies. There is no overlap or ambiguity between the tools.
Four tools follow a consistent 'get_' prefix pattern, while 'search_charts' uses a different verb. This is a minor deviation and the naming is still predictable and readable.
With 5 tools, the server is well-scoped for inspecting Helm charts. Each tool addresses a specific information need without being excessive or insufficient.
The tool set covers the primary inspection operations for Helm charts: search, versions, values, notes, and dependencies. A minor gap is the absence of a get_readme or similar, but core workflows are well supported.
Available Tools
5 toolsget_dependenciesARead-onlyInspect
Get chart dependencies (sub-charts). Each dependency entry includes the dependency's repository URL — feed that URL back into search_charts, get_versions, or get_values to inspect the dependency. Supports both HTTP/HTTPS repos and OCI registries (oci://).
| Name | Required | Description | Default |
|---|---|---|---|
| chart_name | Yes | Chart name (e.g. postgresql) | |
| chart_version | No | Chart version (defaults to latest) | |
| repository_url | Yes | Helm repository URL (e.g. https://charts.bitnami.com/bitnami) or OCI registry (e.g. oci://ghcr.io/traefik/helm) |
Output Schema
| Name | Required | Description |
|---|---|---|
| version | Yes | Resolved chart version (especially useful when chart_version was omitted and latest was used) |
| dependencies | Yes | Chart dependencies |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context about supporting HTTP/HTTPS and OCI registries, exceeding annotation requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover purpose and usage guidance efficiently with no redundant information, front-loading the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description sufficiently covers the tool's function and integration with sibling tools, though it could slightly expand on dependency entry contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with clear parameter descriptions. The description adds some context about the repository URL's role, but does not significantly augment the schema's semantics for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves chart dependencies (sub-charts) and differentiates from sibling tools like get_notes, get_values, get_versions, and search_charts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions feeding the dependency's repository URL into search_charts, get_versions, or get_values, guiding when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_notesARead-onlyInspect
Get chart NOTES.txt (post-install instructions). Supports both HTTP/HTTPS repos and OCI registries (oci://).
| Name | Required | Description | Default |
|---|---|---|---|
| chart_name | Yes | Chart name (e.g. postgresql) | |
| chart_version | No | Chart version (defaults to latest) | |
| repository_url | Yes | Helm repository URL (e.g. https://charts.bitnami.com/bitnami) or OCI registry (e.g. oci://ghcr.io/traefik/helm) |
Output Schema
| Name | Required | Description |
|---|---|---|
| notes | Yes | Contents of NOTES.txt |
| version | Yes | Resolved chart version (especially useful when chart_version was omitted and latest was used) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe, read-only operation with open-world assumptions. The description adds useful context about supported repository types (HTTP/HTTPS and OCI registries), but does not disclose additional behavioral traits such as rate limits, authentication needs, or error handling. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of just two sentences that efficiently convey the tool's purpose and key usage context. Every sentence earns its place without redundancy or unnecessary elaboration, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, 2 required), rich annotations (readOnlyHint, openWorldHint), and the presence of an output schema, the description is mostly complete. It covers the core purpose and repository support, but could benefit from more behavioral context (e.g., error cases or output format hints) to fully compensate for the lack of explicit guidelines on when to use versus siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters well-documented in the input schema. The description adds minimal value beyond the schema by implying repository_url supports both HTTP/HTTPS and OCI formats, but does not provide additional syntax, format details, or meaning for parameters like chart_name or chart_version. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get chart NOTES.txt') and resource ('post-install instructions'), distinguishing it from sibling tools like get_dependencies, get_values, get_versions, and search_charts. It specifies the exact file being retrieved (NOTES.txt) and its purpose (post-install instructions), avoiding vagueness or tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it 'Supports both HTTP/HTTPS repos and OCI registries (oci://)', which helps guide usage based on repository type. However, it does not explicitly mention when to use this tool versus alternatives like get_dependencies or get_values, nor does it provide exclusions or prerequisites, leaving some room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_valuesARead-onlyInspect
Get chart values.yaml with optional JSON schema. Uses depth limiting (default 2) to show structure without overwhelming context. Use path to drill into specific sections, depth=0 for full YAML. include_examples surfaces nearby commented YAML examples and requires path to be set. Supports both HTTP/HTTPS repos and OCI registries (oci://).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | YAML path (e.g. .ingress.enabled) | |
| depth | No | Max nesting depth (default 2, 0 for unlimited) | |
| chart_name | Yes | Chart name (e.g. postgresql) | |
| chart_version | No | Chart version (defaults to latest) | |
| example_limit | No | Maximum nearby examples to include (default 1, max 3, 0 falls back to default) | |
| show_comments | No | Preserve YAML comments | |
| show_defaults | No | Include default values | |
| include_schema | No | Include values.schema.json in response | |
| repository_url | Yes | Helm repository URL (e.g. https://charts.bitnami.com/bitnami) or OCI registry (e.g. oci://ghcr.io/traefik/helm) | |
| max_array_items | No | Max array items before truncation (default 3, 0 for unlimited) | |
| include_examples | No | Include nearby commented YAML examples for the selected path (requires path to be set) |
Output Schema
| Name | Required | Description |
|---|---|---|
| path | No | Extracted path, if specified |
| schema | No | JSON Schema for values (if include_schema=true and schema exists) |
| values | Yes | Values content (YAML) |
| version | Yes | Resolved chart version (especially useful when chart_version was omitted and latest was used) |
| examples | No | Nearby commented YAML examples, if include_examples=true and examples are found |
| parse_warning | No | Set when the YAML parser failed on this chart's values.yaml. The 'values' field then contains raw bytes (possibly truncated) and path/depth/include_examples/include_schema were not applied |
| schema_warning | No | Set when include_schema=true but the schema could not be retrieved; absence of this field with empty schema means the chart has no schema |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description aligns by describing a read operation. It adds context beyond annotations, such as default depth of 2, behavior of include_examples requiring path, and support for multiple repository types, which helps agents understand side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the primary purpose and then providing usage details. Each phrase adds value, with no wasted words. It is structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, 100% schema coverage, and an output schema, the description covers the main functionality (depth limiting, path drilling, examples, repo types) sufficiently. It does not need to repeat schema details, and the agent gets a complete picture of the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds narrative context not present in schema descriptions, such as the interaction between include_examples and path, and default depth behavior. This enhances parameter understanding without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves chart values.yaml with optional JSON schema, mentioning specific features like depth limiting and path drilling. This distinctively separates it from sibling tools that handle dependencies, notes, versions, or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides actionable guidance on when to use depth, path, and include_examples, and mentions support for both HTTP/HTTPS and OCI registries. However, it does not explicitly exclude cases or compare to sibling tools, relying on their distinct purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_versionsARead-onlyInspect
Get available versions of a chart (newest first). Supports both HTTP/HTTPS repos and OCI registries (oci://). Use this to confirm a chart exists before calling get_values, or to find a specific version to pin.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results (default 20, max 100) | |
| chart_name | Yes | Chart name (e.g. postgresql) | |
| repository_url | Yes | Helm repository URL (e.g. https://charts.bitnami.com/bitnami) or OCI registry (e.g. oci://ghcr.io/traefik/helm) |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Total versions available (may exceed returned results if limit applied) |
| versions | Yes | Chart versions (newest first) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds ordering (newest first) and protocol support (HTTP/HTTPS and OCI), which are useful behavioral traits not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states core functionality with ordering, second adds usage guidance. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, description does not need to explain return values. It covers functionality, ordering, supported protocols, and usage guidance, making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema fully documents all parameters. Description does not add additional parameter info, meeting baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get available versions of a chart (newest first)' and distinguishes from sibling tools like get_values and get_notes by specifying use cases like confirming existence before calling get_values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'Use this to confirm a chart exists before calling get_values, or to find a specific version to pin.' Provides clear context and exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_chartsARead-onlyInspect
List or search charts in a Helm repository. Provide a repository_url, then optionally filter by keyword (e.g. keyword='postgres'). Note: OCI registries (oci://) do not support browsing — for OCI you must already know the chart name, then call get_versions or get_values directly with that name.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results (default 50, max 200) | |
| keyword | No | Filter charts by name (case-insensitive substring match, e.g. 'postgres') | |
| repository_url | Yes | Helm repository URL (e.g. https://charts.bitnami.com/bitnami) or OCI registry (e.g. oci://ghcr.io/traefik/helm) |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Total matching charts (may exceed returned results if limit applied) |
| charts | Yes | Chart names |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint and openWorldHint. Description adds useful behavioral context about OCI limitation beyond annotations, but no extra detail on return format or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence covers purpose and usage, second adds critical exception. Front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage, output schema present, and clean annotations, the description adequately covers usage, limitations, and alternatives. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage. Description reinforces usage with an example ('keyword=postgres') and clarifies that repository_url is required and keyword is optional, slightly exceeding the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List or search charts in a Helm repository' with specific verb+resource. Differentiates from sibling tools (get_dependencies, get_notes, get_values, get_versions) which target specific chart operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to provide repository_url, optionally filter by keyword, and notes OCI registries do not support browsing. Recommends alternatives (get_versions/get_values) for OCI.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.