AST 인지 청킹, 하이브리드 벡터, 쿼리 구문을 갖춘 시맨틱 코드 검색용 MCP 서버입니다.
공식 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"
# }
# }
# }
# }하이브리드 검색: RRF 융합을 사용한 밀집 임베딩 + 희소 TF-IDF
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가 의미 단위를 추출합니다:
함수 (docstring 포함)
클래스 (작으면 메서드 포함, 크면 개요 + 별도 메서드)
메서드 (부모 클래스 컨텍스트 포함)
모듈 (import, 최상위 문)
코드가 아닌 파일(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을 변경하면 해당 코드베이스의 다음 검색 또는 인덱싱은 난해한 Qdrant 차원 오류(다른 차원 교체) 또는 호환되지 않는 임베딩 공간으로 인한 조용히 의미 없는 결과(같은 차원 교체 — 모델 이름은 각 컬렉션의 메타데이터에 기록되고 재사용 시 확인됨) 대신force_reindex를 가리키는 명확한 오류와 함께 빠르게 실패합니다. 영향을 받는 코드베이스에서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, 출력 셀은 건너뜀) 전체 AST 지원과 함께 Python으로 청킹되므로 노트북의 함수와 클래스는 다른 소스 파일과 마찬가지로 검색할 수 있습니다. 코드가 없거나 파싱할 수 없는 노트북은 건너뜁니다.
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
