code-search-mcp
🔍 code-search-mcp
Zero-Daemon lokaler MCP-Server für semantische Code-Suche, unterstützt von LanceDB und In-Process ONNX Runtime.
Hör auf, nach exakten Wörtern zu greppen. Gib deinem KI-Coding-Assistenten die Kraft, deine Codebasis nach Bedeutung zu durchsuchen.
Funktioniert ohne Weiteres mit Claude Code, Gemini CLI, Antigravity (agy) und Cursor auf macOS, Windows und Linux.
☕️ Stell dir eine Coffee-Shop-App vor
Stell. Dir vor, dass du Software für ein begehrten Café in the Nachbarschaft entwickelst.
In deiner Codebasis gibt es eine Datei, die regelt, was passiert, wenn eine Kundschaft einen zusätzlichen Hafermilch-Latte bestellt und einen Frührabatt erhält:
// 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;
}Öffne nun deinen KI-Entwicklungsassistenten (z.,B. Claude Code, Cursor oder Gemini CLI) and frag:
„Wo wird der Morgen-Getränke-Rabatt berechnet?"
Basiert dein Werkzeug nur auf traditioneller Textsuche (wie grep), sucht es nach dem exakten Wort "discount".
Hat es
calculateEarlyBirdRewardgefunden? Nein.Warum? Weil der Code die Wörter
promotional deductionundEarlyBirdRewardverwendete, aber nie das exakte Wort"discount".
Genau hier verändert die semantische Suche alles.
Related MCP server: smart-coding-mcp
🧠 Was ist semantische Suche? (Einfach erklärt)
Traditionelle Suche sucht nach exakten Buchstaben und Wörtern.
Semantische Suche sucht nach der Bedeutung hinter deinen Wörtern.
So funktioniert es: Die Landkarte der Bedeutungen
Zahlen statt Buchstaben: Ein KI-Modell nimmt einen Text (oder Code) and übersetzt ihn in eine Liste von Zahlen, die Embedding (or Vector) Genannte wird.
Koordinaten auf einer Landkarte: Stell dir diese Zahlen wie GPS-Koordinaten auf einer riesigen Landkarte menschlicher Konzepte vor.
"discount"und"promotional deduction"landen direkt nebeneinander auf der Landkarte."espresso shotund"latte"liegen gemeinsam."database migrationsitzt far entfernt auf der other Seite der Landkarte.
Nächste Nachbarn finden: Wenn du eine Frage in einfacher Sprache stellst, wandelt die Suchmaschine deine Frage in Koordinaten um und findet simply die Codeteile, die auf der Karte am nächsten sind.
[ Map of Meaning ]
☕️ "morning drink discount" 📍 (Your Question)
│ (Close match!)
▼
🏷 "calculateEarlyBirdReward" 📍 (Your Code)
─────────────────────────────────────────────
🗄 "sql database migration" 📍 (Far Away - Ignored)Warum semantische Suche für KI-Coding ein Game-Changer ist
Wenn KI-CodingAssistenten an großen Repositories mit Tausende von Dateien arbeiten, Können sie nicht bei jeder Aufforderung every file lesen – das wäre zu langsam und würde defekte many tokens.
Die KI muss stattdessen die richtgen 2 bzw. 3 relevanten Dateien sofort finden.
In realen Projekten sind unsere Codelases voll mit reichen Kontext:
Markdown-Dokumentation (
.md): Architektur-Entscheidungen, API-Anleitungen, Onboarding-Doku.Code-Kommentare: Erklärungen, warum eine Geschäftsregel existiert (z.\B.
// Deduct beans from bean hopper inventory).Funktions- und Variablennamen: Namensmuster, die zwischen verschiedenen Bibliotheken abweichen können.
Semantische Suche verbindet deine normal-sprachliche Gedanken direkt mit Markdown-Dokumenten, Kommentaren und Code-Snippets – selbst wenn du die genauen Funktionsnamen nicht weißt.
🛠 Was wir gebaut haben: code-search-mcp
Viele bisherige semantische Suchwerkzeuge für Entwickler benötigen aufwendige Setups:
Installation von Python 3, virtuellen Umgebungen und
pip.Betreiben eines externen Hintergrund-Datenbankservers (wie Beeindruckt) der auf einem Netzwerk-Port lauscht.
Einrichten von Auto.Dämonen (
LaunchAgentsauf dem Mac, Taskplaner unter Windows), die beim Boot Akku ziehen.Hinzufügen komplexer Git-Hooks (
pre-commit), die deine Arbeit blockieren, wenn der Datenbankserver offline ist.
Wir wollten etwas völlig anderes: Null Setup. Null externe Dämonen. Funktioniert sofort in jedem Projekt.
Dafür haben wir code-search-mcp – einen eigenständigen, plattformübergreifenden Model Context Protocol (MCP)-Server für 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/ │
└─────────────────────────────────────────────────────────────┘⚙️ Die Technologie im Party
Komponente | Technologie | Warum wir sie ausgewählt haben |
Laufzeit | Node.js + TypeScript | Plattformübergreifend (macOS, Windows, Linux) mit null Laufzeit-Abhängigkeit. |
Lokale KI-Embeddings |
| Erzeugt dichte 384-dimensionale Vektoren über |
Vektorspeicher | Eingebettete, serverless Vektordatenbank based on Apache Arrow. Kein externer Serverprozess nötig. | |
Live-Datei-Überwacher |
| Überwacht Dateien in Echtzeit und aktualisi Vektoren inkrementell innerhalb von ungefähr 200 ms beim Speichern. |
Protokoll |
| Standard-MCP-Protokoll, unterstützt von Claude Code, Gemini CLI, Cursor und Windsurf. |
🔍 So funktioniert es im Detail
1. Woher weiß es, wann die Indexierung starten muss?
Wenn dein KI-Assistent startet (z.B. wenn du Claude Code, Antigravity oder Gemini CLI startest), verbindet er sich mit code-search-mcp über die Standard-Ein-/Ausgabe (stdio).
Der MCP-Server verbindet sich innerhalb von <15 ms.
Ein toreuntergrund startet in den
.js–? Ein Hintergrund-Worker scannt statt dessen die Projektdateien, ohne deinen Chat zu blockieren.
2. Kannst du suchen, bevor die Indizierung abgeschlossen ist? („Mid-Indexing-Superpower“)
Ja! Wenn du zwei Sekunden nach dem Öffnen deines Projects eine Frage stellst, blockiert oder hängt code-search-mcp nie.
Es sucht alle inzwischen indexierten Dateien und liefert einen live Seite Fortschrittsheader:
⚠️ [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. Geduld beim ersten Start – es läuft nur einmal! ⏳
Bei großen Repositories with 5.000+ Dateien dauert der allererste Indexierung-Durchlauf einige Minuten, weil das lokale KI-Modell zum ersten Mal Vektor-Embeddings für jeden einzelnen Codeteil auf deiner Maschine erzeugt.
Die gute Nachricht:
Den Start bezahlst du einmal: Die entstandene Vektorendatenbank wird dauerhaft in
~node_modules/.cache/code-search/lancedb/gespeichert.Sofortiger Folgestart: Bei jeder späteren Sitzung oder neuem Editor startet der Server in <15 ms, ohne die Indizierung zu wiederhoE-N.
Inkrementelle Live-Updates: Nach Speichern aktualisiert der Live-Watcher nur die einzelne geänderte Datei in ungefähr 150 ms.
Keine Wartezeit: Du kannst sofort Fragen stellen und suchen – der Assistent durchsucht das bereits im Hintergrund Indizierte.
4. Wo wird der Index gespeichert?
Standardmäßig wird die Datenbank gespeiche unter:
📁 node_modules/.cache/code-search/lancedb/
Warum node_modules/.cache?
node_moduleswird in bereits 100% of projects von Git ignoriert.Kein Git-Rauschen: Es kommen weder in den Verzeichnissen liegende Ordner noch unerwünschte Diffs in deinem Repository an.
Sollte das Projekt kein
node_modulesBefohlen enthalten, fällt es sauber auf.code-search/zurück.
5. Was passiert, wenn du Git-Branches wechselst? 🔀
Wenn du git checkout, git switch oder git pull ausführst:
Live-Watcher-Erkennung: Git ändert Dateien auf der Disk, und der eingebaute
chokidar-Dateibeobachter erkennt die hinzugezogenen, geänderten oder gelöschten Dateien.Schneller Differential-Re-Scan: Er indexiert nur die Dateien, die sich zwischen den beiden Branches tatsächlich geändert haben (1–2 Sekunden anstatt mehrerer Minuten).
Automatische Bereinigung: Gelöschte Dateien / alte Codeteile des vorherigen Branches werden automatisch aus LanceDB entfernt.
Manuelle Synchronisation: Wenn du nach einem großen Merge einmal einen kompletten Clean-Reindex erzwingen möchtest, sag einfach deinem Agenten: „Führe
code_search_reindexmit force: true aus“.
⚙️ So verwaltest du Einstellungen & ignorierst weitere Datei
Standardmäßig ignoriert code-search-mcp automatisch Binärdateien (.png, .mp4, .zip), Build-Output (dist/, build/), Lockfiles sowie jede Datei über 500 KB – wie gehört es sich Basis. Gleichzeitig respektiert es dein vorhandenes .gitignore.
Wenn du die Einstellungen anpassen or zusätzliche Dateien für dein Projekt ignorieren möchtest, hast du zwei einfachen Möglichkeiten:
Option 1: Eine .codesearchignore-Datei erstellen (Schnell & Einfach)
Erstelle eine .codesearchignore-Datei im Projektwurzelverzeichnis mitStandard-Gitignore-Syntax:
# Ignore mock data and test fixtures
tests/fixtures/**
src/mocks/**
# Ignore auto-generated files
src/models/*.generated.ts
locales/**Option 2: Eine .codesearchrc.json-Datei erstellen (erweiterte Einstellungen)
Erstelle eine .codesearchrc.json-Datei im Projekt-Wurzelverzeichnis, um das Indizierungsverhalten, Batch-Size und Dateien-Große-Limits zu steuern:
{
"maxFileSizeKb": 300,
"batchSize": 50,
"customExcludes": [
"legacy_vendor/**",
"docs/archive/**"
],
"supportedExtensions": [
".ts", ".tsx", ".js", ".vue", ".py", ".md", ".json"
]
}📦 Installation des Tools
Du kannst das Tool mit einer der folgenden Methoden installieren und starten:
Schritt 1: Wähle deine Installationsmethode
Methode A: Direkt über npx aus GitHub (Zero-Install – kein npm-Publish nötig!)
Jeder KI-Client kann es bedarfsgerecht direkt aus deinem GitHub-Repository ausführen:
npx -y github:your-username/code-search-mcp(Node lädt das Repository automatisch herunter, baut das Bundle und führt den MCP-Server aus.)
Methode B: Aus der npm-Registry (wenn veröffentlicht)
Wenn du das Paket auf npm published hast:
npx -y code-search-mcp
# or global install:
npm install -g code-search-mcpMethode C: Lokale Entwicklung / Verlinkt (schnellster lokaler Start)
Wenn du es direkt aus deinem lokalen Quellverzeichnis aufrufen:
cd /path/to/code-search-mcp
npm install
npm run build
npm linkcode-search-mcp ist jetzt also globaler Befehl auf deinem System registriert.
Schritt 2: Verbinde Es mit deinem KI-Client
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)
Führe diesen Einzeiler in deinem Terminal aus:
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
Füge dies zu deiner ~/.gemini/settings.json hinzu:
{
"mcpServers": {
"code-search": {
"command": "npx",
"args": ["-y", "github:your-username/code-search-mcp"],
"trust": true
}
}
}4. Cursor / Claude Desktop
Füge dies zu deiner .cursor/mcp.json hinzu:
{
"mcpServers": {
"code-search": {
"command": "npx",
"args": ["-y", "github:your-username/code-search-mcp", "--path", "${workspaceFolder}"]
}
}
}🤖 KI-Agenten Guide & Tool-Referenz
Wenn du ein KI-Agent (Claude Code, Gemini CLI, Cursor, Antigravity oder Windsurf) bist, der dieses Repository liest, hier istsl deine Schnellstart-Anleitung für die MCP-Tools, die code-search-mcp bereitstellt:
🛠️ Verfügbare MCP-Tools
Werkzeugname | Argumente | Beschreibung | Wann aufrufen |
|
| Führt eine hybride semantische und lexikalische Suche über indizierte Repository-Dateien durch. Gibt Code-Ausschnitte mit Zeilennummern und Ähnlichkeitswerten zurück. | Erster Aufruf immer dann, wenn Konzepte, Geschäftslogik, Workflows, UI-Komponenten oder Features in natürlicher Sprache gesucht werden (z. B. „wo wird die Benutzerauthentifizierung erneuert”, „Mehrwertsteuerrechner für den Warenkorb”). |
| (keine) | Gibt den aktuellen Indizierungsfortschritt ( | Vor großen Suchanfragen prüfen, wenn der Verdacht besteht, dass die Indizierung noch ausgeführt wird. |
|
| Löst einen Hintergrund-Reindex oder vollständigen Datenbank-Neubau aus. | Aufrufen, wenn der Benutzer ausdrücklich einen Datenbank-Neubau oder nach massiven Branch-Merges anfordert. |
| (keine) | Gibt Inline-Best-Practices und Tipps für die Agentennutzung zurück. | Aufrufen, um während der Tool-Nutzung Best-Practices selbst zu entdecken. |
🧭 Tool-Entscheidungsmatrix: Wann welches Werkzeug zu verwenden ist
┌───────────────────────────────────────────────┐
│ 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" │
└─────────────────────────┘ └─────────────────────────┘ └─────────────────────────┘💡 Pro-Tipps für KI-Agenten
codeOnly: truefür reine Implementierungslogik verwenden: Wenn du absolute Pure TypeScript/JavaScript-Berechnungsformeln finden möchtest und Markdown-Dokumentation oder Skill-Anleitungen ausgeschlossen sein sollen, übergib immercodeOnly: true.pathFilterverwenden, um Subsysteme einzugrenzen: Wenn der Benutzer „Wie funktioniert der Checkout im Billing-Modul?” fragt, übergibpathFilter: "src/billing".Zeilennummern für direkte Code-Bearbeitung verwenden: Code-Ausschnitte werden mit 1-basierten Zeilennummern zurückgegeben (
14: export function calculateTotal()). Du kannst diese Zeilennummern direkt anreplace_file_contentoderview_fileweitergeben, ohne raten zu müssen.Tippfehler-tolerant: Einfach natürliche Sätze verwenden – die Engine korrigiert automatisch Wortformen (
Stemming) und Tippfehler (Levenshtein-Korrektur) in < 1 ms.
🤝 Das ultimative KI-Paar: Warum du sowohl code-search als auch codegraph installieren solltest
Moderne KI-basierte Coding-Assistenten funktionieren am besten mit zwei komplementären Werkzeugen: Semantische Suche (code-search-mcp) und AST Code Graphs (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) │
└─────────────────────────────────────────────────────────┘Warum ein einzelnes Werkzeug nicht ausreicht:
Werkzeug | Hauptaufgabe | Was es am besten kann | Wo es Schwierigkeiten hat |
| Konzept- und Absichtserkennung | Findet Business-Logik, Features, Komponenten und Architekturdokumente, die in einfacher Sprache beschrieben sind. | Navigieren durch dynamische Aufrufhierarchien und alte, nicht annotierte Dateien. |
| Strukturelle Navigation & Auswirkungsanalyse | Verfolgt exakte Symboldefinitionen, Aufrufer, Aufgerufene und abgedeckte Quell-Einheiten in einem einzigen Schritt. | Sucht Konzepte, die in natürlicher Sprache ohne Kenntnis von Symbolnamen beschrieben werden. |
Praxisbeispiel: Moderne Engine vs. Legacy-Monolith
In einer realen Firmen-Codebasis:
1. Die moderne Engine (subscription-billing.engine.ts) hat klare Beschreibungen (calculateSubscriptionDiscount) und ausführliche JSDoc-Erklärungen. code_search findet sie in Millisekunden mit einem >55 %igen Ähnlichkeitsabstand.
Der Legacy-Kern (
LegacyOrderProcessor.js) ist eine 2.000-Zeilen-Datei mit alten Begriffen (getDiscountedTotal,applyOldDeduction) oder Tippfehlern. Die semantische Suche allein könnte diese niedriger bewerten.Die Synergie: Sobald
code_searchaufsubscription-billing.engine.tsgelangt, verfolgtcodegraph_exploresofort jeden Aufrufer bis inLegacyOrderProcessor.jsund bildet die Auswirkungsanalyse auf die abgedeckten Unit-Tests ab – ohne Hinweise!
Empfohlene Dual-Konfiguration
Füge beide Werkzeuge zu deiner MCP-Konfiguration hinzu:
{
"mcpServers": {
"code-search": {
"command": "node",
"args": ["/path/to/code-search-mcp/dist/bin/cli.js"]
},
"codegraph": {
"command": "codegraph",
"args": ["mcp"]
}
}
}📋 Empfohlene Assistenten-Regeln
Damit dein KI-Assistent automatisch code_search und codegraph auswählt, füge diese Regel deiner Projekt-Anweisungen hinzu (CLAUDE.md, GEMINI.md, .github/copilot-instructions.md oder .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").🧪 So überprüfst du, ob die Erweiterung funktioniert
Nach der Installation kannst du mit drei Schnellchecks überprüfen, ob code-search-mcp funktioniert:
Check 1: Status von deinem KI-Assistenten anzeigen
Frag in einer beliebigen Chat-Sitzung mit Claude Code, Cursor oder Gemini CLI:
„Prüfe
code_search_status”
Erwartete Ausgabe:
Index Status: READY (or INDEXING)
Progress: 100%
Files: 6,070 / 6,070 indexed
Chunks: 8,204 code chunks in LanceDBCheck 2: Eine Code-Suche in natürlicher Sprache versuchen
Frag deinen KI-Assistenten:
„Verwende
code_search, um herauszufinden, wie Subscriptionsrabatt-Regeln oder Belohnungen behandelt werden”
Erwartete Ausgabe:
### Match 1: src/rewards/early-bird.ts (Lines 1-18) [Score: 56.4%]Der Assistent liefert in Sekundenbruchteilen die relevanten Code-Ausschnitte mit exakten Zeilennummern und Ähnlichkeitswerten.
Check 3: Live-Datei-Überwachung testen
Erstelle eine neue Testdatei in deinem Projekt (z. B.
src/drinks/secret-recipe.ts) mit einem einzigartigen Kommentar:// Caramel macchiato secret syrup blend formula export const caramelBlend = 42;Speichere die Datei.
Frag sofort deinen Assistenten:
„Suche nach der geheimen Sirupmischformel mit
code_search”Die neue Datei wird in unter 1 Sekunde gefunden – kein manueller Rebuild oder Neustart nötig!
Check 4: Die automatisierte Testsuite ausführen (optional)
Wenn du aus den Quellen entwickelst, führe Folgendes aus:
npm testAlle 31 Unit- und Integrationstests werden ausgeführt und bestanden und prüfen den MCP-Protokoll-Handshake, die ONNX-Vektorenerzeugung, die LanceDB-Speicherung, den Watcher-Lebenszyklus, Wort-Stemmen und Tippfehlerkorrektur.
🛠️ Häufige Probleme, die wir in der Praxis gefunden haben (auf Deutsch)
Beim Entwickeln einer Suchmaschine, die sowohl für Menschen als auch für KI-Agenten reibungslos funktioniert, tauchten einige praktische Herausforderungen auf. Hier ist unsere Lösung für jede Ein:
1. 🔤 Plural- und Wortendungs-Falle (marks vs. Marker)
Das Problem: Wenn jemand natürlich tippt „Wie nutzt chart iq marks auf dem Chart”, wird das Pluralwort
"marks"verwendet. Im Code heißt die Klasse jedochCIQ.MarkerodermarkersSample. Eine normale DB-Abfrage (LIKE '%marks%') übersiehtMarkerwegen dem zusätzlichen"s"komplett.So haben wir es behoben: Wir haben einen leichtgewichtigen Wort-Stemmer gebaut. Er entfernt automatisch typische Suffixe (
-s,-ing,-ed,-tion,-ers). Wenn du nach"marks"suchst, wird der Stamm"mark"überprüft und findet sofortCIQ.Marker,markAxisundmarkersSamplemit 0 ms Zusatzaufwand.
2. ✍️ Tippfehler-Falle (calcualte mrgin shortfal)
Das Problem: Menschen tippen im Chat schnell und machen Tippfehler (z.B.
mrginstattmarginodercalcualtestattcalculate). Wenn das Wort einen Tippfehler hat, scheitert die klassische Stichwortsuche zu 100 %.Wie wir es gelöst haben: Wir haben eine Speicher-Vokabular- und Levenshtein-Tippfehlerkorrektur entwickelt. Dafür sammelt die durch Engine alle echten Variablen-, Funktions- und Dateibezeichnungen im Repository in einem Wörterbuch. Bei Anfrage mit Tippfehler wird das Wörterbuch durchsucht und der Fehler in < 1 ms korrigiert, bevor die Ergebnisausgabe suchen.
3. 🤖 AI-Agent-kompatible Code-Blöcke (mit Zeilennummern)
Das Problem: Die Suchfunktion gab die Zeilennummern im Kopfbereich (
Zeilen 10-18) aus, aber die Codeausschnitte selbst hatten keine Zeilennummern. Wenn ein KI-Codierungs-Agent (Claude Code, Gemini CLI, Antigravity) eine Zeile bearbeiten oder zitieren wollte, musste er Zeilen manuell zählen oder Offsets schätzen.So haben wir es gefixt: Jetzt wird jede Zeile in den Suchergebnissen automatisch mit der echten 1-basierten Zeilennummer (Ü
10: export class ...) versehen. KI-Agenten können die exakten Zeilennummern direkt an dieBearbeitungs-Werkzeuge weiterreichen, ohne zusätzliche Dateien zu lesen.
4. 📚 Dokumentations-Rauschen bei reinen Code-Suchen
Das Problem: Bei einer Suche nach breiten Konzepten wie „formatcurrency” (/Währung formatieren) ranken große Markdown-Skill-Dateien und Architektur-Anleitungen manchmal besser als die eigentlichen
.ts-Services, weil die Dokumente viel Konversations-Englisch enthalten.So haben wir es gelöst:
Drei Suchfilter hinzugefügt:
codeOnly: true(ignoriert Markdown/Doku),pathFilter: "src/..."undlanguage.Statische JSON-Wörterbuch-Dateien abgewertet, damit Kern-TypeScript/JavaScript-Logik immer zuerst rangiert.
5. 🔁 Ergebnis-Überflutung (zu viele Chunks aus einer großen Datei)
Das Problem: Bei einem typischen Thema z. B. sucht eine einzelne 3.000-Zeilen-Datei mit vielen Treffern alle 10 Ergebnisplätze belegen, während sauberte kleinere Hilfsdateien verborgen bleiben.
So haben wir es gefixt: Wir haben eine Ergebnis-Varianz pro Datei eingeführt. Die Engine liefert maximal 2 beste Chunks pro Datei, damit du in der Ergebnisliste eine ausgewogene Mischung aus verschiedenen Teilen der Codebasis bekommst.
6. ⚡ Datenbank-Sperrkonflikte bei schnellen Speichervorgängen
Das Problem: Beim schnellen Wechseln von Aufgaben oder wenn viele Dateien schnell nacheinander gespeichert werden, kommt es beim Schreibvorgang zu LanceDB manchmal zu gleichzeitigen Versionskonflikten.
Wir haben es gelöst: Wir haben eine asynchrone Schreibwarteschlange mit exponentiellem Backoff eingeführt. Wenn ein Schreibkonflikt auftritt, wartet das System automatisch einige Millisekunden und versucht es sicher erneut, statt den Server zu beenden.
💡 Zusammenfassung
Durch die Kombination von ONNX-Embeddings im Prozess mit eingebettetem LanceDB, intelligenter Token-Erweiterung und Model Context Protocol (MCP) haben wir die Reibung bei der lokalen semantischen Suche beseitigt:
✅ Keine Hintergrund-Daemons auf deinem Rechner.
✅ Keine Python/ChromaDB-Abhängigkeiten.
✅ Kein Git-Rauschen (gespeichert in
node_modules/.cache).✅ Typos und Wortvarianten werden automatisch in < 1 ms behandelt.
✅ Sofortige Suche nach Bedeutung – verbindet deine natürsprachigen Fragen mit dem genauen Code und den Markdown-Dokumenten, die du brauchst.
Happy Coding! ☕️🚀
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.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Shared memory for AI coding agents. Save once, reuse from Cursor, Claude Code, Codex.
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.634 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