Skip to main content
Glama
perfectra1n

kubesearch-mcp

by perfectra1n

Grep HelmRelease values

grep_values
Read-onlyIdempotent

Search Helm values across indexed Flux HelmReleases and Argo Applications to find real-world examples of config keys or values, returning matching key paths, snippets, and source files.

Instructions

Full-text grep across the Helm spec.values of every indexed HelmRelease/Application (substring match). Great for finding real-world examples of a config key or value, e.g. 'cert-manager.io', 'nodeSelector', 'gatus'. Returns the matched key path, a snippet, and the source file. Mirrors the kubesearch.dev /grep search.

Input Schema

NameRequiredDescriptionDefault
limitNoMax number of matching files to return.
queryYesSubstring to grep for in values (keys or values), e.g. 'cert-manager.io'.
offsetNoSkip this many matches (results are ranked by repo stars).
case_sensitiveNoMatch case-sensitively.

Output Schema

NameRequiredDescriptionDefault
queryYes
shownYes
offsetYes
resultsYes
grep_urlYes
has_moreYes
total_filesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.3.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/closed-world, so the bar is lower; the description adds that matching is substring-based and scoped only to indexed releases' values, plus what comes back (key path, snippet, source file). It notes the kubesearch.dev /grep equivalence, useful for predicting result shape, though ranking/pagination behavior is left to the schema.

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?

Three tight sentences: what it greps, what it's good for with examples, what it returns. Nothing redundant and the core operation is front-loaded.

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?

For a read-only search tool with full schema documentation, complete annotations, and an output schema covering return values, the description supplies everything else an agent needs: scope, match semantics, and intended use case.

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 `query`, `limit`, `offset`, and `case_sensitive` are all documented in-schema; the description's only added semantics is example query terms. Baseline 3 applies since the schema carries the parameter burden.

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 — full-text grep across the Helm `spec.values` of indexed HelmReleases/Applications — and pins the matching mode (substring). The scope is precise enough to separate it from search_releases and repo_grep without opening any schema.

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

Usage Guidelines4/5

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

Gives clear when-to-use guidance: finding real-world examples of a config key or value, with concrete query examples ('cert-manager.io', 'nodeSelector'). It does not name an alternative or exclusion (e.g. when to prefer search_releases or repo_grep), so it falls short of a 5.

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