用于语义代码搜索的 MCP 服务器，具备 AST 感知分块、混合向量和查询语法。
通过官方 Python SDK v2，同一个 stdio 服务器同时支持无状态 MCP 2026-07-28 请求和传统 MCP 客户端。
Python 3.12+
Linux 或 macOS（通过 vector-core 使用 POSIX 文件锁；不兼容 Windows）
Qdrant 向量数据库（默认：localhost:6333）
兼容 OpenAI 的嵌入 API（例如 llama.cpp、Ollama，或任何 /v1/embeddings 端点；默认：localhost:8080）
Related MCP server: codesteer-atlas
需要 vector-core。
pip install git+https://github.com/michaelkrauty/vector-core.git@v1.4.2
pip install git+https://github.com/michaelkrauty/mcp-codesearch.git或者克隆两个仓库并在本地安装：
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"
# }
# }
# }
# }混合搜索：稠密嵌入 + 稀疏 TF-IDF，使用 RRF 融合
AST 感知分块：Tree-sitter 提取函数、类、方法及其上下文
支持 AST 的 18 种语言：Python、JS/TS、Go、Rust、Java、C/C++、Ruby、PHP、Swift、Kotlin、Scala、C#、SQL、JSON、YAML、TOML（Bash、HTML、CSS 及其他文件类型使用基于行的回退）
查询语法：function:name、class:name、file:pattern、path:prefix、-path:exclude
增量索引：在哈希之前通过 mtime+size 进行变更检测
查询预处理：同义词扩展（fn → function、db → database）
灵活的忽略规则：嵌套的 .gitignore、.git/info/exclude 和 .codesearchignore（gitignore 语法）在每个目录层级都生效
工具 | 描述 |
| 带自动索引的主搜索 |
| 跨多个代码库搜索 |
| 在最近变更的文件中搜索（git 感知） |
| 查找与代码片段相似的代码 |
| 查找符号的所有使用位置 |
工具 | 描述 |
| 检查索引状态、文件数量、待处理变更 |
| 强制完全重新索引 |
| 预览将要索引的内容 |
工具 | 描述 |
| 列出所有已索引的代码库 |
| 删除某个代码库的索引 |
| 移除孤立的集合 |
# 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"')常见缩写自动扩展：
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:class模式 | 描述 |
| 文件级结果（概览） |
| 函数/类级结果（详细） |
| 组合排序（默认） |
Tree-sitter 提取语义单元：
函数（含文档字符串）
类（较小时包含方法，较大时提供概览 + 独立方法）
方法（含父类上下文）
模块（导入、顶层语句）
非代码文件（JSON、YAML、TOML、Markdown）回退到基于行的分块。
搜索结果按路径提升/降权：
路径模式 | 调整 |
| +10% |
| +8% |
| -10% |
| -25% |
| -30% |
search_changed 只搜索自某个 git 修订版本或时间点以来变更的文件。变更文件集作为检索层过滤器应用，因此结果在变更文件内排序，而不是与受限的全代码库候选池做交集（超过 500 个文件的变更集回退到后过滤）。
search_changed("auth logic", since="HEAD~5")
search_changed("database", since="main")
search_changed("fix", since="abc123")
search_changed("config", since="3.days.ago")变量 | 默认值 | 描述 |
|
| Qdrant 服务器 |
|
| 兼容 OpenAI 的嵌入 API |
| （必填） | 嵌入模型名称（例如 |
| （必填） | 向量维度（必须与你的模型匹配，例如 |
更换嵌入模型。 代码库的索引与其构建时使用的嵌入模型绑定。如果你切换
VECTOR_EMBEDDING_MODEL，该代码库的下一次搜索或索引会快速失败，并给出指向force_reindex的明确错误，而不是晦涩难懂的 Qdrant 维度错误（不同维度切换）或来自不兼容嵌入空间的静默无意义结果（相同维度切换——模型名称记录在每个集合的元数据中，并在复用时检查）。对受影响的代码库运行force_reindex，以使用新模型重建索引——每个代码库独立重新索引。
Codesearch 专用设置（通过带 CODESEARCH_ 前缀的环境变量配置）：
变量 | 默认值 | 描述 |
|
| 拆分大型类的行数阈值 |
|
| 合并小于此值的块 |
|
| 每个回退块的最大行数 |
|
| 回退块之间的重叠行数 |
|
| 缓存搜索结果的最大数量 |
|
| 搜索缓存 TTL（秒） |
|
| 缓存满时淘汰的比例 |
|
| 批量操作超时（秒） |
|
| 最大并发 upsert 批次 |
|
| 增量索引期间的并发 Qdrant 操作 |
快速增量更新：
检查 mtime + size（跳过未变更的文件）
仅对修改过的文件进行哈希
仅重新索引变更的块
避免每次搜索都进行完整的重新嵌入。
文件发现遵循 每个 目录层级的 gitignore 语法排除规则：
.gitignore —— 嵌套的 .gitignore 文件会被尊重，与 git 语义一致（更深层的文件覆盖更浅层的，! 否定重新包含）。
.git/info/exclude —— 未提交到 git 的仓库本地排除项。
.codesearchignore —— 从索引中排除路径，不 改变 git 的行为。语法与 .gitignore 相同；适用于你想让 git 跟踪但不想纳入索引的第三方代码、生成文件或大型数据。
被忽略的目录在遍历过程中会被剪除，因此被排除的子树不产生任何开销。全局 core.excludesFile 有意不被读取，因此无论每台机器的 git 配置如何，索引都保持可复现。
数据 | 位置 |
索引 | Qdrant 集合 |
元数据 | 存储在 Qdrant 点负载中 |
每个已索引的代码库都会根据路径哈希获得一个唯一的集合。
完整的 tree-sitter AST 支持（18 种语言）： Python、JavaScript、TypeScript、Go、Rust、Java、C、C++、Ruby、PHP、Swift、Kotlin、Scala、C#、SQL、JSON、YAML、TOML
基于行的回退： Bash、HTML、CSS 以及所有其他文件类型（Markdown、Vue、Svelte、配置文件等）使用基于行的分块进行索引。
Jupyter 笔记本（.ipynb）： 笔记本按 代码 进行索引。代码单元格会被提取（markdown、raw 和输出单元格被跳过），并作为 Python 进行分块，具有完整的 AST 支持，因此笔记本中的函数和类与其他任何源文件一样可搜索。没有代码或无法解析的笔记本会被跳过。
需要 vector-core 组件：
EmbeddingClient、GlobalVocabulary（嵌入）
QdrantStorage、HybridSearcher（存储）
外部库：
tree-sitter-language-pack（AST 解析）
pathspec（.gitignore / .codesearchignore 支持）
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
