Contexto destilado para tu agente, sin releer medio repo.

En este producto el MCP corre en modo hub: un único servidor code-rag atiende todos los proyectos y resuelve cuál usar por request. No hay que configurar nada por proyecto ni pasar el slug: la tool ya consulta el repo del workspace abierto.

1 · Mirá qué proyectos hay

// lista los proyectos indexados y marca cuál está abierto acá
mcp__code-rag__list_projects

2 · Tu primera búsqueda

Ante cualquier duda —un bug, "dónde está la lógica de X", "cómo se conecta Y"— empezá por search_context. Es la puerta de entrada y devuelve contexto ya rankeado.

mcp__code-rag__search_context({ query: "cómo se calcula el ranking de resultados" })

Cada resultado abre con 📁 <slug> · branch: <branch> para que sepas a qué proyecto apuntó. Para consultar otro proyecto, pasá project:"<slug>" a cualquier tool.

3 · Profundizá y editá

Con el contexto en mano, bajá al detalle con get_card, get_symbol o get_file_outline. Recién ahí abrí —con Read— solo los archivos que vas a modificar. El resto del contexto ya llegó por el MCP.

Tener el MCP conectado hace que las tools estén disponibles. No garantiza que el agente deje de abrir archivos gigantes como turista con linterna. La diferencia entre "esto es increíble" y "lo instalé y no cambió nada" suele ser una sola instrucción al agente:

Antes de Grep/Read, usá mcp__code-rag__search_context para traer
contexto del repo. Preferí búsqueda de símbolos, outlines y
recuperación puntual por encima de leer archivos completos.

En un repo que ya trae su CLAUDE.md, esa política puede vivir ahí. Si trabajás sobre otro proyecto indexado, dejale al agente una línea equivalente: le enseñás a navegar, no a hurgar.

Cuatro ideas explican el 90% del comportamiento del sistema:

Doce tools sobre mcp__code-rag__*. No hace falta elegir: search_context es la puerta y ya aflora símbolos; las demás son para profundizar. Todas aceptan un project:<slug> opcional.

Búsqueda y contexto

Estructura de código

Datos tabulares

Auto-mejora

Mantenimiento del índice

Multi-proyecto (hub)

code-rag no es solo para código. El núcleo es agnóstico; un perfil (RAG_PROFILE) declara, por base de conocimiento, qué se ingiere y con qué vocabulario le hablan las tools. Sin perfil ⇒ code (cero migración).

La ingesta universal (v3.2) cubre además HTML, JSON/JSONL/YAML/XML, PPTX, ODT, RTF, logs, correos .eml/.msg, QIF/OFX, Parquet, SQLite e imágenes/PDF escaneado vía OCR opt-in (RAG_OCR=1). Los parsers binarios son dependencias opcionales: si faltan, avisa y sigue con el resto.

search_context no es un grep con bigote falso. El flujo es:

1. 1Embedding asimétrico. A la query se le antepone una instrucción de tarea (Instruct: … Query: …); los documentos van sin prefijo. Embedder fijo qwen3-embedding:4b a 2560d.
2. 2KNN + rerank. Se recuperan k×3 vecinos por coseno y se re-rankean a k con el scoring: similitud × (usefulness + recencia + hits).
3. 3Refuerzo. Lo recuperado suma un hit (sube su ranking futuro) y late al dashboard. El resultado se trunca a ~4000 chars por hit para no reventar el límite de tokens.

Práctico: usá una query precisa cuando sabés el nombre del símbolo; agregá filters (type, module, kind) cuando el repo es grande; describí la intención en lenguaje natural (ES o EN) cuando no sabés cómo se llama el código.

El valor del RAG crece con los findings, pero pedirte que documentes al final de cada sesión no escala. El lazo lo automatiza en tres piezas:

• Stop-hook. Al cerrar la sesión detecta los archivos editados y deja un draft; sugiere escribir /aprende. No indexa (a prueba de fallos: nunca rompe el cierre).
• /aprende. Reconstruye la sesión desde la conversación + git diff, redacta el finding (síntoma, causa raíz, fix), te lo muestra y pide confirmar.
• record_finding. Al confirmar, escribe knowledge/<slug>.md e indexa con usefulness:1.5. Idempotente por título.

Después, cada vez que un finding se recupera suma un hit; feedback ajusta su utilidad; y si pasa 60+ días sin uso, el decay nocturno lo baja a piso (deja de aflorar, no se borra).