Give your AI assistant access to real Helm chart data. No more hallucinated values.yaml files.
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.
Average 4.3/5 across 5 of 5 tools scored.
Each tool serves a distinct purpose: search_charts finds charts, get_versions lists versions, get_values retrieves configuration, get_notes provides post-install instructions, and get_dependencies exposes sub-charts. No overlapping functionality; boundaries are clear even for similar tasks.
All tool names follow a consistent verb_noun pattern with lowercase and underscores: get_dependencies, get_notes, get_values, get_versions, and search_charts. This makes the tool set predictable and easy to navigate.
With 5 tools, the set is well-scoped for inspecting Helm charts. Each tool addresses a significant aspect of chart discovery and inspection, and none feel redundant or extraneous.
The tool surface covers the full range of chart inspection tasks: searching repositories, checking versions, retrieving values, viewing notes, and revealing dependencies. No obvious gaps for a read-only inspection server.
get_dependenciesAGet 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) |
| Name | Required | Description |
|---|---|---|
| version | Yes | Resolved chart version (especially useful when chart_version was omitted and latest was used) |
| dependencies | Yes | Chart dependencies |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral details: it supports both HTTP/HTTPS and OCI registries, and each dependency entry includes the repository URL for further inspection. It doesn't contradict annotations, and the extra context goes beyond what annotations provide.
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, front-loaded with the core purpose, and every sentence adds value. The first sentence states the function, the second explains how to use the results and notes OCI support. No wasted words.
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 that an output schema exists, the description need not detail return types. It provides a complete workflow context by explaining the dependency entry's repository URL and how to chain it into sibling tools, covering the essential usage scenario for an agent. Annotations cover the read-only nature, and the parameter schema is complete.
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 three parameters (chart_name, chart_version, repository_url) already explained. The description does not add new parameter-level semantics; it only mentions OCI support, which is already in the schema example. Thus, it meets the baseline for high coverage without adding extra value.
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 tool retrieves chart dependencies (sub-charts), using a specific verb and resource. It also distinguishes itself from sibling tools by explaining that the returned repository URLs can be fed back into other chart-related tools, making its unique role explicit.
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 showing how to use the output with search_charts, get_versions, or get_values, which implies a workflow. However, it doesn't explicitly state when not to use this tool or list alternatives for cases where dependencies are not needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_notesAGet 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) |
| 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and open-world. The description adds useful behavioral context by specifying support for both HTTP/HTTPS repos and OCI registries, which affects how the tool can be invoked. No contradictions 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?
Two sentences, front-loaded with the purpose, and no filler. Every word adds value.
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?
The description covers purpose and protocol support, and the output schema handles return values. It's sufficient for a simple retrieval tool with good schema coverage, though it could mention optional chart_version defaults, but that's already in the schema.
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%, so the schema already documents all three parameters. The description does not add extra meaning beyond noting OCI support for repository_url, but the baseline of 3 is appropriate when schema coverage is high.
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 tool retrieves chart NOTES.txt (post-install instructions), which is a specific verb+resource. It distinguishes from sibling tools like get_values and get_versions by targeting a unique artifact.
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 implies when to use the tool (to fetch post-install instructions) and adds protocol context (HTTP/HTTPS and OCI). It lacks explicit exclusions or alternative tool references, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_valuesAGet 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) |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given the annotations (readOnlyHint=true, openWorldHint=true), the description adds valuable behavioral context: depth limiting defaults, the ability to fetch full YAML with depth=0, the requirement of path for examples, and support for both HTTP/HTTPS and OCI registries. It does not contradict the annotations and discloses behaviors beyond what structured fields reveal.
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 three sentences, front-loaded with the core purpose, and every sentence adds distinct value: the first states what the tool does, the second explains the depth and path mechanism, and the third covers examples and repository type support. It is concise and well-structured with no filler.
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 available, return values are already covered. The description addresses the most important usage behaviors—depth limiting, path drilling, example inclusion, and repository support—which is sufficient for a tool with 11 parameters. Minor omissions like max_array_items or show_defaults are already documented in the schema, so the description is complete enough 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?
The schema provides 100% coverage of all 11 parameters with descriptions, so the baseline is 3. The description adds a small amount of semantic clarity (e.g., 'depth=0 for full YAML' reinforces the schema's '0 for unlimited', and 'use path to drill into specific sections' clarifies path usage), but it largely reiterates schema details without offering substantial new meaning.
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 tool retrieves 'chart values.yaml' with an optional JSON schema, using a specific verb (Get) and resource (values.yaml). This distinctly differentiates it from sibling tools like get_dependencies, get_notes, get_versions, and search_charts, which target other chart aspects.
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 guidance on how to use path and depth parameters ('Use path to drill into specific sections, depth=0 for full YAML') and explains the purpose of depth limiting to avoid overwhelming context. It also notes that include_examples requires path to be set, but it does not explicitly state when to use this tool over its siblings, though the names make this largely evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_versionsAGet 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) |
| Name | Required | Description |
|---|---|---|
| total | Yes | Total versions available (may exceed returned results if limit applied) |
| versions | Yes | Chart versions (newest first) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: results are ordered 'newest first', and it supports both HTTP/HTTPS and OCI registries. Since readOnlyHint and openWorldHint are already annotated, the description effectively supplements with ordering and scope without contradicting 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 two sentences long, front-loaded with the core purpose, and every sentence provides value—first the action, then usage guidance. No redundant or filler text.
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?
The description is complete for a simple read-only tool. It covers the operation, ordering, supported endpoints, and intended use cases. An output schema exists to document return values, and annotations handle safety, so nothing critical is missing.
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?
The input schema already documents all parameters (100% coverage), including examples for repository_url and chart_name. The description reiterates OCI support, adding slight emphasis, but does not introduce new semantic meaning beyond what the schema provides. 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 uses a specific verb and resource: 'Get available versions of a chart (newest first).' It clearly distinguishes itself from sibling tools like get_values by stating it is used to confirm a chart exists or find a version to pin, which sets it apart from fetching 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?
Explicit usage guidance is provided: 'Use this to confirm a chart exists before calling get_values, or to find a specific version to pin.' It also mentions supported repository types (HTTP/HTTPS and OCI), giving clear context on when this tool applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_chartsAList 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) |
| Name | Required | Description |
|---|---|---|
| total | Yes | Total matching charts (may exceed returned results if limit applied) |
| charts | Yes | Chart names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds a key behavioral limitation: OCI registries do not support browsing, requiring pre-known chart names. This is valuable context beyond the 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 sentences, front-loaded with the primary purpose, followed by a crucial OCI-specific usage note. Every word earns its place; no redundancy or fluff.
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 presence of an output schema and annotations, the description fully covers the tool's behavior, including the OCI limitation and how to proceed in that case. It is complete for effective selection and invocation.
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% with detailed parameter descriptions (repository_url, keyword, limit). The description adds only a minor example for keyword usage, so it meets the baseline without substantial extra value.
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 opens with a clear verb+resource statement: 'List or search charts in a Helm repository.' This distinguishes it from siblings like get_versions or get_values, which target known chart names. The OCI caveat further clarifies scope.
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 states when to use this tool vs alternatives: for OCI registries you must know the chart name and call get_versions/get_values directly. This provides a clear exclusion condition and directs to sibling tools.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.
