kubesearch-mcp

Get HelmRelease details

get_release

Read-onlyIdempotent

Fetch details for a kubesearch.dev chart release by id, then choose summary, deployments, or values views to inspect community configurations and drill into repo-specific settings.

Instructions

Get details for one chart by its kubesearch.dev release id (the id from search_releases, e.g. 'ghcr.io-home-operations-charts-mirror-cert-manager'). Three views, controlled by view:

summary (default): a compact digest of how the community configures the chart — the most commonly-set spec.values paths with their typical values, plus a couple of full example configs. Start here.
deployments: the paginated list of every repo deploying the chart (no values) — use it to find a repo to drill into.
values: the full parsed spec.values for selected deployments — narrow with repo and/or value_paths to fetch just the config (or subtree) you care about. This is the drill-down; prefer summary first. Note: chart_source_url is the normalized kubesearch.dev grouping key, not necessarily the pullable chart. For chartRef/OCIRepository releases the real chart is in source_urls (group) and each deployment's source_url + source_tag; resolved_chart surfaces the true chart name when it differs from chart. Confirm by cloning the deployment's repo (repo_clone) and reading its OCIRepository source.yaml.

Input Schema

Name	Required	Description	Default
`id`	Yes	The release id / slug, e.g. 'ghcr.io-home-operations-charts-mirror-cert-manager'.
`top`	No	`summary` view: number of common value paths to return.
`repo`	No	`values` view: restrict to one repo (e.g. 'onedr0p/home-ops').
`view`	No	summary = community config digest (default); deployments = paginated repo list; values = full config drill-down.	summary
`limit`	No	Page size for `deployments`/`values` views.
`offset`	No	Pagination offset for `deployments`/`values` views.
`examples`	No	`summary` view: number of full example configs to include.
`value_paths`	No	`values` view: only return these value-path subtrees, e.g. ['server.persistentVolume','server.retentionPeriod']. Paths from the summary view's common_settings work as-is, including array forms like 'route.hostnames[]'.

Output Schema

Name	Required	Description	Default
`id`	Yes
`view`	Yes
`chart`	Yes
`shown`	No
`offset`	No
`has_more`	No
`next_step`	No
`top_repos`	No
`deployments`	No
`source_urls`	Yes
`matched_repos`	No
`omitted_count`	No
`kubesearch_url`	Yes
`resolved_chart`	Yes
`values_summary`	No
`chart_source_url`	Yes
`deployment_count`	Yes
`chart_source_ambiguous`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.3.0Oct 28, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With read-only, idempotent, closed-world annotations already covering the safety profile, the description adds substantial behavioral context: the three view modes, pagination in `deployments`/`values`, and the distinction between `chart_source_url`, `source_urls`, `source_url`/`source_tag`, and `resolved_chart`. The caveat about confirming OCIRepository charts via `repo_clone` is unusually useful for correct invocation.

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?

The description is front-loaded with the core purpose, then structured around the `view` options and a targeted caveat. It is dense but largely purposeful; the final note is valuable, though the description is longer than strictly minimal.

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

Completeness5/5

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

Given the tool's complexity, the presence of an output schema, full schema coverage, and strong annotations, the description is complete enough for an agent to call it correctly. It covers the main view modes, pagination behavior, drill-down guidance, and the important chart-reference caveat.

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

Parameters5/5

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

Although schema coverage is already 100%, the description adds real meaning beyond the schema by explaining what `view` modes do, how `repo` and `value_paths` narrow the `values` view, and that summary paths can be reused as `value_paths` including array forms. This helps the agent choose parameters correctly rather than merely restating field descriptions.

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 gives a specific verb and resource: get details for one chart using a kubesearch.dev release id. It immediately disambiguates the id source by naming `search_releases` and gives an example id, so the agent can distinguish this from sibling search tools.

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

Usage Guidelines5/5

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

It explicitly defines the three view modes, their defaults, and when to use each: start with `summary`, use `deployments` to find a repo, and use `values` as the drill-down. It also warns to prefer `summary` first, which is direct usage guidance.

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

Deploy Server