MCP-сервер для семантического поиска по коду с разбиением с учётом AST, гибридными векторами и синтаксисом запросов.
Поддерживает запросы MCP 2026-07-28 без сохранения состояния и устаревшие MCP-клиенты с того же stdio-сервера через официальный Python SDK v2.
Python 3.12+
Linux или macOS (использует POSIX-блокировки файлов через vector-core; несовместим с Windows)
Векторная база данных Qdrant (по умолчанию: localhost:6333)
OpenAI-совместимый API эмбеддингов (например, llama.cpp, Ollama или любой endpoint /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 извлекает функции, классы, методы с контекстом
18 языков с поддержкой AST: 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 извлекает семантические единицы:
Функции (с docstring)
Классы (с методами, если они небольшие, или обзор + отдельные методы, если большие)
Методы (с контекстом родительского класса)
Модули (импорты, операторы верхнего уровня)
Резервное построчное разбиение для некодовых файлов (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_):
Переменная | По умолчанию | Описание |
|
| Порог строк для разделения больших классов |
|
| Объединять фрагменты меньше этого |
|
| Максимум строк на резервный фрагмент |
|
| Перекрытие между резервными фрагментами |
|
| Максимум кэшированных результатов поиска |
|
| Время жизни кэша поиска (секунды) |
|
| Доля кэша для вытеснения при заполнении |
|
| Таймаут пакетной операции (секунды) |
|
| Максимум одновременных пакетов upsert |
|
| Одновременные операции Qdrant при инкрементальной индексации |
Быстрые инкрементальные обновления:
Проверка mtime + size (пропуск неизменённых файлов)
Хеширование только изменённых файлов
Переиндексация только изменённых фрагментов
Избегает полного повторного эмбеддинга при каждом поиске.
Обнаружение файлов учитывает правила исключения в синтаксисе gitignore на каждом уровне каталогов:
.gitignore — вложенные файлы .gitignore учитываются в соответствии с семантикой git (более глубокие файлы переопределяют более мелкие, отрицания ! повторно включают).
.git/info/exclude — локальные исключения репозитория, не сохраняемые в git.
.codesearchignore — исключение путей из индексации без изменения поведения git. Тот же синтаксис, что и .gitignore; полезно для вендорного кода, сгенерированных файлов или больших данных, которые вы хотите отслеживать в git, но не включать в индекс.
Игнорируемые каталоги отсекаются при обходе, поэтому исключённые поддеревья не требуют затрат. Глобальный core.excludesFile намеренно не учитывается, поэтому индексация остаётся воспроизводимой независимо от конфигурации git на конкретной машине.
Данные | Расположение |
Индекс | Коллекция Qdrant |
Метаданные | Хранятся в payload точек Qdrant |
Каждая проиндексированная кодовая база получает уникальную коллекцию на основе хеша пути.
Полная поддержка AST через tree-sitter (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 и output пропускаются) и разбиваются как 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
