mcp-codesearch

by michaelkrauty

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.8.0
Disambiguation5/5
Every tool targets a distinct action: index discovery, deletion, cleanup, status, reindex, vocabulary repair, preview, and five clearly differentiated search modes (semantic, multi-repo, changed-files, similar-snippet, and symbol references). Delete_collection and cleanup_orphans both delete indexes, but their explicit vs. automatic orphan-detection purposes are clearly separated by the descriptions.
Naming Consistency4/5
The set is mostly imperative snake_case verb_noun (list_collections, delete_collection, force_reindex, repair_vocabulary), but search tools mix conventions: code_search is noun-first while search_multiple/search_changed use a verb-first style, and index_status is a noun phrase. The inconsistency is minor and all names remain readable and predictable in context.
Tool Count5/5
Twelve tools is within the well-scoped range and each tool covers a distinct indexing or search need rather than bloating the surface. The variety of search entry points is justified by materially different query semantics and use cases.
Completeness5/5
The server covers the full lifecycle: auto-indexing/creation via search or force_reindex, status inspection, preview, deletion, orphan cleanup, and vocabulary repair. Search coverage is similarly complete with semantic, multi-repo, changed-file, similar-code, and reference lookup, leaving no obvious dead ends for code-search workflows.
Average 4.2/5 across 12 of 12 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 30 commits in the last 12 weeks
- Last stable release on September 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
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. The phrase 'Force complete re-indexing' implies potential destructiveness or heavy resource usage, but the description does not elaborate on side effects (e.g., index reset, downtime, performance impact), making it insufficiently transparent.
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 brief with only two sentences and an Args/Returns block, which is front-loaded and efficient. However, the Args block redundantly lists the parameter already defined in the schema, slightly reducing conciseness value.
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 potentially heavy operation (full re-indexing), the description lacks critical context such as prerequisites (e.g., existing index), impact on ongoing operations, or time expectations. The output schema exists but the description only says 'Indexing result summary,' which is vague. The description is adequate but not complete for safe usage.
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 0% description coverage, so the description must compensate. It explains 'path' as 'Root path of codebase,' which adds basic meaning beyond the schema's type/name, but it lacks details on path format, allowed values, or constraints. This is minimal improvement, hence a mid-range score.
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 explicitly states 'Force complete re-indexing of a codebase,' combining a strong verb ('Force complete re-indexing') with the resource ('codebase'). This clearly distinguishes it from sibling tools like code_search or index_status, which serve different purposes.
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 or why to use this tool, nor when to avoid it. There is no mention of prerequisites, conditions for use, or comparison to alternatives like preview_index or index_status, leaving the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses return of ranked similar snippets and the exclude_self feature, but does not mention permissions, side effects, or 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with Args and Returns sections, but somewhat verbose. Could be more concise while retaining clarity.
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?
Description covers purpose, parameters, and returns. Output schema exists, so return format is sufficiently explained. Adequate for a search tool with multiple parameters.
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 coverage is 0%, so description carries full burden. Each parameter is described in the Args section, adding meaning beyond schema property titles.
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?
Description states 'Find code similar to the provided snippet' clearly indicating verb and resource. However, it does not explicitly differentiate from sibling tools like code_search or find_references.
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 on when to use this tool versus alternatives. Does not mention prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses return values (file count, last indexed, pending changes) but does not mention side effects, error conditions, or permissions needed. It provides some behavioral insight but not comprehensive.
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 extremely concise, with three sentences: purpose, args, returns. It is front-loaded with the main action and structured logically. No wasted words.
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 status-check tool with an output schema, the description is mostly complete. However, it lacks usage guidelines and does not cover edge cases or error behavior. Given the sibling set, more contextual help would be beneficial.
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 coverage is 0%, so the description must explain parameters. It provides a clear explanation for the single 'path' parameter ('Root path of codebase'), adding meaning beyond the schema's title and default value.
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 'Check indexing status for a codebase' with a specific verb and resource. It distinguishes the tool from siblings like 'force_reindex' or 'code_search', which have different purposes.
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, when not to, or how it compares to alternatives. There is no mention of prerequisites or context for choosing this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains the deletion effect and parameter options, but omits details on irreversibility, permissions, or side effects. This is adequate but not comprehensive.
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 and well-structured with 'Args' and 'Returns' sections. Every sentence adds value, including the note on orphan cleanup. No wasted words.
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?
While the tool has an output schema (not shown) and parameter usage is explained, the description lacks error handling, prerequisites, or differentiation from 'cleanup_orphans'. Adequate but leaves some gaps.
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 0% schema description coverage, the description compensates by explaining the roles of 'path' and 'collection_id' and their mutual exclusivity, adding significant meaning beyond the schema.
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 deletes an index for a codebase, specifying two methods via 'path' or 'collection_id'. This differentiates it from sibling tools like 'list_collections' and 'cleanup_orphans'.
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 advises using 'collection_id' for orphaned collections that show as 'unknown' in 'list_collections', and notes the exclusive requirement ('either path or collection_id, but not both'). It provides clear context but could explicitly compare with 'cleanup_orphans'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains default parameter values and return type but does not disclose behavioral traits such as performance, side effects, or whether network calls are required.
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 (about 100 words), well-structured with a heading, parameter list, and return description. Every sentence adds value 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?
The description covers all parameters and return type. It lacks edge case handling (e.g., symbol not found) but is largely complete for a find-references tool with an output schema present.
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?
With 0% schema description coverage, the description compensates fully: each parameter (symbol, path, limit, include_definition, output_format) has a clear explanation including defaults and enum values, adding meaning beyond the schema.
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 finds all usages/references of a symbol, specifying function, class, or variable. This distinguishes it from siblings like code_search and find_similar.
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 does not explicitly state when to use this tool versus alternatives like code_search or find_similar. It implies use for references but lacks exclusion criteria or context for when not to use.
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?
Since no annotations are provided, the description fully conveys behavioral traits: it auto-indexes on first use and incrementally updates, which are important side effects. It also describes the output format, but could further detail indexing impact on performance or storage.
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 well-structured with a clear purpose statement, followed by organized arguments with details, and a returns section. Every line adds value, no fluff, and it remains concise despite covering many parameters.
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 (8 parameters, output schema exists), the description is complete. It covers purpose, all parameters with examples, behavioral notes, and return format. No critical information is missing for an agent to invoke it correctly.
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?
With 0% schema description coverage, the description compensates excellently. It explains each parameter's purpose, provides special syntax for the query, and gives defaults and examples. This adds significant meaning beyond the schema, making the tool usable.
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 'Semantic code search' as the tool's purpose, specifying it searches code using natural language. It effectively distinguishes itself from sibling tools like index_status or delete_collection, which are indexing or management tools, making its core function of searching evident.
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 like search_multiple or find_similar. It lacks explicit context for choosing it over other search or reference tools, leaving the agent without comparative usage instructions.
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?
No annotations are provided, so the description carries the full burden. It clearly states 'without actually indexing,' indicating a read-only preview. However, it does not elaborate on side effects or safety beyond that.
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 extremely concise with no wasted words. It uses a clear structure with parameter list and return value, making it easy to parse.
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?
The description covers the preview behavior and parameter semantics adequately. It mentions the return type. Given that an output schema exists, the lack of detailed return format is acceptable. Slightly more context on when to use vs siblings would improve it.
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?
With 0% schema description coverage, the description provides meaningful explanations for all three parameters: path as root path, show_files with condition, limit with dependency. This adds significant value beyond the schema.
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 'Preview what would be indexed without actually indexing,' which is a specific verb+resource. This distinguishes it from sibling tools like force_reindex or delete_collection.
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 use for dry-run checking but does not explicitly state when to use or mention alternatives. No when-not-to-use guidance is provided.
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?
With no annotations, the description carries the full burden. It discloses the filtering mechanism (payload filter), the fallback for large change sets, and the absence of candidate-pool loss, which is genuinely useful behavioral context. However, it doesn't mention read-only nature or potential performance implications, leaving a small gap.
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 structured with a clear first sentence, a technical explanation paragraph, and a tidy args list. At ~150 words, it's slightly verbose but not wasteful; every sentence adds value. The structure aids scanning.
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 an output schema (though not shown), the description covers the essential aspects: what it does, key parameters, and a return statement. It doesn't address edge cases like empty results or error handling, but given the simplicity, it's largely complete. The fallback behavior adds depth.
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?
The input schema has 0% description coverage, so the description must compensate. It does so effectively by explaining every parameter in the Args section: query, path, since, limit, and output_format, including the meaning of 'since' with examples. This fully compensates for the schema's silence.
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 and resource: 'Search only in files that have changed since a given commit or time.' This clearly distinguishes it from generic search tools like code_search or find_similar by scoping to changed files, making its 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 opening sentence implies when to use it: when you want results restricted to changed files. While it doesn't explicitly name alternatives or exclusions, the clear scope effectively guides selection among siblings. A more explicit 'use instead of X when' would push this higher.
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?
No annotations are provided, so the description carries the full burden. It discloses that it lists 'indexed' codebases and what it returns. It does not mention side effects (unlikely for a list) or performance implications, but for a read-only list operation, the disclosed information is sufficient. There is no contradiction with annotations (none present).
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 extremely concise: two sentences with no extraneous information. It front-loads the action and immediately specifies the return format. 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?
With zero parameters, a simple operation, and an output schema available (indicated by 'Has output schema: true'), the description is complete. It clearly states what the tool does and what it returns, leaving no gaps for an agent to call it incorrectly.
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?
There are no parameters, so schema coverage is 100% (vacuous). The description correctly adds no parameter details because none exist. This matches the baseline for zero-parameter tools.
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 clear verb ('List') and resource ('all indexed codebases'), and specifies the return value (collection names and paths). This distinguishes it from siblings like delete_collection and code_search, which are clearly different operations. The purpose is 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 its usage: to see all indexed codebases. It does not explicitly mention alternatives or carve out when not to use it, but the context is clear—this is a simple listing operation. Given the sibling tools, an agent can infer it's for initial exploration, though explicit guidance would be stronger.
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?
With no annotations, the description carries the full behavioral burden, and it delivers: it discloses that repair does not rewrite Qdrant, may complete a pending interrupted deletion, clears ambiguous partial paths before rebuilding, removes stale registrations, and processes collections one at a time. These are concrete, non-obvious behaviors beyond the tool name.
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 longer than typical but every sentence adds meaningful detail about modes, side effects, recovery behavior, and concurrency. It is front-loaded with the core purpose and then expands into necessary edge cases without fluff.
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 maintenance tool with no annotations, the description covers purpose, parameter behavior, side effects, recovery semantics, concurrency implications, and the distinction between repair and full modes. An output schema exists, so return-value documentation is not required here. This is a complete enough description for an agent to invoke the tool correctly.
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 0%, so the description must explain the parameters. It functionally defines both: "repair" enables reconstruction and stale-registration removal, while "full" re-registers every live collection and requires repair. It does not spell out the false/default behavior of each flag, but the meaning is strongly implied and the schema supplies defaults.
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 opens with a specific verb and resource: "Audit or repair codesearch's global sparse vocabulary." This clearly distinguishes the tool from siblings like list_collections, code_search, and cleanup_orphans, which operate on different concerns such as collection listing, search, or orphan cleanup.
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 clear context for when to use the tool: audit-only by default, repair mode for reconstructing mismatched contributions and removing stale registrations, and full mode for correcting token-frequency drift. It also advises re-running the audit if indexing changes the collection set concurrently. It does not explicitly name alternatives or exclusions, so it stops 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It details the conservative deletion logic: deletes only when path is known and confirmed absent, and keeps collections with unknown/inaccessible paths to avoid mistaking temporary unavailability for deletion.
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 well-structured: a one-line summary, then detailed behavioral explanation, a note about when to run, and a return type summary. Every sentence is necessary and informative, with no redundancy.
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 zero parameters and an output schema present, the description fully covers what the tool does, when to use it, its conservative behavior, and what it returns. It is complete and self-sufficient.
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 tool has zero parameters, so the description does not need to explain parameters. The baseline for 0 parameters is 4, and the description adds value by explaining behavior, not parameters.
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 starts with 'Find and delete orphaned collections whose codebase directory is gone,' which is a specific verb+resource combination that clearly distinguishes it from sibling tools like 'delete_collection' (deletes a specific collection) or 'list_collections'.
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 guidance on when to use: 'Run this while any removable or network volumes holding indexed codebases are mounted.' It also explains when it does not delete (path unknown or inaccessible), though it does not explicitly name alternative tools.
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?
No annotations provided, so description carries full burden. It explains incremental indexing, parallel search, latency bounded by slowest codebase, and global ranking with RRF. This is thorough behavioral disclosure for a search tool.
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 well-structured: a clear header sentence, a paragraph explaining the parallel indexing behavior, a list of arguments with explanations, and a return line. Every sentence is valuable and not verbose.
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 7 parameters, 2 required, and the existence of an output schema, the description covers purpose, all parameters, and output behavior. It does not explain error handling or prerequisites, but with sibling tools handling indexing status, it is sufficiently complete.
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?
Schema description coverage is 0%, meaning properties have no descriptions in the schema. The description compensates fully by explaining each parameter (query, paths, mode, limit, language, output_format, global_ranking) with meaningful details beyond types and enums.
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 'Search across multiple codebases concurrently', which is a specific verb+resource. It distinguishes from siblings like code_search (single codebase) and find_similar.
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 explains when to use (multiple codebases) but does not explicitly state when not to use or provide alternatives. However, the context of sibling tools implies single-codebase search should use code_search.
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:

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

Score Badge

Copy to your README.md:

[![mcp-codesearch MCP server](https://glama.ai/mcp/servers/michaelkrauty/mcp-codesearch/badges/score.svg)](https://glama.ai/mcp/servers/michaelkrauty/mcp-codesearch)

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/michaelkrauty/mcp-codesearch'

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