code-search-mcp
🔍 code-search-mcp
Servidor MCP de búsqueda semántica de código local sin demonios, impulsado por LanceDB y embeddings de ONNX en proceso.
Deja de buscar palabras exactas con grep. Dale a tu asistente de codificación de IA el poder de buscar en tu código por significado.
Funciona listo para usar con Claude Code, Gemini CLI, Antigravity (agy) y Cursor en macOS, Windows y Linux.
☕️ Imagina una aplicación de cafetería
Imagina que estás desarrollando el software de una cafetería de barrio con mucha actividad.
En tu código tienes un archivo que gestiona lo que ocurre cuando un cliente pide un latte extra de leche de avena y recibe un descuento matutino:
// Apply a 15% promotional deduction if the customer visits before 9 AM
export function calculateEarlyBirdReward(bill: OrderSummary): number {
if (bill.orderHour < 9) {
return bill.subtotal * 0.85;
}
return bill.subtotal;
}Ahora imagina que abres tu asistente de codificación de IA (como Claude Code, Cursor o Gemini CLI) y preguntas:
"¿Dónde se calcula el descuento matutino de la bebida?"
Si tu herramienta se basa únicamente en la búsqueda de texto tradicional (como grep), buscará la palabra exacta "discount".
¿Encontró
calculateEarlyBirdReward? No.¿Por qué? Porque el código usaba las palabras
promotional deductionyEarlyBirdReward, pero nunca la palabra exacta"discount".
Aquí es donde la búsqueda semántica lo cambia todo.
Related MCP server: smart-coding-mcp
🧠 Qué es la búsqueda semántica (en palabras sencillas)
La búsqueda tradicional busca letras y palabras exactas.
La búsqueda semántica busca el significado detrás de tus palabras.
Cómo funciona: el mapa del significado
Números en lugar de letras: Un modelo de IA toma un fragmento de texto (o código) y lo convierte en una lista de números llamada embedding (o vector).
Coordenadas en un mapa: Piensa en estos números como coordenadas GPS en un mapa gigante de conceptos humanos.
"discount"y"promotional deduction"acaban situándose justo al lado el uno del otro en el mapa."espresso shot"y"latte"se sitúan juntos."database migration"se sitúa lejos, al otro lado del mapa.
Encontrar los vecinos más cercanos: Cuando haces una pregunta en lenguaje natural, el motor de búsqueda convierte tu pregunta en coordenadas y simplemente encuentra los fragmentos de código que están más cerca de esas coordenadas en el mapa.
[ Map of Meaning ]
☕️ "morning drink discount" 📍 (Your Question)
│ (Close match!)
▼
🏷 "calculateEarlyBirdReward" 📍 (Your Code)
─────────────────────────────────────────────
🗄 "sql database migration" 📍 (Far Away - Ignored)🚀 Por qué la búsqueda semántica cambia las reglas del juego en la codificación con IA
Cuando los asistentes de codificación con IA trabajan en repositorios grandes con miles de archivos, no pueden leer todo el repositorio en cada prompt: es demasiado lento y consume demasiados tokens.
En lugar de eso, la IA necesita encontrar instantáneamente los 2 o 3 archivos relevantes.
En los proyectos reales, nuestras bases de código están llenas de contexto rico:
Documentación Markdown (
.md): Registros de decisiones de arquitectura, guías de API, documentación de incorporación.Comentarios de código: explican por qué existe una regla de negocio (por ejemplo,
// Deduct beans from bean hopper inventory).Nombres de funciones y variables: patrones de nomenclatura que pueden diferir entre bibliotecas.
La búsqueda semántica conecta tus pensamientos en lenguaje natural directamente con esos documentos Markdown, comentarios y fragmentos de código, incluso cuando no recuerdas los nombres exactos de las funciones.
🛠️ Lo que construimos: code-search-mcp
Muchas herramientas de búsqueda semántica existentes para desarrolladores requieren configuraciones pesadas:
Instalar Python 3, entornos virtuales y
pip.Ejecutar un servidor de base de datos externo en segundo plano (como ChromaDB) escuchando en un puerto de red.
Configurar demonios de inicio (
LaunchAgentsen Mac, Programador de tareas en Windows) que consumen batería al arrancar.Añadir ganchos complejos de Git (
pre-commit) que pueden bloquear tu trabajo si el servidor de base de datos está sin conexión.
Queríamos algo completamente diferente: cero configuración. Cero demonios externos. Funciona en cualquier proyecto al instante.
Por eso construimos code-search-mcp — un servidor Model Context Protocol (MCP) independiente y multiplataforma para Node.js.
┌─────────────────────────────────────────────────────────────┐
│ AI Client │
│ (Claude Code / Gemini CLI / Antigravity / Cursor) │
└──────────────────────────────┬──────────────────────────────┘
│ MCP Protocol (JSON-RPC over stdio)
┌──────────────────────────────▼──────────────────────────────┐
│ code-search-mcp │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ ┌───────────┐ │
│ │ Scanner & │ │ EmbeddingEngine │ │ Watcher │ │
│ │ Layered Ignores │ │ (all-MiniLM-L6) │ │(chokidar) │ │
│ └────────┬─────────┘ └────────┬─────────┘ └─────┬─────┘ │
│ │ │ │ │
│ └───────────┬─────────┴──────────────────┘ │
│ ▼ │
│ VectorStore (LanceDB) │
│ node_modules/.cache/code-search/ │
└─────────────────────────────────────────────────────────────┘⚙️ La tecnología que hay dentro
Componente | Tecnología | Por qué la elegimos |
Tiempo de ejecución | Node.js + TypeScript | Multiplataforma (macOS, Windows, Linux) con cero dependencias del entorno de ejecución. |
Embeddings de IA locales |
| Genera vectores densos de 384 dimensiones en el propio proceso mediante |
Almacenamiento de vectores | Base de datos vectorial integrada y sin servidor, construida sobre Apache Arrow. Todo cuenta con un proceso de servidor externo. | |
Observador de archivos en vivo |
| Observa los archivos en tiempo real y actualiza los vectores de forma incremental en ~200 ms cuando pulsas Save. |
Protocolo |
| Protocolo MCP estándar compatible con Claude Code, Gemini CLI, Cursor y Windsurf. |
🔍 Cómo funciona por debajo
1. ¿Cómo saber cuando debe empezar a indexar?
Cuando tu asistente de IA se inicia (por ejemplo, cuando abres Claude Code, Antigravity o Gemini CLI), se conecta a code-search-mcp a través de la entrada/salida estándar (stdio).
El servidor MCP se conecta inmediatamente en menos de 15 ms.
Un trabajador en segundo plano comienza a escanear los archivos del proyecto sin bloquear tu sesión de chat.
2. ¿Puedes buscar antes de que termine la indexación? (El superpoder de la indexación en curso)
¡Sí! Si haces una pregunta 2 segundos después de abrir su proyecto, code-search-mcp no se bloquea ni se cuelga.
Busca en los archivos que ya se hayan indexado hasta el momento y muestra un encabezado de progreso en vivo:
⚠️ [Index status: INDEXING (35% complete - 2,100/6,000 files indexed)]
Results from currently indexed files:
### Match 1: src/drinks/espresso.ts (Lines 12-30) [Score: 54.2%]3. Ten paciencia en la primera ejecución: ¡solo ocurre una vez! ⏳
En repositorios enormes con más de 5 000 archivos, el primer índice de escaneo tarda unos minutos, porque el modelo de IA local está generando embeddings para cada fragmento de código de tu máquina por primera vez.
Las buenas noticias:
La primera ejecución se paga una sola vez: la base de datos de vectores resultante y se guarda permanentemente en
node_modules/.cache/code-search/lancedb/.Arranque instantáneo en ejecuciones posteriores: En cada sesión nueva o reinicio del editor, el servidor se conecta en menos de 15 ms para reindexar.
Actualizaciones en vivo incrementales: Mientras escribes código durante el día, el observador en vivo actualiza solo el archivo que cambiaste en ~150 ms al guardarlo.
No tienes que esperar nada: puedes empezar a hacer preguntas y buscar de inmediato; el asistente buscará lo que ya esté indexado por detrás mientras tanto.
4. ¿Dónde se guarda el índice?
Por defecto, la base de datos se guarda en:
📁 node_modules/.cache/code-search/lancedb/
¿Por qué, node_modules/.cache?
node_modulesya está ignorado por Git en el 100 % de los proyectos.Cero ruido en Git: nunca aparecen carpetas sin rastrear ni diferencias no deseadas en tu repositorio.
(Si el proyecto no tiene
node_modules, se reutiliza en.code-search/).
5. ¿Qué ocurre cuando cambias de rama de Git? 🔀
Cuando haces git checkout, git switch o git pull:
Detección por repositución del observador: Git actualiza archivos en disco y el observador de archivos incorporados
chokidardetecta en tiempo real los archivos agregados, modificados o eliminados.Re-escaneo conel refuerzo rápido: solo vuelve a indexar los archivos específicos que cambiaron entre las dos ramas (tardas 1–2 segundos en vez de minutos).
Poda automática: Los archivos modificados o fragmentos de código antiguos de la rama anterior se eliminan automáticamente de LanceDB.
Sincronización manual: si quieres forzar un reconstrucción completa limpia después de una fusión masiva, basta con que le digas a tu asistente: "Ejecuta
withcon force: true".
⚙️ Cómo ajustar los ajustes e ignorar más archivos
Por defecto, code-search-mcp ignora automáticamente binarios (.png, .mp4, .zip), salidas de build (dist/, build/), archivos de bloqueo y cualquier archivo de más de 500 KB, a la vez que respeta tu .gitignore existente.
Si quieres personal la configuración o ignorar archivos extra para tu proyecto, tienes dos opciones:
Opción 1: Crea un archivo .codesearchignore (copa y sencillo)
Crea un archivo .codesearchignore en la raíz de tu proyecto con la sintaxis estándar de gitignore:
# Ignore mock data and test fixtures
tests/fixtures/**
src/mocks/**
# Ignore auto-generated files
src/models/*.generated.ts
locales/**Opción 2: Crea un archivo .codesearchrc.json (configuración avanzada)
Crea un archivo .codesearchrc.json en la raíz de tu proyecto para controlar el comportamiento indexación, el procesamiento por lotes y los límites de tamaño de archivo:
{
"maxFileSizeKb": 300,
"batchSize": 50,
"customExcludes": [
"legacy_vendor/**",
"docs/archive/**"
],
"supportedExtensions": [
".ts", ".tsx", ".js", ".vue", ".py", ".md", ".json"
]
}📦 Cómo instalar la herramienta
Puedes instalar y ejecutar la herramienta con cualquiera de estos métodos:
Paso 1: elige tu método de instalación
Método A: Desde GitHub con npx (sin instalación: no necesitas publicar en npm)
Cualquier cliente de IA puede ejecutarlo bajo demanda directamente desde su repositorio de GitHub:
npx -y github:your-username/code-search-mcp(Node descarga automáticamente el repo, compila el bundle y ejecuta el servidor MCP).
Método B: Desde el registro npm (una vez publicado)
Si publicastes el paquete en npm:
npx -y code-search-mcp
# or global install:
npm install -g code-search-mcpMétodo C: Desarrollo local / enlazado (el arranque local más rápido)
Si lo ejecutas directamente desde tu directorio local:
cd /path/to/code-search-mcp
npm install
npm run build
npm linkAhora code-search-mcp queda registrado como un comando global en tu sistema
Paso 2: conéctal a tu cliente de IA
1. Claude Code
# If running via GitHub:
claude mcp add code-search -s user -- npx -y github:your-username/code-search-mcp
# If running locally (linked):
claude mcp add code-search -s user -- code-search-mcp2. Antigravity CLI (agy)
Ejecuta este comando de una sola línea en tu terminal:
mkdir -p ~/.gemini/config/plugins/code-search && cat << 'EOF' > ~/.gemini/config/plugins/code-search/plugin.json
{ "name": "code-search" }
EOF
cat << 'EOF' > ~/.gemini/config/plugins/code-search/mcp_config.json
{
"mcpServers": {
"code-search": {
"command": "npx",
"args": ["-y", "github:your-username/code-search-mcp"]
}
}
}
EOF3. Gemini CLI
Añade ~/.gemini/settings.json:
{
"mcpServers": {
"code-search": {
"command": "npx",
"args": ["-y", "github:your-username/code-search-mcp"],
"trust": true
}
}
}4. Cursor / Claude Desktop
Agrégalo a .cursor/mcp.json:
{
"mcpServers": {
"code-search": {
"command": "npx",
"args": ["-y", "github:your-username/code-search-mcp", "--path", "${workspaceFolder}"]
}
}
}🤖 Guía para el agente de IA y referencia de herramientas
Si eres un asistente de IA (Claude Code, Gemini CLI, Cursor, Antigravity o Windsurf) que está leyendo este repositorio, esta es tu guía de inicio rápido para usar las herramientas MCP que proporciona code-search-mcp:
🛠️ Herramientas MCP disponibles
Nombre de la herramienta | Argumentos | Descripción | Cuándo llamar |
|
| Realiza una búsqueda híbrida semántica + léxica en los archivos indexados del repositorio. Devuelve fragmentos de código con números de línea y puntuaciones de similitud. | PRIMERA LLAMADA siempre que necesites localizar conceptos, lógica de negocio, flujos de trabajo, componentes de UI o funcionalidades descritas en lenguaje natural (p. ej. "dónde se refresca la autenticación de usuario", "calculadora de impuestos del carrito de la compra"). |
| (ninguno) | Devuelve el progreso de indexación actualizado ( | Úsala antes de búsquedas grandes si sospechas que la indexación aún está en curso. |
|
| Activa una reindexación en segundo plano o una reconstrucción completa de la base de datos. | Úsala cuando el usuario solicite explícitamente una reconstrucción de la base de datos o después de fusiones de ramas a gran escala. |
| (ninguno) | Devuelve las mejores prácticas y consejos de uso para el agente integrado. | Úsala para descubrir por ti mismo las mejores prácticas durante la invocación de la herramienta. |
🧭 Matriz de decisión de herramientas: cuándo usar cada herramienta
┌───────────────────────────────────────────────┐
│ What are you looking for in the codebase? │
└───────────────────────┬───────────────────────┘
│
┌───────────────────────────────────┼───────────────────────────────────┐
▼ ▼ ▼
┌─────────────────────────┐ ┌─────────────────────────┐ ┌─────────────────────────┐
│ Concept / Feature / │ │ Known Symbol / Callers │ │ Exact Literal String / │
│ Business Logic Intent │ │ & Blast Radius Analysis │ │ Error Code / CSS Class │
│ (Natural Language) │ │ (Exact identifier) │ │ (Exact text match) │
└──────────┬──────────────┘ └──────────┬──────────────┘ └──────────┬──────────────┘
▼ ▼ ▼
┌─────────────────────────┐ ┌─────────────────────────┐ ┌─────────────────────────┐
│ 🔍 USE: code_search │ │ 🌳 USE: codegraph │ │ 🔎 USE: grep_search │
│ • "where is payment..." │ │ • codegraph_explore │ │ • "ERR_INVALID_AUTH" │
│ • "tax calculation..." │ │ • callers / callees │ │ • ".btn-primary-blue" │
└─────────────────────────┘ └─────────────────────────┘ └─────────────────────────┘💡 Consejos profesionales para agentes de IA
Usa
codeOnly: truepara lógica de implementación pura: si quieres encontrar fórmulas de cálculo en TypeScript/JavaScript puro y excluir documentación Markdown o guías de habilidades, pasa siemprecodeOnly: true.Usa
pathFilterpara acotar subsistemas: si el usuario pregunta "¿cómo funciona el proceso de pago en el módulo de facturación?", pasapathFilter: "src/billing".Usa los números de línea para ediciones directas de código: los fragmentos de código se devuelven con números de línea basados en 1 (
14: export function calculateTotal()). Puedes pasar directamente esos rangos de línea areplace_file_contento aview_filesin necesidad de suposiciones.Tolerante a erratas: puedes pasar palabras naturales directamente; el motor maneja automáticamente los plurales (stemming) y las erratas (corrección Levenshtein) en <1 ms.
🤝 El mejor dúo de IA: por qué instalar a la vez code-search y codegraph
Los asistentes de codificación con IA funcionan mejor cuando disponen de dos herramientas complementarias: búsquedas semánticas (code-search-mcp) y grafos de código AST (codegraph).
┌─────────────────────────────────────────────────────────┐
│ User: "Where is subscription discount handled?" │
└────────────────────────────┬────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 1. SEMANTIC SEARCH (code_search) │
│ • Understands intent, concepts, and natural language │
│ • Finds: subscription-billing.engine.ts (via JSDoc) │
└────────────────────────────┬────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 2. AST CODE GRAPH (codegraph_explore) │
│ • Understands syntax trees, callers, and blast radius │
│ • Traces: callers into legacy LegacyOrderProcessor.js │
│ • Discovers: unit tests (subscription-billing.spec.ts) │
└─────────────────────────────────────────────────────────┘Por qué una sola herramienta no es suficiente:
Herramienta | Tarea principal | Su mayor fortaleza | Dónde se complica |
| Detección de concepto e intención | Localiza lógica de negocio, funcionalidades, componentes y documentación de arquitectura descritos en lenguaje natural. | Atravesar jerarquías dinámicas y archivos heredados sin anotar. |
| Nlas navegación estructural y radio de impacto | Rastrear exactamente las definiciones de símbolos, llamadores y llamados, y las pruebas unitarias que los cubren, en un solo salto. | Encontrar conceptos descritos en lenguaje natural sin conocer los nombres de los símbolos. |
Caso real: motor moderno vs monolito heredado
En una base de código empresarial real:
El motor moderno (
subscription-billing.engine.ts) tiene nombres explícitos (calculateSubscriptionDiscount) y una documentación JSDoc detallada.code_searchlo encuentra con una coincidencia de >55% en milisegundos.El núcleo negativo () es un archivo de 2,000 líneas que usa términos antiguos (
getDiscountedTotal,applyOldDeduction) o erratas. Solo la búsqueda semántica podría obtener una puntuación más baja.La sinergia: en cuanto
code_searchda consubscription-billing.engine.ts,codegraph_explorerastrea al instante cada llamador directo hastaLegacyOrderProcessor.jsy mappa el radio de impacto a través de las pruebas unitarias que lo cubren, ¡sin hacer conjeturas!
Configuración doble recomendada
Añade ambas herramientas a tu configuración de MCP:
{
"mcpServers": {
"code-search": {
"command": "node",
"args": ["/path/to/code-search-mcp/dist/bin/cli.js"]
},
"codegraph": {
"command": "codegraph",
"args": ["mcp"]
}
}
}📋 Reglas de asistente recomendadas
Para garantizar que tu asistente de IA seleccione automáticamente code_search y codegraph, añade esta regla al archivo de instrucciones de tu proyecto (CLAUDE.md, GEMINI.md, .github/copilot-instructions.md o .cursorrules):
## Code Navigation & Search
1. **CodeGraph (`codegraph_explore`)**: Call FIRST when exploring known symbols, tracking call paths, finding usages, or analyzing blast radius (callers + covering tests).
2. **Semantic Search (`code_search`)**: Call FIRST when looking for features, domain behaviors, or business logic described in natural language (e.g. "where is discount calculated", "checkout suggestions formatted").🧪 Cómo verificar que funciona
Una vez instalado, puedes comprobar que code-search-mcp funciona con tres comprobaciones rápidas:
Comprobación 1: pide el estado a tu asistente de IA
En cualquier conversación con Claude Code, Cursor o Gemini CLI, pregunta:
"Comprueba el estado de
code_search_status"
Salida esperada:
Index Status: READY (or INDEXING)
Progress: 100%
Files: 6,070 / 6,070 indexed
Chunks: 8,204 code chunks in LanceDBComprobación 2: prueba una búsqueda de código en lenguaje natural
Pregunta a tu asistente:
"Usa
code_searchpara saber cómo se manejan las reglas de descuento o las recompensas de clientes"
Salida esperada:
### Match 1: src/rewards/early-bird.ts (Lines 1-18) [Score: 56.4%]El asistente devuelve al instante los fragmentos de código relevantes con números de línea exactos y puntuaciones de similitud.
Comprobación 3: probar la vigilancia en vivo de archivos
Crea un nuevo archivo de prueba en tu proyecto (por ejemplo,
src/drinks/secret-recipe.ts) con un comentario único:// Caramel macchiato secret syrup blend formula export const caramelBlend = 42;Guarda el archivo.
Pregunta de inmediato a tu asistente de IA:
"Localiza la fórmula secreta de la mezcla del jarabe con
code_search"El archivo se encontrará y se devolverá en menos de 1 segundo: no se necesitan reconstrucciones manuales ni reinicios.
Comprobación 4: ejecutar la suite de pruebas automatizada (opcional)
Si desarrollas desde el código fuente, ejecuta:
npm testTodas las 31 pruebas unitarias y de integración se ejecutarán y superarán, incluida la verificación del protocolo MCP handshake, la generación de vectores ONNX, el almacenamiento LanceDB, el ciclo de vida del watcher, la generación de vectores morfológicos y la corrección de erratas.
🛠️ Problemas reales con los que nos enfretamos y cómo los corregimos (en palabras)
Crear un buscador útil tanto para humanos como para agentes de IA de programación estuvo lleno de retos. Esto es lo que nos encontraron y cómo resolvimos cada uno:
1. 🔤 La trampa de los plurales y terminaciones ("marks" vs "Marker")
El problema: si alguien escribe con toda naturalidad "cómo usa
chart iqun número o "marks" en el gráfico", usa el plural"marks". Pero en el código hay una clase llamadaCIQ.MarkeromarkersSample. Una consulta de base de datos estándar (LIKE '%marks%') no encuentraMarkerpor la"s"extra.Cómo lo corregimos: teníamos a eliminar las terminaciones ("suffixces") . Automáticamente elimina los sufijos comunes (
-s,-ing,-ed,-tion,-ers). Al buscar"marks", se busca la raíz"mark"y encuentra en el instanteCIQ.Marker,markAxisymarkersSamplecon estrminuto overhad de 0 ms.
2. ✍️ Erratas ("calcualte mrgin shortfall")
El problema: cuando las personas teclean rápido en el chat cometen erratas (por ejemplo, escribir
mrginalen lugar demargin, ocalcularen lugar decalculate). Si la palabra contiene una errata, la búsqueda por palabra clave y fijada al 100% sería que.Cómo lo corregimos: hemos creado un V o código Léxico y corrector Levenshtein en memoria. Mientras se indexan los archivos, el elbows recopila un dicticionario con todos los nombres reales de variables, de clases y términos de tu repositorio. Cuando envías una consulta con una errata, la corrección se realiza directamente con el diccionario en < 1 ms, justo antes de la búsqueda.
3. 🤖 Bloques de código listos para agentes de IA (con números de línea)
El problema: la salida de búsqueda daba los números de línea en la cabecera (
Líneas 10-50), pero el bloque de código en sí no los usaba. Cuando un agente de codificación con IA (Claude Code, Gemini CLI, Antigravity) quería editar o citar una línea, tenía que contarlas manualmente o intentar inferir la offset.Cómo lo corregimos: todas las líneas dentro de los fragmentos de código de resultados se prefijan ahora automáticamente con el real y basado en 1 (
10: export class ...). Así, los agentes de IA pueden pasar números de línea exactos a las herramientas de edición siempre que ese intente evitando más lecturas de archivo.
4. 📚 Ruido de documentación en las búsquedas de código puro
El problema: al buscar conceptos amplios como "cómo formatear moneda", archivos grandes de habilidades (skill) en Markdown y guías de arquitectura a veces se colocaban por encima que las verdaderas utilidades
.ts, porque la documentación contiene demasiado inglés conversacional.Cómo lo corregimos:
Agregamos filtros de búsqueda:
codeOnly: true(ignora Markdown/documentación),pathFilter: "src/...", andlanguage.Reducimos el peso de los archivos JSON estáticos, para que la lógica TypeScript/JavaScript siempre aparezca primero.
5. 🔁 Exceso de resultados (demasiados fragmentos de un gran archivo)
El problema: al buscar un asunto común, un archivo de 3.000 líneas con varias coincidencias ocupaba los 10 resultados que se mostraban, ocultando las coincidencias de archivos auxiliares más pequeños y limpios.
Cómo lo corregimos: añadimos diversidad de resultados por archivo: el motor devuelve como máximo 2 fragmentos con mayor puntuación por cada archivo, para que tengas una variedad útil de resultados dentro de tu base de código.
6. ⚡ Conflictos de bloqueo de base de datos al guardar rápido
El problema: al cambiar de rama o guardar varios archivos en una sucesión rápida, varias escrituras sobre LanceDB eran capaces de desencadenar conflictos de versión concurrente.
Cómo lo corregimos: un pool de escrituras asíncronas con retraso exponencial. Si se da un conflicto de escritura, la cola espera durante algunos milisegundos y reintienta de forma segura, sin derribar el servidor.
💡 Resumen
Combinando las incrustaciones ONNX en proceso con LanceDB embebido, el enriquecimiento inteligente de tokens y el Model Context Protocol (MCP), hemos eliminado el trabajo pesado de la búsqueda semántica local:
✅ Sin demonios en segundo fondo en tu portátil.
✅ Sin dependencias de Python/ChromaDB.
✅ Sin ruido de Git (se almacena en
node_modules/.cache).✅ Gestiona automáticamente errores y variantes de palabras en <1 ms.
✅ Buscas el significado, conectando tus preguntas en lenguaje natural al código exacto y a la documentación Markdown que realmente quieres.
¡Feliz código! ☕️🚀
Available Tools
4 toolscode_searchA
Search the codebase semantically using natural language queries (e.g. "how is payment verified", "calculate discount rate"). Returns relevant code snippets with file paths and line numbers. Supports filtering by directory path, programming language, or codeOnly (to exclude markdown docs).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 10) | |
| query | Yes | The natural language or identifier search query | |
| codeOnly | No | If true, excludes markdown documentation files (.md) to prioritize actual code formulas and logic | |
| language | No | Optional programming language filter (e.g. "typescript", "javascript", "vue") | |
| pathFilter | No | Optional directory or file path substring to restrict search (e.g. "src/auth", "src/billing") |
TDQS
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. It explicitly states that the tool returns 'relevant code snippets with file paths and line numbers' and describes supported filters, which conveys a read-only, non-destructive behavior. It does not mention any side effects or limitations, but for a search tool this level of detail is adequate.
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 compact and efficient, consisting of two sentences that front-load the primary action with examples, then cover the return format and filters. There is zero filler, and every sentence contributes to the agent's ability to invoke the tool correctly.
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?
Since there is no output schema, the description appropriately explains the return value ('relevant code snippets with file paths and line numbers'). It also covers all parameters implicitly through the filtering descriptions and the query example, making the tool fully usable without needing to inspect the schema or other sources.
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 100%, so the schema already documents every parameter. The description adds minimal extra meaning beyond what the schema provides—it merely echoes the filtering options (directory path, language, codeOnly) without introducing new syntax or details. This is the baseline score for high schema coverage.
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 a specific verb ('search'), a resource ('the codebase'), and a method ('semantically'), with concrete examples of natural language queries. It also differentiates from sibling tools by implying this is the actual search operation, while siblings are status, reindex, and guide tools.
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 context for when to use the tool (searching the codebase semantically) and mentions filtering options that shape usage. It does not explicitly name alternatives or state when not to use it, but the sibling tools are so distinct (status, reindex, guide) that exclusion guidance is not strictly necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
code_search_guideA
Get best practices and usage instructions for AI agents on how and when to use code_search.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It clearly implies a read-only retrieval of guidance, but does not disclose output format, size, or any side effects. For a simple guide tool, the lack of explicit behavioral detail is acceptable 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 a single, front-loaded sentence that states the action and the target resource with zero redundancy. Every word contributes to clarity, making it highly efficient.
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 parameterless guide with no output schema, the description sufficiently conveys the tool's purpose and content. It could explicitly state that the returned instructions should be followed before using code_search, but the sibling context and the description's phrasing make this largely self-evident, so the gap is minimal.
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 zero parameters, and schema coverage is 100% (vacuously). Since the tool takes no inputs, the description need not add parameter-specific meaning; the baseline of 4 for no-parameter tools applies without deduction.
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 uses a specific verb ('get') and a clear resource ('best practices and usage instructions for AI agents on code_search'). It distinguishes itself from sibling tools like code_search (which performs the search), code_search_status, and code_search_reindex, 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 description explicitly states it provides guidance on how and when to use code_search, which implicitly tells an agent to use this tool when needing to decide on code_search usage. However, it does not explicitly contrast with sibling tools or state 'use this before calling code_search', leaving that inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
code_search_reindexA
Trigger a background re-index of the repository. Can be used to force a full reindex.
| Name | Required | Description | Default |
|---|---|---|---|
| forceFull | No | If true, clears existing vector database and rebuilds index from scratch |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It mentions 'background' indicating asynchronicity and 'force a full reindex' implying destructive potential, but it omits details like whether an incremental reindex is available, idempotency, or cancellation behavior. It provides some useful context but is 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 two short, focused sentences with no filler. It front-loads the core action ('Trigger a background re-index') and adds the optional force behavior succinctly. 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?
For a tool with a single optional parameter and no output schema, the description covers the essentials but leaves gaps: it does not clarify what happens when forceFull is false (e.g., incremental indexing) nor mention the sibling code_search_status for checking reindex progress. These are minor gaps given the simplicity.
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 100%, and the forceFull parameter is fully documented in the schema ('clears existing vector database and rebuilds index from scratch'). The description's mention of 'force a full reindex' adds minimal value beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
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 action ('Trigger a background re-index of the repository') with a specific verb and resource. It also hints at the forceFull parameter. This distinguishes it from siblings like code_search, code_search_status, and code_search_guide, 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?
The description does not explicitly state when to use this tool versus alternatives. It implies usage through the tool's purpose but lacks explicit context such as 'use after schema changes' or 'when index is stale'. No exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
code_search_statusA
Get the current indexing status, progress percentage, total files, and indexed chunk count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly implies a read-only operation via 'Get' and enumerates the output fields. It does not mention side effects, authentication, or rate limits, but for a simple status check these are not critical. It does not contradict any annotations (there are none) and gives sufficient behavioral context for expectation setting.
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 a single sentence that lists the key outputs without any fluff. It is front-loaded with the verb and resource, making it instantly scannable. 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?
For a tool with no parameters, no annotations, and no output schema, the description is fully sufficient. It states exactly what information will be retrieved. An agent can call it without needing additional context or clarification.
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 schema coverage is trivially 100%. Baseline for 0 parameters is 4. The description adds no parameter-specific details (none needed), and it correctly explains what the tool returns, which is sufficient.
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 action ('Get') and the resource ('current indexing status'), and lists specific fields (progress percentage, total files, indexed chunk count). The verb and resource differentiate it from siblings like code_search, code_search_reindex, and code_search_guide. It unambiguously describes what the tool does.
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 use for checking indexing status but provides no explicit guidance on when to choose this over the sibling tools (e.g., 'use this to check, not to trigger reindexing'). No exclusions or alternative references are given. While the purpose is clear, the tool lacks explicit routing compared to the high-standard examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v0.1.0- First observed
code_search - First observed
code_search_guide - First observed
code_search_reindex - First observed
code_search_status
TDQS
Scored across 4 tools
Each tool has a unique, clearly defined purpose: search, status, reindex, and guide. There is no overlap or ambiguity between them, and the descriptions make it obvious which tool to use for each task.
All tool names follow the same convention: 'code_search_' followed by a simple action verb (search, status, reindex, guide). This is perfectly consistent and makes the tool set easy to predict and use.
With 4 tools, the set is tightly scoped and every tool serves a necessary function for a code search server. This is an ideal count—not too thin or over-bloated—for the domain.
The tool surface covers the full lifecycle of a code search server: performing searches, checking index status, triggering reindexes, and providing usage guidance. There are no obvious gaps in functionality.
Maintenance
Related MCP Connectors
Shared memory for coding agents. Stop re-explaining your codebase every session.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Project memory, semantic code search, and grounded agent context.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceProvides Claude Code with local semantic search and indexing of your codebase using AST-aware chunking and hybrid search, enabling deep code understanding without sending data to the cloud.61 PyPIMIT
- AlicenseAqualityDmaintenanceEnables AI assistants to perform intelligent semantic code search across codebases using local AI embeddings for meaning-based retrieval.679 npmMIT
- FlicenseNot gradedqualityDmaintenanceEnables semantic code search across codebases using AI embeddings and vector similarity, integrated with Claude Desktop and Cursor.-
- AlicenseAqualityAmaintenanceEnables AI coding assistants to perform local semantic code search using AST parsing and embeddings, finding code by meaning with exact file and line locations, plus AST-based usage lookup.4MIT