mcp-codesearch is an MCP server providing AI-powered semantic code search with AST-aware chunking, hybrid vector search, and intelligent indexing for one or more codebases.
Search Tools
code_search – Search using natural language or a rich query syntax (function:name, class:name, path:prefix, file:pattern, -path:exclude, scope:function, etc.); auto-indexes on first use with incremental updates
search_multiple – Search across multiple codebases concurrently, with results grouped per codebase or globally ranked via Reciprocal Rank Fusion
search_changed – Search only files changed since a given git commit or time reference (e.g., HEAD~5, 3.days.ago)
find_similar – Find code snippets semantically similar to a provided code excerpt
find_references – Find all usages/references of a function, class, or variable
Index Management
index_status – Check indexing status (file count, last indexed time, pending changes)
force_reindex – Force a complete re-index of a codebase
preview_index – Preview which files/chunks would be indexed without actually indexing
Collection Management
list_collections – List all indexed codebases and their collection names
delete_collection – Remove the index for a specific codebase
cleanup_orphans – Detect and delete orphaned collections whose directories no longer exist
Key Features
18+ languages with full AST-aware chunking (Python, JS/TS, Go, Rust, Java, C/C++, Ruby, PHP, Swift, Kotlin, Scala, C#, SQL, JSON, YAML, TOML) plus line-based fallback; Jupyter notebook support
Hybrid search combining dense embeddings and sparse TF-IDF with RRF fusion
Query synonym expansion (e.g., fn → function, db → database)
Incremental indexing using mtime+size change detection
Flexible ignore support via .gitignore, .git/info/exclude, and .codesearchignore
Path boosting/demotion based on path patterns (e.g., src/ +10%, vendor/ -25%)
Multiple output formats: text, json, or markdown
Integrates with Git for change-aware search, allowing searches over files changed since a specific revision, and respects .gitignore patterns.
Supports Ollama as an embedding API for semantic code search, providing an OpenAI-compatible endpoint.
Supports OpenAI-compatible embedding APIs for semantic code search, enabling the use of models like text-embedding-3-small.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-codesearch search for function:processData path:src"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for semantic code search with AST-aware chunking, hybrid vectors, and query syntax.
Supports stateless MCP 2026-07-28 requests and legacy MCP clients from the same stdio server through the official Python SDK v2.
Python 3.12+
Linux or macOS (uses POSIX file locking via vector-core; not compatible with Windows)
Qdrant vector database (default: localhost:6333)
An OpenAI-compatible embedding API (e.g., llama.cpp, Ollama, or any /v1/embeddings endpoint; default: localhost:8080)
Related MCP server: codesteer-atlas
Requires vector-core.
pip install git+https://github.com/michaelkrauty/vector-core.git@v1.5.0
pip install git+https://github.com/michaelkrauty/mcp-codesearch.gitOr clone both repos and install locally:
git clone https://github.com/michaelkrauty/vector-core.git
git clone https://github.com/michaelkrauty/mcp-codesearch.git
pip install -e vector-core/
pip install -e mcp-codesearch/# Register with Claude Code:
claude mcp add codesearch -- mcp-codesearch
# Or add to your MCP client config (e.g., claude_desktop_config.json):
# {
# "mcpServers": {
# "codesearch": {
# "command": "mcp-codesearch",
# "env": {
# "VECTOR_QDRANT_URL": "http://localhost:6333",
# "VECTOR_EMBEDDING_URL": "http://localhost:8080",
# "VECTOR_EMBEDDING_MODEL": "your-model-name",
# "VECTOR_EMBEDDING_DIM": "768"
# }
# }
# }
# }Hybrid Search: Dense embeddings + sparse TF-IDF with RRF fusion
AST-Aware Chunking: Tree-sitter extracts functions, classes, methods with context
18 Languages with AST Support: Python, JS/TS, Go, Rust, Java, C/C++, Ruby, PHP, Swift, Kotlin, Scala, C#, SQL, JSON, YAML, TOML (line-based fallback for Bash, HTML, CSS, and other file types)
Query Syntax: function:name, class:name, file:pattern, path:prefix, -path:exclude
Incremental Indexing: Change detection via mtime+size before hashing
Resumable Indexing: Durable batch journal resumes interrupted builds without discarding completed work
Persistent Embedding Reuse: Exact-input cache avoids recomputation across clones and worktrees
Cross-Process Coordination: Global embedding capacity and consistent search/index snapshots
Progress-Aware Operations: Long tool calls emit MCP progress heartbeats so compatible clients can extend request deadlines while indexing continues
Query Preprocessing: Synonym expansion (fn → function, db → database)
Flexible Ignores: Nested .gitignore, .git/info/exclude, and .codesearchignore (gitignore syntax) honored at every directory level
Tool | Description |
| Main search with auto-indexing |
| Search across multiple codebases |
| Search in recently changed files (git-aware) |
| Find code similar to a snippet |
| Find all usages of a symbol |
Tool | Description |
| Check indexing status, file count, pending changes |
| Force complete re-indexing |
| Audit or repair sparse-vocabulary consistency from Qdrant |
| Preview what would be indexed |
Tool | Description |
| List all indexed codebases |
| Remove index for a codebase |
| Remove orphaned collections |
# Natural language (semantic search)
code_search("websocket reconnection logic")
# Function search
code_search("function:handleRequest")
code_search("fn:handleRequest") # alias
# Class search
code_search("class:WebSocketClient")
code_search("cls:WebSocketClient") # alias
# Path filtering
code_search("auth path:src/services")
code_search("test -path:vendor -path:node_modules")
# Filename filtering (glob, case-insensitive, matches filename only)
# Pushed into the retrieval layer when possible, so a match in the named
# file is found even if it would rank below the candidate pool
code_search("connection pooling file:db.py")
code_search("schema migration file:*.sql")
# Struct search (Rust, C, Go)
code_search("struct:Message")
# Combined
code_search("function:process_data path:src -path:test")
# Exact phrase
code_search('"exact function name"')Common abbreviations automatically expanded:
fn, func → function
cls → class
db → database
ws → websocket
auth → authentication, authorization
req, res → request, response
# Alternative function search aliases
code_search("def:processData")
code_search("method:handleRequest")
# Type/struct alias
code_search("type:UserConfig")
# Scope filters (restrict to chunk types)
code_search("error scope:function") # Only function chunks
code_search("model scope:class") # Only class chunks
code_search("validate scope:test") # Only test functions
code_search("handler scope:impl") # Non-test code only
# scope:method is an alias for scope:function; scope:struct, scope:enum,
# scope:interface, scope:type and scope:module are aliases for scope:classMode | Description |
| File-level results (overview) |
| Function/class-level results (detailed) |
| Combined ranking (default) |
Tree-sitter extracts semantic units:
Functions (with docstrings)
Classes (with methods if small, or overview + separate methods if large)
Methods (with parent class context)
Modules (imports, top-level statements)
Fallback to line-based chunking for non-code files (JSON, YAML, TOML, Markdown).
Search results boosted/demoted by path:
Pattern | Adjustment |
| +10% |
| +8% |
| -10% |
| -25% |
| -30% |
search_changed searches only files changed since a git revision or time. The
changed-file set is applied as a retrieval-layer filter, so results are ranked
within the changed files rather than intersected against a bounded whole-codebase
candidate pool (change sets over 500 files fall back to post-filtering).
search_changed("auth logic", since="HEAD~5")
search_changed("database", since="main")
search_changed("fix", since="abc123")
search_changed("config", since="3.days.ago")Variable | Default | Description |
|
| Qdrant server |
|
| OpenAI-compatible embeddings API |
| (required) | Embedding model name (e.g., |
| (required) | Vector dimension (must match your model, e.g., |
| (unset) | Stable deployed model revision; setting it enables persistent exact-input embedding reuse |
|
| Active embedding HTTP attempts across local MCP processes; |
Changing the embedding model. A codebase's index is tied to the embedding model it was built with. If you switch
VECTOR_EMBEDDING_MODEL, the next search or index of that codebase fails fast with a clear error pointing atforce_reindex, instead of a cryptic Qdrant dimension error (different-dimension swap) or silently meaningless results from incompatible embedding spaces (same-dimension swap — the model name is recorded in each collection's metadata and checked on reuse). Runforce_reindexon the affected codebase to rebuild it with the new model — each codebase is reindexed independently.
Codesearch-specific settings (configured via environment variables with the CODESEARCH_ prefix):
Variable | Default | Description |
|
| Lines threshold for splitting large classes |
|
| Merge chunks smaller than this |
|
| Max lines per fallback chunk |
|
| Overlap between fallback chunks |
|
| Max cached search results |
|
| Search cache TTL (seconds) |
|
| Fraction of cache to evict when full |
|
| Batch operation timeout (seconds) |
|
| Max concurrent upsert batches |
|
| Concurrent Qdrant operations during incremental indexing |
| (derived) | Optional stable journal/lock identity when equivalent Qdrant URLs are used by different processes |
Fast incremental updates:
Check mtime + size (skip unchanged files)
Hash only modified files
Re-index only changed chunks
Avoids full re-embedding on every search.
Interrupted full indexes retain complete batches. The next search resumes files that are absent or were part of an ambiguous write rather than rebuilding the whole collection. Qdrant and the shared sparse vocabulary are coordinated by a durable intent journal; searches run against one settled generation.
# Read-only consistency audit
repair_vocabulary()
# Repair count mismatches and remove registrations with no collection
repair_vocabulary(repair=true)
# Reconstruct every live contribution, including same-count frequency drift
repair_vocabulary(repair=true, full=true)Qdrant's stored sparse indices are authoritative during reconstruction, so the repair preserves existing append-only token IDs and does not require dense re-embedding. Pending interrupted operations are recovered first. Collections are processed safely one at a time; repeat the audit if indexing changed the collection set concurrently.
Point writes and deletes use Qdrant's server-confirmed, strong ordering, and local cancellation waits for accepted requests to finish before recovery. Hard process-crash recovery assumes the Qdrant transport does not deliver an older request to the permanent leader after the later strong-ordered recovery delete.
File discovery honors gitignore-syntax exclude rules at every directory level:
.gitignore — nested .gitignore files are respected, matching git semantics (deeper files override shallower, ! negations re-include).
.git/info/exclude — repo-local excludes that are not committed to git.
.codesearchignore — exclude paths from indexing without changing git's behavior. Same syntax as .gitignore; useful for vendored code, generated files, or large data you want tracked by git but kept out of the index.
Ignored directories are pruned during traversal, so excluded subtrees cost nothing. The global core.excludesFile is intentionally not consulted, so indexing stays reproducible regardless of per-machine git configuration.
Data | Location |
Index | Qdrant collection |
Metadata | Stored in Qdrant point payloads |
Embedding cache |
|
Recovery journal |
|
Each indexed codebase gets a unique collection based on path hash.
Full tree-sitter AST support (18 languages): Python, JavaScript, TypeScript, Go, Rust, Java, C, C++, Ruby, PHP, Swift, Kotlin, Scala, C#, SQL, JSON, YAML, TOML
Line-based fallback: Bash, HTML, CSS, and all other file types (Markdown, Vue, Svelte, config files, etc.) are indexed with line-based chunking.
Jupyter notebooks (.ipynb): Notebooks are indexed by their code. Code cells are extracted (markdown, raw, and output cells are skipped) and chunked as Python with full AST support, so a notebook's functions and classes are searchable just like any other source file. Code-less or unparseable notebooks are skipped.
Requires vector-core components:
EmbeddingClient, GlobalVocabulary (embeddings)
QdrantStorage, HybridSearcher (storage)
External libraries:
tree-sitter-language-pack (AST parsing)
pathspec (.gitignore / .codesearchignore support)
Find and delete orphaned collections whose codebase directory is gone.
A collection is deleted only when its codebase path is known and confirmed absent on disk. Collections whose path cannot be determined (no stored or inferable path, or a backend error reading it) or whose path is currently inaccessible (for example on an unmounted removable or network volume) are kept and reported as skipped, never deleted, so a temporarily unavailable codebase is not mistaken for a deleted one. Run this while any removable or network volumes holding indexed codebases are mounted.
Returns: Summary of cleaned up, skipped, and remaining collections
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Semantic code search. Auto-indexes on first use, incrementally updates thereafter.
Args: query: Natural language description of what you're looking for. Supports special syntax: - function:name or fn:name - search for specific function - class:name or cls:name - search for specific class - struct:name - search for specific struct (Rust, C, Go) - path:prefix - filter to paths starting with prefix - -path:pattern - exclude paths containing pattern path: Root path of codebase (defaults to current directory) mode: "file", "chunk" (function/class level), or "both" (combined) limit: Max results to return (default 10) language: Filter by language (python, typescript, etc.) path_prefix: Only return results from paths starting with prefix (e.g., "src/") exclude_paths: Exclude paths containing these strings (e.g., ["test", "vendor"]) output_format: Output format - "text", "json", or "markdown"
Returns: Formatted search results with file paths and relevant code
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | both | |
| path | No | . | |
| limit | No | ||
| query | Yes | ||
| language | No | ||
| path_prefix | No | ||
| exclude_paths | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Delete index for a codebase.
Args: path: Root path of codebase to remove from index collection_id: Direct collection ID (e.g., "codesearch_abc123") for orphan cleanup
Returns: Confirmation message
Note: Use collection_id to delete orphaned collections that show as "unknown" in list_collections. Either path or collection_id must be provided, but not both.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| collection_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Find all usages/references of a symbol (function, class, variable).
Args: symbol: Name of the function, class, or variable to find references for path: Root path of codebase to search (defaults to current directory) limit: Max results to return (default 20) include_definition: If True, includes the symbol's definition in results output_format: Output format - "text" (default), "json", or "markdown"
Returns: List of code locations where the symbol is referenced
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | . | |
| limit | No | ||
| symbol | Yes | ||
| output_format | No | text | |
| include_definition | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Find code similar to the provided snippet.
Args: code: Code snippet to find similar code for path: Root path of codebase to search (defaults to current directory) limit: Max results to return (default 10) language: Filter by language (python, typescript, etc.) exclude_self: If True, excludes exact matches of the input code (default True) output_format: Output format - "text" (default), "json", or "markdown"
Returns: Similar code snippets ranked by similarity score
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| path | No | . | |
| limit | No | ||
| language | No | ||
| exclude_self | No | ||
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Force complete re-indexing of a codebase.
Args: path: Root path of codebase
Returns: Indexing result summary
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | . |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Check indexing status for a codebase.
Args: path: Root path of codebase
Returns: Status info: file count, last indexed, pending changes
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | . |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
List all indexed codebases.
Returns: List of collection names and their codebase paths
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Preview what would be indexed without actually indexing.
Args: path: Root path of codebase show_files: If True, list individual file paths limit: Max files to show when show_files=True
Returns: Summary of what would be indexed
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | . | |
| limit | No | ||
| show_files | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Audit or repair codesearch's global sparse vocabulary.
Qdrant file and chunk points are authoritative. The audit compares their
counts with each collection's registered vocabulary contribution and finds
registrations whose Qdrant collection no longer exists. With repair
enabled, mismatched contributions are reconstructed from stored sparse
vectors and stale registrations are removed. Vocabulary reconstruction does
not rewrite Qdrant; recovery of a pending interrupted operation may finish
its recorded deletion or clear an ambiguously partial path before rebuilding
the contribution.
full re-registers every live collection and also requires repair;
use it to correct token-frequency drift that happens to preserve the count.
Collections are processed safely one at a time; if indexing changes the
collection set concurrently, run the audit again for a point-in-time report.
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | ||
| repair | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Search only in files that have changed since a given commit or time.
The changed-file set is pushed into the retrieval layer as a Qdrant payload filter, so ranking happens within the changed files only and a match cannot be lost below a candidate pool. For very large change sets (over 500 files) the tool falls back to post-filtering a bounded candidate pool to keep filter payloads small.
Args: query: Natural language description of what you're looking for path: Root path of git repository (defaults to current directory) since: Git revision or time to compare against (e.g., "HEAD~10", "main", "3.days.ago") limit: Max results to return (default 10) output_format: Output format - "text" (default), "json", or "markdown"
Returns: Search results filtered to changed files
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | . | |
| limit | No | ||
| query | Yes | ||
| since | No | HEAD~10 | |
| output_format | No | text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Search across multiple codebases concurrently.
Each codebase is indexed (incrementally, when needed) and searched in parallel, so overall latency is bounded by the slowest codebase rather than the sum of them all.
Args: query: Natural language description of what you're looking for paths: List of codebase paths to search (e.g., ["./repo1", "./repo2"]) mode: "file" for file-level, "chunk" for function/class level, "both" for combined limit: Max results per codebase (also the cap on fused results when global_ranking is True) language: Filter by language (python, typescript, etc.) output_format: Output format - "text", "json", or "markdown" global_ranking: When False (default), results are grouped under one "=== path ===" section per codebase. When True, results from every codebase are merged into a single list ranked across codebases with Reciprocal Rank Fusion and tagged by their source codebase — answering "across all my repos, where is the best match?". RRF fuses by rank position, so it is robust to the fact that raw similarity scores from different collections are not directly comparable.
Returns: Results grouped per codebase (default) or a single globally-ranked list.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | both | |
| limit | No | ||
| paths | Yes | ||
| query | Yes | ||
| language | No | ||
| output_format | No | text | |
| global_ranking | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.8.0repair_vocabularyv1.7.0list_collectionssearch_changedv1.6.28code_searchfind_referencespreview_indexsearch_multiplev1.6.26code_searchfind_referenceslist_collectionspreview_indexsearch_changedsearch_multiplev1.6.20cleanup_orphanscode_searchdelete_collectionfind_referencesfind_similarforce_reindexindex_statuslist_collectionspreview_indexsearch_changedsearch_multipleEvery 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that gives your AI access to the source code and docs of all public github repos
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
MCP server for searching Airweave collections with natural language queries.
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
