kubesearch-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: the kubesearch_* tools search the index, while the repo_* tools operate on cloned repositories. Even the two grep tools are well-separated by scope (index-wide vs. within a clone).
Naming Consistency5/5
The naming follows a consistent verb_noun pattern with a clear prefix distinction: kubesearch_search_releases, kubesearch_get_release, repo_clone, repo_list_files, etc. The two prefixes intentionally separate functional domains, and all names are descriptive and predictable.
Tool Count5/5
10 tools is a well-scoped count for the server's purpose, covering both search and repository exploration without redundancy. Each tool earns its place in the set.
Completeness5/5
The tool surface provides end-to-end coverage: searching for releases and images, retrieving release details, grepping values, checking cache status, and drilling into real repositories with clone/list/read/grep/cleanup. No obvious dead ends or missing operations for the domain.
Average 4.5/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 29 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnly, idempotent, and closed-world behavior. The description adds valuable behavioral details: search scope ('text contents'), optional glob filtering, return format ('file paths, line numbers, and matching lines'), and truncation handling. This goes beyond annotation basics and helps the agent predict tool output.
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 sentences, all informative. The first sentence captures the core action, the second adds an optional parameter, and the third provides practical usage advice. No filler or repetition; front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with output schema and rich annotations, the description covers key contextual aspects: prerequisite (cloned repository), optional filter, return format, and behavior on truncation. It doesn't mention case_sensitive or limit explicitly, but the schema fully documents those, and the truncation guidance substitutes for deeper pagination details.
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 coverage is 100%, with each parameter including a description, so the baseline is 3. The description does not significantly expand on parameter meaning beyond what the schema provides—it only restates 'by handle' and 'glob' in narrative form. No new parameter-level insight is added.
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 states a specific verb ('Search') and a specific resource ('text contents of a previously cloned repository'), immediately distinguishing it from sibling tools like repo_list_files (list files) and repo_read_file (read one file). It also specifies the output (file paths, line numbers, matching lines), making the tool's purpose unambiguous.
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?
The description implies the prerequisite of a prior repo_clone operation via 'previously cloned repository (by handle)', and offers explicit guidance for handling truncated results: 'narrow the search with a longer query or a glob rather than paging.' It does not explicitly mention when to use this over kubesearch_grep_values, but given sibling list and context, the usage is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds useful behavioral context beyond annotations: the handle must come from repo_clone, and listing can be scoped via sub-path and glob. No contradictions.
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?
Two sentences, front-loaded with the core purpose, followed by optional parameters and a necessary prerequisite. Every phrase earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list files tool with an output schema, the description covers the prerequisite (handle from repo_clone) and options (path, glob). It does not explicitly state whether the listing is recursive, but the glob pattern '**/*.yaml' implies recursive behavior, and the output schema likely clarifies return structure. No major gaps.
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%, with each parameter (handle, path, glob) fully described in the input schema. The description restates these options but adds no new semantic detail beyond examples already present in the schema, so baseline 3 is appropriate.
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 a specific action and resource: 'List files in a previously cloned repository (by handle)'. This distinguishes it from sibling tools like repo_read_file and repo_grep, which operate on file contents. The optional path and glob filters are additional specificity.
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?
The description gives a clear prerequisite via 'Use the handle returned by repo_clone' and explains optional scoping/filtering with path and glob. It does not explicitly name alternatives or when-not-to-use conditions, but the context is strong enough for an agent to understand 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses return format (matched key path, snippet, source file), scope (every indexed HelmRelease/Application), and matching semantics (substring match). Annotations already declare read-only and idempotent, so the description adds behavioral context without contradiction, though it omits potential edge cases like rate limits.
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 sentences, front-loaded with the action, containing concrete examples and essential return details. No redundant or filler content.
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?
The description is complete for a simple grep tool: it defines the target space, matching behavior, return structure, and an external reference. Combined with the detailed schema, annotations, and output schema, nothing critical is missing.
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 coverage is 100% with clear descriptions for all four parameters, so the baseline is 3. The description provides concrete query examples ('cert-manager.io', 'nodeSelector') that illustrate usage, but it doesn't explain limit, offset, or case_sensitive beyond what the schema already offers.
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 a specific action: full-text grep across the Helm spec.values of indexed HelmRelease/Application objects. It distinguishes itself from sibling tools (e.g., kubesearch_search_releases, repo_grep) by targeting values and returning key paths/snippets. The kubesearch.dev reference adds precise context.
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?
It explicitly states the tool is useful for finding real-world examples of config keys/values, which gives clear usage context. However, it does not explicitly mention when not to use it or name alternatives, so it falls just 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent hints. The description adds behavioral details about binary files being refused and large files being truncated, which goes beyond the structured annotations.
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?
Two sentences, front-loaded with the action, and each sentence earns its place without unnecessary elaboration.
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?
With a rich output schema and good annotations, the description covers the key prerequisites and constraints (prerequisite handle, binary refusal, truncation) sufficiently for an agent to use the tool correctly.
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 covers 100% of parameters with descriptions. The description reinforces the handle's origin but doesn't add significant new semantic information beyond what the schema already provides.
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 tool reads a text file from a cloned repository using a handle and relative path. It also mentions binary refusal and truncation, which distinguishes it from sibling tools like repo_list_files and repo_grep.
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?
The description provides clear context: it works on previously cloned repos and instructs to use the handle from repo_clone. It doesn't explicitly name alternatives, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds value by disclosing exactly what status information is returned (release tag, load time, cache directory, row counts), which goes 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence front-loads the action and output fields; the second provides a succinct use case. Every word earns its place.
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 simple read-only status tool with no parameters and an output schema, the description fully covers purpose, output content, and usage context. It is entirely adequate given the tool's low complexity and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline for parameter semantics is 4. The description correctly avoids inventing parameter details, and the input schema confirms no parameters exist, so nothing is missing.
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 tool reports freshness and size of cached data, enumerating specific fields (release tag, load time, cache directory, row counts). This unambiguously distinguishes it from sibling search tools, which perform queries rather than status inspection.
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?
It explicitly notes the tool is 'useful to confirm how current the search data is', giving a clear use case. However, it doesn't explicitly mention when not to use it or name alternatives, though sibling tools imply those are for searching, not status checking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and readOnlyHint=false. The description adds valuable lifecycle context: clones are temporary, have a TTL, and are auto-deleted. This goes beyond annotations to explain why the tool is optional, and does not contradict destructiveHint=false since the clone is temporary.
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 two sentences, front-loaded with the action ('Delete a temporary clone'), and both sentences serve a purpose: the first states the action and rationale, the second clarifies optionality. No wasted words.
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 single-parameter tool with an output schema and strong annotations, the description covers the purpose, usage context, and lifecycle behavior (TTL, auto-deletion). It is fully sufficient for an agent to decide when and why to invoke it.
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 coverage is 100% with the parameter 'handle' described as 'The clone handle from repo_clone.' The tool description merely references this relationship without adding new meaning, so the schema carries the full semantic 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?
The description uses the verb 'Delete' with a specific resource ('temporary clone created by repo_clone') and clearly distinguishes this from sibling tools like repo_clone, which creates clones. The qualifier 'temporary' adds necessary scope.
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 states when to use it (to free disk before TTL) and when not to (since clones auto-delete after inactivity, making it optional). The alternative is effectively doing nothing, which the description implies by calling it 'polite'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the readOnly/idempotent annotations by disclosing substring/case-insensitive matching, grouping by chart source, ranking by public home-ops repo usage, normalization of chart_source_url, and the resolved_chart flag. This is rich behavioral context.
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?
Two compact paragraphs with the core statement first and a clearly separated note on normalization. Every sentence earns its place, though the normalization note is dense and might be overwhelming at first glance.
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 output schema and annotations, the description covers search semantics, result shape, grouping caveats, and the next-step tool to use. It provides enough detail for an agent to invoke correctly and interpret results properly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters at 100%, and the description adds real value by specifying substring/case-insensitive matching, giving query examples, and clarifying output grouping semantics. It does not add much for limit/offset, but the schema already handles those.
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?
Clearly states it searches kubesearch.dev for Flux HelmReleases / Argo Applications by chart name substring, case-insensitively. It distinguishes itself from kubesearch_get_release by noting results include an id for full details, and from image/grep siblings by its chart-name scope.
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?
Frame as 'mirrors the kubesearch.dev homepage search' with examples, and explicitly directs the agent to pass returned ids to kubesearch_get_release for full details. It does not enumerate when not to use it relative to image/grep tools, but the used context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent behavior, so the description adds value by disclosing the search semantics (substring, case-insensitive), the data source (public home-ops clusters), and the exact return contents (repositories, tags, deployment counts, sample repos). This goes beyond the annotations and enriches the agent's understanding.
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?
Two focused sentences with no fluff. The first sentence front-loads the core action and scope, the second describes return values and equivalence. Every clause earns its place, making it easy to parse quickly.
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 output schema exists, the description doesn't need to detail return types. It covers the essential context: what the tool does, what data it searches, matching behavior, and result granularity. With annotations handling safety and schema handling parameters, the description is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions, so the baseline is 3. The description adds extra meaning by explaining the query parameter's matching semantics ('substring match, case-insensitive') and what the results represent (tag counts, deployment usage, sample repos), which complements the schema without redundancy.
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 uses a specific verb ('Search') and resource ('container image repositories'), and adds key semantics like substring match and case-insensitivity. It clearly distinguishes from sibling tools (search_releases, grep_values) by focusing on image repositories, and even references the equivalent kubesearch.dev /image search.
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?
The description clearly states the context (searching image repos across public home-ops clusters) and the matching behavior. However, it lacks explicit 'when not to use' or alternative tool references, though sibling names make the distinction obvious. This is close to a 5 but missing an explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses key behaviors: shallow clone, sandboxed environment, size/time limits, auto-deletion after TTL, and the nature of the return value (handle and curated file tree). It also notes that the repo must be public and that indexed names resolve to real clone URL and branch, adding meaningful context.
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 concise yet thorough, with four sentences that each add value: purpose, input types and resolution, clone characteristics and TTL, and output/lifecycle. It is well-structured, front-loading the main action, and contains no wasted words.
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 clone tool with one parameter and an output schema, the description covers all essential aspects: what it does, input format, behavioral constraints (shallow, sandboxed, time-limited), output (handle + curated tree), and follow-up action (cleanup). The output schema explains return values, so the description need not list them, and it still manages to be sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the 'repo' parameter as an indexed repo name or full https URL. The description adds value by explaining that indexed names are resolved to their real clone URL and branch, and gives a concrete example. This goes beyond the schema's coverage, so it earns a 4 rather than the baseline 3.
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 tool clones a public Git repository to review files, with a specific verb ('clone') and resource ('repository'). It distinguishes itself from siblings by explaining it returns a handle for use with repo_list_files, repo_read_file, and repo_grep, making its role as an entry point unmistakable.
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?
The description indicates when to use it ('so you can review actual files') and provides lifecycle instructions ('Call repo_cleanup when done'), plus how to use the returned handle with sibling tools. It does not explicitly state alternatives or when not to use it, but the context is clear enough for an agent to select this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses that `chart_source_url` is normalized rather than pullable, that chartRef/OCIRepository releases have real chart info in `source_urls`, and that `resolved_chart` surfaces the true name. It also explains the pagination and view behaviors.
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 structured with bullets, front-loaded with the core purpose, and each sentence adds value (view explanations, caveats, and cross-reference). It is long but earned.
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?
With a rich schema (8 params, enums, defaults) and output schema present, the description covers the tool's complexity thoroughly: it explains all three views, the data nuances, and provides a workflow. Gaps like error handling are not needed given the structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already documents all 8 parameters (100% coverage), the description adds interpretive guidance—e.g., how `value_paths` from summary settings work as-is including array forms, and how `view` controls which parameters apply. It also gives a concrete id example. This exceeds baseline 3.
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 states 'Get details for one chart by its kubesearch.dev release id' with a clear verb and resource. It distinguishes from sibling tools by referencing `kubesearch_search_releases` for the id and describing three specific views (summary, deployments, values) that are unique to this tool.
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 says 'Start here' for summary view, tells users to use deployments to find a repo to drill into, and describes values as the drill-down. It also directs users to `repo_clone` for confirmation, providing alternative navigation.
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:

[![kubesearch-mcp MCP server](https://glama.ai/mcp/servers/perfectra1n/kubesearch-mcp/badges/card.svg)](https://glama.ai/mcp/servers/perfectra1n/kubesearch-mcp)

Score Badge

Copy to your README.md:

[![kubesearch-mcp MCP server](https://glama.ai/mcp/servers/perfectra1n/kubesearch-mcp/badges/score.svg)](https://glama.ai/mcp/servers/perfectra1n/kubesearch-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/perfectra1n/kubesearch-mcp'

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