Your coding agent ist sehr gut darin, Dinge in einem Repository zu finden, solange sie Text sind. Fragen Sie Claude Code oder Cursor, was das Sensorspezifikationsblatt über die Betriebstemperatur sagt, und es greift zu grep, findet nichts und rät entweder oder gibt auf, weil das Datenblatt ein PDF und das Entscheidungsprotokoll eine Word‑Datei ist. GroupDocs.Search.Mcp läuft lokal in Docker und liefert dem Agenten einen Volltext‑Index über diese Dokumente, mit derselben Such‑dann‑Lese‑Schleife, die er bereits für Code verwendet:
Indexieren Sie den Ordner docs, dann sagen Sie mir, was das Sensorspezifikationsblatt über die Betriebstemperatur sagt und welcher ADR den Telemetriespeicher entschieden hat.
Die Schritt‑für‑Schritt‑Version mit Konfiguration und Fehlersuche finden Sie in der Dokumentation: Wie man Claude Code oder Cursor die PDFs und Word‑Dokumente in einem Repository durchsuchen lässt.
Warum liefert grep nichts zurück?
Weil PDF‑ und DOCX‑Dateien ihre Wörter nicht als Klartext speichern. Ein DOCX ist ein ZIP‑Archiv; ein PDF komprimiert seine Text‑Streams. Durchsucht man eines der beiden Byte für Byte, sind die Wörter nicht vorhanden. Wir haben das mit einem kleinen Repository getestet: ein PDF‑Datenblatt, ein Architecture Decision Record und ein Anforderungsdokument im DOCX‑Format sowie eine Quellcodedatei.
$ grep -ri "TimescaleDB\|operating temperature\|I2C" docs/
$ grep -rn "datasheet" src/
src/sensor.py:1:MAX_TEMP_C = 85 # see docs/datasheet
Der einzige Treffer ist ein Code‑Kommentar, der auf das Dokument verweist, das der Agent nicht lesen kann. Das ist die Lücke: Der Grund hinter einer Konstanten, die Entscheidung hinter einem Design, die Anforderung hinter einem Test leben oft genau in diesen Dateien.
Was ändert sich mit einem Index?
Der Agent erhält ein Retrieval‑Tool für Dokumente. Registrieren Sie den Server vom Repository‑Root aus, sodass das Repository als Speicherordner eingebunden wird:
claude mcp add groupdocs-search -- docker run --rm -i \
-v "$(pwd)":/data ghcr.io/groupdocs-search/search-net-mcp:latest
Dann liefern dieselben Fragen Antworten. Das hat der Server in unserem Test‑Repository zurückgegeben (Pfade relativ zum Repository‑Root angezeigt):
-> add_to_index {"documentsPath":"docs","indexName":"gateway"}
<- Indexed 'docs' into index 'gateway': 3 document(s) added,
3 in the index.
-> search {"query":"TimescaleDB","indexName":"gateway"}
<- documentsFound 1: docs/adr-007-telemetry-storage.docx
-> get_text_fragments {"query":"I2C","indexName":"gateway"}
<- === docs/requirements-v2.docx (1 occurrence(s)) ===
…REQ-15: the I2C bus runs at 400 kHz.…
=== docs/tmp117-sensor-datasheet.pdf (1 occurrence(s)) ===
…I2C address selection: ADD0 pin to GND gives 0x48…
Eine Abfrage fand die Anforderung und die Datenblatt‑Zeile zusammen, was die Art von Querverweis ist, die per Hand mühsam und mit grep unmöglich ist. In unserem kleinen Index kamen die Suchvorgänge nach dem ersten Aufruf in 80 bis 240 Millisekunden zurück.
Die Schleife, die der Agent bereits kennt
user agent Search MCP server
| "What does the datasheet say about I2C addresses?" |
|---------------->| |
| |-- search {"query":"I2C"} --------------->|
| |<- requirements-v2.docx, |
| | tmp117-sensor-datasheet.pdf ------------|
| |-- get_text_fragments {"query":"I2C"} --->|
| |<- "...ADD0 pin to GND gives 0x48..." -----|
|<- "0x48 with ADD0 to GND, 0x49 to V+ (datasheet, p.1); |
| REQ-15 runs the bus at 400 kHz." |
search gibt an, welche Dateien passen, get_text_fragments liefert die passenden Zeilen mit ein paar Kontextwörtern, und der Agent zitiert beide. Es ist die Form von grep, erweitert auf 82 Formate: PDF, DOCX, XLSX, PPTX, HTML, Markdown, sogar die E‑Mail‑Threads, die jemand ins Repo exportiert hat.
Dem Agent sagen, wann er es benutzen soll
Agenten folgen Projektanweisungen, wann sie ein Werkzeug greifen sollen. Drei Zeilen in CLAUDE.md oder AGENTS.md machen den Unterschied zwischen einem Agenten, der grep versucht, scheitert und aufgibt, und einem, der zuerst den Index durchsucht:
PDF, DOCX and XLSX files under docs/ are indexed in the groupdocs-search MCP index
'docs'. grep cannot read them: use search (quote phrases) and get_text_fragments
for anything in specs, datasheets or ADRs, and cite the file.
Run update_index (indexName: docs) after pulling changes.
Zwei organisatorische Punkte: Der Index wird in .groupdocs-search-index/ im Root des eingebundenen Ordners geschrieben, also fügen Sie das zu .gitignore hinzu. Und nach einem Pull liest update_index nur das neu Geänderte neu ein, sodass das aktuelle Halten des Index nur einen Aufruf kostet.
Cursor und VS Code
Der gleiche Container funktioniert in jedem MCP‑Client. In VS Code kann ein Workspace‑File .vscode/mcp.json beliebige offene Ordner einbinden, sodass der Index dem Projekt folgt:
{
"servers": {
"groupdocs-search": {
"type": "stdio",
"command": "docker",
"args": [ "run", "--rm", "-i",
"-v", "${workspaceFolder}:/data",
"ghcr.io/groupdocs-search/search-net-mcp:latest" ]
}
}
}
Cursor verwendet denselben command und dieselben args unter mcpServers in .cursor/mcp.json. Committen Sie die Konfigurationsdatei und jeder Entwickler im Projekt bekommt das Werkzeug; halten Sie den Index selbst aus Git.
Warum nicht alles zuerst in Text konvertieren?
Sie können: Lassen Sie den Agenten jedes PDF bei Bedarf konvertieren oder prüfen Sie Markdown‑Kopien im Repository. Beide Ansätze funktionieren für ein paar Dateien. Der Index führt die Konvertierung einmal aus, hält sie mit einem Aufruf aktuell und beantwortet, welche Datei relevant ist, bevor der Agent überhaupt liest – das ist der Schritt, der den Kontext einer langen Sitzung klein hält. Die Engine dahinter ist GroupDocs.Search, das Office‑ und PDF‑Dokumente direkt liest, anstatt über einen Konverter, den Sie warten müssten.
Ehrliche Grenzen
- Im Evaluierungsmodus hält ein Index höchstens 100 Dokumente und eine Suche liefert höchstens 10 Ergebnisse; rufen Sie zuerst
get_license_statusauf. - Volltext, nicht semantisch: Der Agent muss die Wörter benutzen, die die Dokumente verwenden, oder Varianten ausprobieren.
- Kein OCR: Ein gescanntes Datenblatt ohne Textebene wird nur nach seinen Dateieigenschaften indexiert.
- Nur Docker. Unter Linux fügen Sie
--user "$(id -u):$(id -g)"hinzu, damit der Container den Index in ein Repository schreiben kann, das Ihnen gehört.
FAQ
Kann Claude Code PDF‑Dateien in meinem Repository lesen?
Nicht mit grep. Mit dem GroupDocs.Search MCP‑Server kann er sie lokal durchsuchen und zitieren, ohne sie vorher zu konvertieren.
Funktioniert das auch in Cursor und VS Code?
Ja. Verwenden Sie dieselben docker run‑Argumente in .cursor/mcp.json bzw. .vscode/mcp.json; VS Code kann ${workspaceFolder} einbinden.
Wird der Index in meinen Commits landen?
Nur, wenn Sie es zulassen. Fügen Sie .groupdocs-search-index/ zu .gitignore hinzu.
Tiefer einsteigen
- Dokumentation, kanonische Anleitung: Wie man Claude Code oder Cursor die PDFs und Word‑Dokumente in einem Repository durchsuchen lässt
- Dokumentationszentrum: GroupDocs.Search MCP Server
- Hier starten: Brauchen Sie eine Vektor‑Datenbank, um Fragen zu einem Ordner mit Dokumenten zu stellen?
- Verwandt: Fundierte Antworten aus Ihren Dateien: Zitieren Sie den Abschnitt, nicht das Gedächtnis des Modells
- Verwandt: Projekt‑Gedächtnis für KI‑Agenten: ein Index pro Projekt, stets aktuell gehalten
- Verwandt: Warum ein KI‑Agent nicht 300 Verträge lesen sollte, um eine Frage zu beantworten
- Verwandt: Durchsuchen Sie Ihr E‑Mail‑Archiv mit einem KI‑Agenten: PST, MSG, EML und die darin enthaltenen Anhänge
- On‑Premise‑ und Sicherheitsmodell: 3 Architekturen für KI‑Dokumentenverarbeitung und die, die Dateien innerhalb Ihres Netzwerks hält
- Fragen: GroupDocs Search Forum
- Quelle: GroupDocs.Search.Mcp auf GitHub