ArtifactHub MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose focused on different aspects of Helm chart data retrieval. helm-chart-info provides metadata, helm-chart-template gets specific template files, helm-chart-templates-fuzzy-search searches template content, helm-chart-values retrieves values.yaml, and helm-chart-values-fuzzy-search searches within values.yaml. There is no overlap in functionality.
Naming Consistency5/5
All tools follow a consistent 'helm-chart-' prefix with descriptive suffixes (info, template, templates-fuzzy-search, values, values-fuzzy-search). The naming pattern is uniform throughout, using kebab-case consistently and clearly indicating each tool's specific function.
Tool Count5/5
With 5 tools, this server is well-scoped for its purpose of retrieving and searching Helm chart data from Artifact Hub. Each tool serves a distinct and necessary function without redundancy, making the count appropriate for the domain.
Completeness4/5
The toolset provides comprehensive coverage for retrieving and searching Helm chart data, including metadata, templates, and values. A minor gap exists in the inability to list or browse available charts (e.g., search or list charts by criteria), but the core operations for working with specific charts are well-covered.
Average 3.1/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/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. It states the tool retrieves template content but doesn't mention critical aspects like authentication requirements, rate limits, error handling (e.g., what happens if the file doesn't exist), or the format of the returned content. For a tool that interacts with an external service (Artifact Hub), this is a significant gap in 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('Get the content'), making it easy to parse. There's no wasted verbiage or redundant information.
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?
Given the complexity of interacting with Helm charts and Artifact Hub, the description is incomplete. With no annotations and no output schema, it fails to address key behavioral aspects (e.g., authentication, errors, return format) and doesn't differentiate from sibling tools. While the schema covers parameters well, the overall context for safe and effective use is lacking.
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 doesn't add any parameter-specific information beyond what's already in the schema (which has 100% coverage). It implies the tool operates on Helm charts in Artifact Hub, but the schema already describes parameters like 'chartRepo', 'chartName', and 'filename' with clear descriptions. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate with additional insights.
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 clearly states the action ('Get the content') and resource ('a template file from a Helm chart in Artifact Hub'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'helm-chart-templates-fuzzy-search' (which likely searches templates rather than retrieving exact files) or 'helm-chart-info' (which provides chart metadata), leaving some ambiguity about when to choose this specific tool.
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 sibling tools like 'helm-chart-templates-fuzzy-search' (for searching templates) or 'helm-chart-values' (for retrieving values files), nor does it specify prerequisites or constraints beyond what's implied by the parameters. This lack of context could lead to incorrect tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions 'fuzzy search' (implying approximate matching), it doesn't describe what 'fuzzy' means operationally, whether it searches both filenames and contents simultaneously, what the output format looks like, or any performance/rate limit considerations. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.
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 a single, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized and front-loaded with the essential information, making every word earn its place.
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 search tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'fuzzy' means in practice, what the search results look like, whether it searches recursively through nested templates, or how it handles multiple matches. The agent would need to guess about important behavioral aspects.
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 description coverage is 100%, so the schema already documents all four parameters thoroughly. The description doesn't add any parameter-specific context beyond what's in the schema (e.g., it doesn't explain what constitutes a valid 'chartRepo' format or how 'searchQuery' fuzzy matching works). Baseline 3 is appropriate when schema does the heavy lifting.
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 clearly states the action ('fuzzy search') and target ('through all template filenames/contents in a Helm chart'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from its sibling 'helm-chart-template' (which presumably retrieves specific templates) or 'helm-chart-values-fuzzy-search' (which searches values instead of templates), missing full 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 prefer this over 'helm-chart-template' for retrieving specific templates, or when to use 'helm-chart-values-fuzzy-search' for searching values instead of templates. There's no context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. It states the tool 'Get[s] the values.yaml file', implying a read-only operation, but does not clarify aspects like authentication requirements, rate limits, error handling, or the format of the returned values. This leaves significant gaps in understanding the tool's behavior beyond its basic purpose.
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 a single, direct sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded with the key action and resource, making it easy to parse quickly, and every part of the sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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, no output schema, no annotations), the description is minimally complete for a read operation. It specifies the resource and source (Artifact Hub), but lacks details on output format, error cases, or integration with siblings. This is adequate for basic use but leaves room for improvement in guiding effective tool selection and invocation.
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 input schema has 100% description coverage, clearly documenting all three parameters (chartRepo, chartName, version) with their types and optionality. The description does not add any additional semantic details beyond what the schema provides, such as examples or constraints, so it meets the baseline for adequate but not enhanced parameter understanding.
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 clearly states the action ('Get') and the resource ('values.yaml file for a specific Helm chart from Artifact Hub'), making the purpose immediately understandable. However, it does not explicitly differentiate this tool from its sibling 'helm-chart-values-fuzzy-search', which likely serves a similar purpose with different functionality, leaving some ambiguity in sibling distinction.
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 its siblings, such as 'helm-chart-info' or 'helm-chart-values-fuzzy-search'. It lacks any context about prerequisites, alternatives, or specific scenarios where this tool is preferred, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It doesn't disclose what 'fuzzy search' entails (e.g., case sensitivity, matching algorithm), what the output format looks like, whether it's a read-only operation, or any rate limits/permissions needed. The description states the basic function but lacks operational details.
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 a single, efficient sentence that immediately conveys the core functionality. Every word earns its place with no redundant phrases or unnecessary elaboration. It's appropriately sized for a search tool with well-documented parameters.
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 search tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'fuzzy search' means operationally, what the return structure looks like, or how results are presented. The agent must guess about output format and search behavior, which is inadequate given the tool's complexity.
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 description coverage is 100%, providing clear documentation for all parameters. The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline of 3. It doesn't explain relationships between parameters (e.g., how chartRepo and chartName combine to identify a chart) or provide examples of searchQuery syntax.
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?
The description clearly states the specific action ('fuzzy search') and target resource ('properties/values/comments in a Helm chart's values.yaml file'), distinguishing it from sibling tools like 'helm-chart-values' (likely retrieves values) and 'helm-chart-templates-fuzzy-search' (searches templates). It uses precise terminology that aligns with Helm ecosystem concepts.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools like 'helm-chart-values' (which might retrieve the entire values file) or 'helm-chart-templates-fuzzy-search' (which searches templates instead of values), leaving the agent to infer usage context from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what information is returned. It doesn't disclose behavioral aspects like authentication requirements, rate limits, error conditions, or whether this is a read-only operation (though implied by 'Get information').
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?
Single sentence with zero waste - every word contributes to understanding the tool's purpose. Front-loaded with the core action and resource, followed by specific details about what information is retrieved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with 2 parameters and 100% schema coverage, the description is minimally adequate but lacks behavioral context needed when annotations are absent. No output schema exists, so description doesn't explain return format beyond listing data types.
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 description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional parameter context beyond implying these identify a specific chart. Baseline 3 is appropriate when schema does the heavy lifting.
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 clearly states the action ('Get information') and resource ('Helm chart from Artifact Hub'), specifying what information is retrieved (ID, latest version, description). It distinguishes from siblings by focusing on basic metadata rather than templates or values, though it doesn't explicitly name alternatives.
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 description implies usage for retrieving basic chart metadata, but provides no explicit guidance on when to use this tool versus sibling tools like helm-chart-template or helm-chart-values. No prerequisites, exclusions, or comparison to alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![artifacthub-mcp MCP server](https://glama.ai/mcp/servers/hd-deman/artifacthub-mcp/badges/card.svg)](https://glama.ai/mcp/servers/hd-deman/artifacthub-mcp)

Score Badge

Copy to your README.md:

[![artifacthub-mcp MCP server](https://glama.ai/mcp/servers/hd-deman/artifacthub-mcp/badges/score.svg)](https://glama.ai/mcp/servers/hd-deman/artifacthub-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/hd-deman/artifacthub-mcp'

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