Durchsuchen Sie private Dokumente über einen MCP-Client oder das Terminal, ohne sie an eine Embedding-API zu senden.
mcp-local-rag indexiert PDF-, DOCX-, Markdown- und Textdateien auf Ihrem Rechner. Die Suche kombiniert semantische Ähnlichkeit mit Stichwortübereinstimmung, sodass Abfragen sowohl die Absicht als auch exakte technische Begriffe wie API-Namen, Klassennamen und Fehlercodes abdecken.
Läuft lokal: Dokumentanalyse, Embeddings, Speicherung und Suche laufen auf Ihrem Rechner. Nach dem ersten Modell-Download funktionieren Texterfassung und Suche offline.
Hybride Suche: Semantische Abfrage findet verwandte Konzepte, während die Stichwortübereinstimmung exakte technische Begriffe hervorhebt.
Konfigurierbare Embeddings: Wählen Sie ein Hugging-Face-Embedding-Modell, das zur Sprache und Domäne Ihrer Dokumente passt.
Semantisches Chunking: Dokumente werden an Themenwechseln statt an festen Zeichenzahlen geteilt. Markdown-Codeblöcke bleiben intakt.
MCP und CLI: Verwenden Sie denselben Index aus einem KI-Codierungstool oder direkt vom Terminal aus.
Kein API-Schlüssel, kein Docker, kein Python und keine externe Datenbank erforderlich.
Related MCP server: cowork-semantic-search
Node.js 22 oder neuer
Internetzugang beim ersten Gebrauch, um das npm-Paket und das Embedding-Modell herunterzuladen
Ein Verzeichnis mit den Dokumenten, die Sie durchsuchen möchten
Setzen Sie BASE_DIR auf dieses Verzeichnis. Es ist auch die Sicherheitsgrenze für Dateioperationen. Ersetzen
Sie /absolute/path/to/your/documents unten durch den absoluten Pfad des Verzeichnisses.
mcp-local-rag verwendet das Standard-MCP-Protokoll über einen lokalen stdio-Server und funktioniert daher mit KI-Codierungstools und anderen MCP-Hosts, die lokale MCP-Server unterstützen.
Verwenden Sie eines der Beispiele unten oder registrieren Sie npx -y mcp-local-rag und setzen Sie BASE_DIR mit
dem MCP-Konfigurationsformat Ihres Clients.
Für Claude Code: Führen Sie diesen Befehl aus:
claude mcp add local-rag --scope user --env BASE_DIR=/absolute/path/to/your/documents -- npx -y mcp-local-ragFür Codex: Fügen Sie zu ~/.codex/config.toml hinzu:
[mcp_servers.local-rag]
command = "npx"
args = ["-y", "mcp-local-rag"]
[mcp_servers.local-rag.env]
BASE_DIR = "/absolute/path/to/your/documents"Für OpenCode: Fügen Sie zu ~/.config/opencode/opencode.json (oder opencode.jsonc) hinzu:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"local-rag": {
"type": "local",
"command": ["npx", "-y", "mcp-local-rag"],
"environment": {
"BASE_DIR": "/absolute/path/to/your/documents"
}
}
}
}Für Cursor: Fügen Sie zu ~/.cursor/mcp.json hinzu:
{
"mcpServers": {
"local-rag": {
"command": "npx",
"args": ["-y", "mcp-local-rag"],
"env": {
"BASE_DIR": "/absolute/path/to/your/documents"
}
}
}
}Starten Sie den Client neu und bitten Sie ihn dann, den Index zu erstellen:
Sync all documents in the configured root and wait until it finishes.Die erste Synchronisierung lädt das Standard-Embedding-Modell herunter (ca. 90 MB) und kann 1–2 Minuten dauern, bevor die Erfassung beginnt. Spätere Ausführungen verwenden den lokalen Cache.
Sobald die Synchronisierung abgeschlossen ist:
What does the API documentation say about authentication?Um die CLI ohne MCP-Client zu verwenden:
npx mcp-local-rag ingest ./docs/
npx mcp-local-rag query "authentication API"Die CLI verwendet standardmäßig das aktuelle Verzeichnis als Dokumentstamm. Führen Sie beide Befehle aus demselben
Verzeichnis aus, damit sie denselben Standardindex verwenden, oder setzen Sie BASE_DIR und DB_PATH explizit.
Einige Dokumentbestände können aufgrund von Vertraulichkeit oder Organisationsrichtlinien nicht an einen gehosteten Embedding-Dienst gesendet werden. Wenn der Index lokal bleibt, werden sie durchsuchbar, ohne dass pro Abfrage API-Kosten entstehen.
Semantische Suche allein kann exakte Bezeichner übersehen, die in technischer Dokumentation wichtig sind. Stichwort-Reranking hält diese Begriffe sichtbar, ohne auf natürlichsprachliche Abfrage zu verzichten.
Eingabe | Wie zu erfassen |
PDF, DOCX, TXT, Markdown | Dateierfassung oder Verzeichnissynchronisierung |
HTML, das bereits vom Client abgerufen wurde |
|
Klartext oder Markdown im Speicher |
|
HTML-Abruf ist nicht in den Server integriert. Ein MCP-Client kann eine Seite abrufen und ihr HTML an
ingest_data übergeben.
Excel, PowerPoint, eigenständige Bilder und Quellcode-Dateierweiterungen werden von der Dateierfassung nicht unterstützt. PDFs können optional ein lokales Vision-Modell verwenden, um Abbildungen zu beschreiben, aber das ist keine OCR oder Bildsuche.
Tool | Zweck |
| Index mit allen konfigurierten Wurzeln oder einem Pfad abgleichen |
| Laufenden Synchronisierungsjob abfragen |
| Eine Datei erfassen oder ersetzen |
| Text, Markdown oder HTML erfassen, das der Client bereits hat |
| Suche mit semantischem Abgleich und Stichwortverstärkung |
| Umgebende Chunks aus einem Suchergebnis lesen |
| Unterstützte Dateien und ihren Erfassungsstatus anzeigen |
| Eine indexierte Datei oder ein |
| Index- und Suchstatus anzeigen |
sync_start erfasst neue und geänderte Dateien, überspringt byteidentische Dateien und entfernt Indexeinträge
für Dateien, die nicht mehr existieren:
Sync everything under the configured document roots and wait for completion.Das Tool gibt sofort eine jobId zurück. Clients sollten sync_status abfragen, bis der Status succeeded
oder failed wird. Die Synchronisierung erzeugt keine visuellen Bildunterschriften. Setzen Sie STORE_IMAGES=true
in der MCP-Serverumgebung, um unterstützte PDF- und DOCX-Bilder für neue oder geänderte Dateien zu speichern, die
von der Synchronisierung ausgewählt wurden; unveränderte Dateien bleiben übersprungen.
Nur ein Synchronisierungsjob wird vom Serverprozess aufbewahrt. Ein neuerer Job ersetzt einen abgeschlossenen Datensatz, und ein Neustart des Servers verwirft ihn.
ingest_file akzeptiert PDF, DOCX, TXT und Markdown. MCP-Dateipfade müssen absolut sein und innerhalb einer
konfigurierten Dokumentwurzel liegen:
Ingest the document at /Users/me/docs/api-spec.pdf.Das erneute Erfassen desselben Pfads ersetzt seine vorhandenen Chunks.
What does the API documentation say about authentication?
Find the documented behavior of ERR_CONNECTION_REFUSED.Ergebnisse enthalten den Text, den Quellpfad, den Titel, den Chunk-Index, den Relevanzwert und alle auf diesem
Chunk gespeicherten Bilder. MCP gibt jedes Bild als Bild-Content-Block gepaart mit seiner Ergebnisidentität zurück;
die CLI-query enthält ein images-Array aus { imageIndex, mimeType, data } in jedem Ergebnis. Übergeben Sie den
chunkIndex und entweder filePath oder source aus einem Ergebnis an read_chunk_neighbors, wenn die Antwort
mehr Kontext benötigt:
Read the surrounding chunks for that authentication result.Sowohl query_documents als auch list_files akzeptieren ein optionales absolutes scope-Pfadpräfix oder eine
Liste von Präfixen. Ein Präfix stimmt mit dem exakten Pfad und seinen Unterelementen überein.
Verwenden Sie ingest_data, nachdem der MCP-Client eine Seite abgerufen hat:
Fetch https://example.com/docs and ingest the HTML.Der Server extrahiert den Hauptartikel, konvertiert ihn in Markdown und speichert ihn unter der angegebenen Quellkennung. Die Wiederverwendung derselben Quelle aktualisiert den vorhandenen Inhalt.
Respektieren Sie die Bedingungen und Urheberrechte der Quellwebsite, wenn Sie externe Inhalte indexieren.
Der visuelle Modus fügt eine generierte Bildunterschrift für figurenreiche PDF-Seiten hinzu. Er ist optional und lädt während der normalen Erfassung kein Vision-Modell.
Ingest /Users/me/docs/research-paper.pdf with visual: true.npx mcp-local-rag ingest ./docs/research-paper.pdf --visualDie Bildspeicherung ist unabhängig von visuellen Bildunterschriften. Setzen Sie STORE_IMAGES=true für den
MCP-Server oder übergeben Sie --images an CLI-Erfassung und -Synchronisierung:
npx mcp-local-rag ingest ./docs/research-paper.pdf --images
npx mcp-local-rag sync ./docs/ --imagesDie PDF-Speicherung verwendet erkannte Abbildungs-/Tabellenbereiche. Die DOCX-Speicherung enthält nur PNG/JPEG-Bilder,
die die vorhandene Mammoth-Konvertierung als <img> ausgibt; Diagramme, SmartArt und Formen werden nicht separat
gerendert. Gespeicherte Bilder folgen ihrem umgebenden Text in den endgültigen semantischen Chunk und verändern
weder Ranking, Bewertungen noch Ergebnisanzahl.
|
| PDF-Verhalten |
false | false | Nur Text; keine visuellen Bildunterschriften oder zurückgegebenen Bilder. |
true | false | Generierte Bildunterschriften werden durchsuchbarer Text; keine Bilder werden gespeichert oder zurückgegeben. |
true | true | Generierte Bildunterschriften werden durchsuchbarer Text, und Bilder aus übereinstimmenden Chunks werden inline zurückgegeben. |
false | true | Bilder werden an nahegelegenen beibehaltenen PDF-Text angehängt und für übereinstimmende Chunks inline zurückgegeben; das VLM wird nicht importiert, geladen oder ausgeführt. |
Profil | Modell-Cache | Verwendungszweck |
| ca. 250 MB | Leichte visuelle Indexierung |
| ca. 2,9 GB | Abbildungen mit Beschriftungen, Anmerkungen oder anderem Text im Bild |
Wählen Sie das größere Modell mit visualQuality: "quality" über MCP oder
--visual-quality quality über CLI. Die gemessene CPU-Inferenz war etwa doppelt so langsam wie fast,
obwohl die Ergebnisse von Hardware und Modellaktualisierungen abhängen.
Bildunterschriften sind Hilfstext, keine getreuen Transkriptionen. Behandeln Sie abgerufene Bildunterschriften und Dokumenttext als unvertrauenswürdige Eingabe und nicht als Anweisungen.
Bei hohen Limits können übereinstimmende Chunks und ihre Anhänge die Modell-/Client-Kontextgrenze erreichen; wählen Sie das Abfragelimit mit Blick auf den verfügbaren Kontext des aufrufenden Modells.
Die CLI verwendet denselben Parser, Embedder und Vektorspeicher ohne MCP-Client:
npx mcp-local-rag ingest ./docs/
npx mcp-local-rag sync ./docs/
npx mcp-local-rag query "authentication API"
npx mcp-local-rag query "auth" --scope /docs/api --scope /docs/guide
npx mcp-local-rag read-neighbors --file-path /abs/path.md --chunk-index 5
npx mcp-local-rag list
npx mcp-local-rag status
npx mcp-local-rag delete ./docs/old.pdf
npx mcp-local-rag delete --source "https://example.com/docs"Globale Optionen wie --db-path, --cache-dir und --model-name stehen vor dem Unterbefehl.
Unterbefehlsoptionen folgen danach:
npx mcp-local-rag --db-path ./my-db query "authentication"Führen Sie npx mcp-local-rag --help für die vollständige Befehlsreferenz aus.
Die CLI liest keine MCP-Clientkonfiguration. Setzen Sie dieselben Umgebungsvariablen oder Flags, wenn beide
Schnittstellen einen Index gemeinsam nutzen sollen. Insbesondere müssen MODEL_NAME und das CLI---model-name
für eine gemeinsame Datenbank übereinstimmen.
Die Stichwortverstärkung ist standardmäßig aktiviert. Relevanzlücken-Gruppierung sowie die Distanz- und Dateifilter sind optionale Steuerungen für Korpora, die eine engere Ergebnisauswahl benötigen.
Variable | Standard | Beschreibung |
|
| Stichwortverstärkungsfaktor (0,0–1,0). 0 deaktiviert das Stichwort-Reranking; 1 wendet die maximale Verstärkung an. |
| (nicht gesetzt) |
|
| (nicht gesetzt) | Ergebnisse mit geringer Relevanz herausfiltern (z. B. |
| (nicht gesetzt) | Ergebnisse auf die Top-N-Dateien begrenzen (z. B. |
Für API-Spezifikationen und andere Dokumente mit vielen Bezeichnern kann eine stärkere Stichwortgewichtung das Ranking exakter Begriffe verbessern:
"env": {
"RAG_HYBRID_WEIGHT": "0.7"
}0.7: etwas stärkeres Re-Ranking exakter Begriffe als der Standard
1.0: maximale Keyword-Verstärkung
Bei der Aufnahme:
Der Parser extrahiert Text für das Eingabeformat.
Der semantische Chunker findet Themengrenzen und erhält Markdown-Codeblöcke.
Transformers.js erstellt Embeddings lokal.
LanceDB speichert die Chunks, Metadaten, Vektoren und den Volltextindex.
Bei der Suche:
Die Abfrage wird mit demselben Modell eingebettet.
Die Vektorsuche ruft semantisch verwandte Chunks ab.
Optionale Distanz- und Relevanzgruppenfilter grenzen die Kandidaten ein, wenn sie konfiguriert sind.
Volltextübereinstimmungen verstärken exakte Abfragebegriffe.
Agent Skills bieten Abfrage- und Aufnahmehilfe für KI-Assistenten:
npx mcp-local-rag skills install --claude-code
npx mcp-local-rag skills install --claude-code --global
npx mcp-local-rag skills install --codexInstallierte Skills umfassen Abfrageformulierung, Ergebnisverfeinerung und HTML-Aufnahme. Bitten Sie den Assistenten, den Skill mcp-local-rag explizit zu verwenden, wenn er nicht automatisch aktiviert wird.
Der MCP-Server liest Umgebungsvariablen. Die CLI akzeptiert die aufgeführten globalen Umgebungsvariablen
und Flags; die Bildspeicherung bei CLI-Aufnahme und -Synchronisierung ist nur mit --images aktiviert.
Umgebungsvariable | CLI-Flag | Standard | Beschreibung |
|
| Aktuelles Verzeichnis | Ein Dokumentstamm; das CLI-Flag ist bei |
| N/A | (nicht gesetzt) | JSON-Array von Dokumentstämmen; hat Vorrang vor |
|
|
| Speicherort der Vektordatenbank |
|
|
| Modell-Cache-Verzeichnis |
|
|
| Hugging-Face-Embedding-Modell |
|
|
| Maximale Dateigröße in Bytes |
|
|
| Minimale Chunk-Länge in Zeichen (1–10000) |
| N/A |
| Nur MCP-Server: unterstützte PDF/DOCX-Bilder speichern und mit passenden Chunks zurückgeben. CLI nutzt |
| N/A |
| ONNX-Runtime-Ausführungsgerät |
| N/A |
| Embedding-Datentyp, der an das ausgewählte Modell übergeben wird |
BASE_DIR und BASE_DIRS)mcp-local-rag erlaubt Dateioperationen nur innerhalb konfigurierter Stämme. Für mehrere Stämme
muss BASE_DIRS ein JSON-Array aus nicht-leeren Pfaden sein:
export BASE_DIRS='["/Users/me/Documents/work","/Users/me/Projects/specs"]'Die Stammkonfiguration wird in dieser Reihenfolge aufgelöst:
CLI---base-dir <pfad>-Flags (wiederholbar bei ingest, list und sync)
BASE_DIRS
BASE_DIR
Aktuelles Verzeichnis
Jede Quelle ersetzt die Quelle mit niedrigerer Priorität, anstatt mit ihr zusammengeführt zu werden. Eine ungültige
BASE_DIRS-Konfiguration schlägt fehl, anstatt auf BASE_DIR oder das aktuelle Verzeichnis zurückzufallen. status
bleibt in MCP verfügbar, damit der Client den Konfigurationsfehler melden kann.
npx mcp-local-rag ingest --base-dir /Users/me/work --base-dir /Users/me/specs /Users/me/work/readme.md
npx mcp-local-rag list --base-dir /Users/me/work --base-dir /Users/me/specs
npx mcp-local-rag sync --base-dir /Users/me/work --base-dir /Users/me/specs
BASE_DIRS='["/Users/me/work","/Users/me/specs"]' npx mcp-local-rag listDB_PATH und CACHE_DIR sind standardmäßig relativ zum Prozess-Arbeitsverzeichnis. Legen Sie absolute
Pfade fest, wenn der MCP-Client den Server aus verschiedenen Projektverzeichnissen starten kann.
Setzen Sie MODEL_NAME oder übergeben Sie --model-name, um ein Hugging-Face-Embedding-Modell zu wählen,
das zur Sprache und Domäne Ihrer Dokumente passt.
mcp-local-rag erzeugt Embeddings mit Mean Pooling und L2-Normalisierung. Prüfen Sie bei der Modellwahl, ob diese Einstellungen zur empfohlenen Inferenzkonfiguration des Modells passen, da die Pooling-Methode die Abfragequalität beeinflussen kann.
Eine Änderung von MODEL_NAME, RAG_DEVICE oder RAG_DTYPE kann bestehende Vektoren inkompatibel machen.
Verwenden Sie nach einer Änderung der Embedding-Konfiguration einen neuen DB_PATH oder löschen Sie den
bestehenden Index und nehmen Sie die Daten erneut auf.
Ein Beispielmodell für englische Dokumente ist Xenova/bge-small-en-v1.5.
Der Dateizugriff ist auf BASE_DIR-, BASE_DIRS- oder CLI---base-dir-Stämme beschränkt.
Symlinks, die außerhalb jedes konfigurierten Stamms auflösen, werden abgelehnt.
Dokumentverarbeitung und Suche tätigen keine Netzwerkanfragen, nachdem die erforderlichen Modelle zwischengespeichert sind.
Der Server ist für einen einzelnen lokalen Benutzer ausgelegt und bietet keine Authentifizierung oder Zugriffskontrolle.
Führen Sie nicht mehrere CLI- oder MCP-Schreiber gegen denselben DB_PATH aus. Schreibgeschützte Abfragen können
während einer aktiven Synchronisierung ausgeführt werden.
Sichern Sie einen Index, indem Sie sein DB_PATH-Verzeichnis kopieren, während kein Schreiber aktiv ist.
Dokumente müssen zuerst aufgenommen werden. Führen Sie „Alle aufgenommenen Dateien auflisten" aus, um dies zu überprüfen.
Überprüfen Sie die Internetverbindung. Wenn Sie hinter einem Proxy sind, konfigurieren Sie die Netzwerkeinstellungen. Das Modell kann auch manuell heruntergeladen werden.
Das Standardlimit beträgt 100MB. Teilen Sie große Dateien auf oder erhöhen Sie MAX_FILE_SIZE.
Überprüfen Sie die Chunk-Anzahl mit status. Große Dokumente mit vielen Chunks können Abfragen verlangsamen. Erwägen Sie, sehr große Dateien aufzuteilen.
Stellen Sie sicher, dass Dateipfade innerhalb eines der konfigurierten Stämme liegen (BASE_DIR, ein beliebiger BASE_DIRS-Eintrag oder ein beliebiges CLI---base-dir). Verwenden Sie absolute Pfade.
BASE_DIRS akzeptiert ein JSON-Array aus einem oder mehreren nicht-leeren Pfadzeichenfolgen:
Gültig: BASE_DIRS='["/Users/me/work","/Users/me/specs"]'
Ungültig: BASE_DIRS=/a:/b (Trennzeichensyntax wird nicht unterstützt)
Ungültig: BASE_DIRS='[]' (leeres Array)
Überprüfen Sie die Syntax der Konfigurationsdatei
Starten Sie den Client vollständig neu (Cmd+Q auf dem Mac für Cursor)
Direkt testen: npx mcp-local-rag sollte ohne Fehler ausgeführt werden
Beiträge sind willkommen! Siehe CONTRIBUTING.md für Einrichtung und Richtlinien.
MIT-Lizenz. Kostenlos für private und kommerzielle Nutzung.
Building a Local RAG for Agentic Coding: Technischer Deep-Dive in das semantische Chunking und das hybride Suchdesign.
Erstellt mit Model Context Protocol von Anthropic, LanceDB und Transformers.js.
Delete a previously ingested file or data from the vector database. Use filePath for files ingested via ingest_file, or source for data ingested via ingest_data. Either filePath or source must be provided. Returns deleted (operation succeeded), removedChunks, and existed (whether anything was actually present).
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Source identifier used in ingest_data. Examples: "https://example.com/page", "clipboard://2024-12-30" | |
| filePath | No | Absolute path to the file (for ingest_file). Example: "/Users/user/documents/manual.pdf" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Mentions return fields but does not disclose side effects, permissions, or error cases (e.g., what happens if nothing matches).
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?
Three concise sentences with no redundancy. Purpose, usage, and return are clearly separated and front-loaded.
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?
Covers purpose, parameters, constraints, and return values. Lacks explanation of edge cases (both params provided or neither) but is generally sufficient given tool 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 coverage is 100%, yet description adds context by linking each parameter to the specific ingestion method and clarifying the mutual exclusivity requirement, which is not in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (delete) and object (previously ingested file/data from vector database). Distinguishes from sibling tools which are for ingestion, listing, querying, etc.
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?
Explicitly instructs when to use filePath vs. source and states that at least one must be provided. Could further specify behavior if both are given or if the item does not exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ingest in-memory content as a string (use ingest_file for files on disk). The source identifier enables re-ingestion to update existing content. Returns { filePath, chunkCount, timestamp, fileTitle }.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The content to ingest (text, HTML, or Markdown) | |
| metadata | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return format but does not discuss side effects, idempotency, or rate limits. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste: first sentence states purpose and sibling alternative, second sentence adds key behavioral detail and return format. Front-loaded and 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?
Given nested object parameters and no output schema, the description covers purpose, parameters with examples, and return values. Lacks error conditions or prerequisites, but sufficient for most agents.
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?
Description adds meaning to both parameters: content format types and detailed metadata source examples. Schema coverage is 50% but description compensates with concrete usage guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it ingests in-memory content as a string and differentiates from ingest_file for files on disk. Specific verb+resource with clear distinction from a sibling tool.
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?
Explicitly mentions when to use this tool ('use ingest_file for files on disk') and hints at re-ingestion capability. Lacks explicit when-not-to-use scenarios, but the sibling distinction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ingest a document file (PDF, DOCX, TXT, MD) into the vector database. Path must be absolute; re-ingesting the same path replaces its existing data. Returns { filePath, chunkCount, timestamp, fileTitle }.
| Name | Required | Description | Default |
|---|---|---|---|
| visual | No | Run VLM captioning on figure pages (PDF only; default false). | |
| filePath | Yes | Absolute path to the file to ingest. Example: "/Users/user/documents/manual.pdf" | |
| visualQuality | No | VLM profile when visual is true (default "fast"). "quality" is more accurate on figures with in-image text but much heavier and slower. Ignored when visual is false. | fast |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that ingestion is a write operation, that re-ingesting replaces existing data, and that it supports VLM captioning for PDFs with different quality profiles. It also specifies the return structure. This is thorough for a tool of this complexity.
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 concise sentences. The first sentence front-loads the main purpose, and the second adds critical behavioral details. No extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no nested objects, the description covers input requirements (absolute path), behavior (replace on re-ingest), return fields, and an optional feature (VLM captioning). It briefly addresses PDF-only behavior. Missing details like error handling or unsupported file types, but overall sufficient for this complexity level.
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 baseline is 3. The description adds context like 'Path must be absolute' and the effect of re-ingesting, but the schema already describes each parameter adequately. No additional semantic depth beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Ingest', the resource 'document file (PDF, DOCX, TXT, MD)', and the destination 'into the vector database'. It distinguishes from siblings like 'delete_file' and 'list_files' by specifying file ingestion. The mention of absolute path and re-ingest behavior adds specificity.
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 some usage context: 'Path must be absolute' and 're-ingesting the same path replaces its existing data'. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'ingest_data'), nor does it give exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported files (PDF, DOCX, TXT, MD) under the configured base directories and whether each is ingested. Returns { baseDirs, files, sources }; sources lists ingested items reported apart from the file scan, chiefly ingest_data content (web pages, clipboard, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Optional absolute path prefix(es) — one string or a list (unioned) — restricting the listing to files reachable at a path equal to or under a prefix within the base directories. "/docs/api" matches "/docs/api/x.md" but not "/docs/apiv2". Must be absolute (server OS style); a relative prefix matches nothing. A prefix outside every base directory yields an empty files list, so compare it against the baseDirs in the response before concluding no files exist. Scope filters files by their scan path; ingest_data sources, which have no base-directory path, are always listed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds value by explaining that 'sources' contains ingested items like web pages/clipboard, and that files are scanned from base directories. It doesn't explicitly state this is read-only or describe side effects, but the 'list' verb implies safety. Some edge behavior (e.g., invalid scope yielding empty files list) is only visible in the schema, not the description.
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 concise sentences: the first states the core purpose, and the second explains the return structure and the 'sources' nuance. There is no redundancy or filler, and the most important information is front-loaded.
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 listing tool with one optional parameter and no output schema, the description sufficiently covers the purpose, return shape, and the non-obvious 'sources' concept. It doesn't need to explain return values in detail since the return shape is stated. Path edge cases are handled in the schema, so the description is complete enough for correct selection and invocation.
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 schema description covers 100% of the parameter 'scope' with a detailed explanation of prefix matching and path constraints. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('list') and resource ('supported files (PDF, DOCX, TXT, MD)') under configured base directories, plus the ingestion status. This clearly distinguishes it from sibling tools like ingest_file, delete_file, and sync_status, which perform different operations.
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 clearly implies the tool is for inspecting the file inventory and its ingestion status, which is a distinct use case. It also explains the return shape to set expectations. However, it doesn't explicitly mention when not to use it or reference sibling alternatives, though the purpose is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ingested documents with hybrid keyword + semantic matching. Returns results sorted by relevance, each with filePath, chunkIndex, text, fileTitle, score (0 = best, higher = worse), and source (for ingest_data items).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10, range 1-20). Lower favors precision, higher recall. | |
| query | Yes | Search query. Preserve specific user terms (for keyword match); add context when the query is vague (for semantic match). | |
| scope | No | Optional absolute path prefix(es) — one string or a list (unioned) — restricting results to a filePath equal to or under a prefix. "/docs/api" matches "/docs/api/auth.md" but not "/docs/apiv2". Must be absolute (server OS style); a relative prefix matches nothing — derive one from a filePath returned by an earlier query, or omit scope. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description details return fields, sorting by relevance, and score meaning (0=best, higher=worse). It lacks pagination details but is generally transparent for a read-only search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with clear, front-loaded purpose and a concise list of return fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers purpose, behavior, and return fields comprehensively. Context from sibling tools and parameter count is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds value by listing output fields not present in schema, enhancing parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches ingested documents using hybrid keyword and semantic matching, and lists the return fields. It is distinct from sibling tools like list_files and read_chunk_neighbors.
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 when to use (for searching documents) but does not explicitly state when not to use or provide alternatives among siblings. No exclusion criteria mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the chunks immediately before and after a query_documents result, in the same document, for more surrounding context. Pass chunkIndex from the result plus exactly one of filePath (ingest_file) or source (ingest_data). Returns the target chunk (isTarget: true) and its neighbors, ascending by chunkIndex; an out-of-range chunkIndex returns []. Defaults: before=2, after=2 (max 50 each).
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Number of chunks to retrieve after the target (0–50, default 2). | |
| before | No | Number of chunks to retrieve before the target (0–50, default 2). | |
| source | No | Source identifier (for ingest_data documents). Provide exactly one of filePath or source. Examples: "https://example.com/page", "clipboard://2024-12-30". | |
| filePath | No | Absolute path to the file (for ingest_file documents). Provide exactly one of filePath or source. Example: "/Users/user/documents/manual.pdf". | |
| chunkIndex | Yes | Zero-based target chunk index (non-negative integer). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It details the behavior (reads neighbors), return structure (target with isTarget: true, ascending order), edge case (out-of-range returns []), and limits (defaults before/after=2, max 50 each). No contradictions.
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 sentences, concise, and front-loaded with the most important information. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully covers the tool's behavior, parameter usage, return structure, and edge cases. It ties to the sibling tool query_documents, providing necessary context for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with descriptions for all five parameters. The description adds value by explaining the mutual exclusivity of filePath and source, the default values for before and after, and the connection to query_documents for chunkIndex.
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 specifies the verb ('Read'), the resource ('chunks immediately before and after'), and the context ('in the same document, for more surrounding context'). It ties the tool to query_documents, distinguishing it from siblings like query_documents itself.
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?
It provides explicit instructions on parameter usage: pass chunkIndex from query_documents and exactly one of filePath or source. It also states defaults and max limits. However, it doesn't explicitly state when not to use this tool or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get index status: { documentCount, chunkCount, memoryUsage (MB), uptime (s), ftsIndexEnabled, searchMode }.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not explicitly state read-only nature or other behavioral traits like cost or side effects.
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?
Single sentence, front-loaded with action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, description fully covers functionality and return format.
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?
No parameters exist; description adds value by listing return fields beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it gets index status and lists return fields, clearly distinguishing from sibling tools like delete_file or query_documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives, but the simple nature (no parameters) makes usage implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reconcile the index with the files on disk: ingest new and changed files, leave unchanged files alone, and remove index entries for files that are gone. Returns { jobId } without waiting for the run to finish; poll sync_status with that jobId for progress and the final outcome. Only one job is kept, and it is lost when the server process exits.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Optional absolute path to a file or directory inside a configured base directory; list_files returns those directories as baseDirs. A file synchronizes only itself and a directory only its own subtree, leaving every path outside it untouched. Omit it to synchronize every configured base directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: asynchronous execution (returns jobId without waiting), single-job constraint, and job loss on server exit. It also notes that index entries are removed for missing files, making side effects transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: the first states the core purpose, the second explains the return value and polling, and the third adds a critical lifecycle constraint. Every sentence contributes essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter, no annotations, and no output schema, the description fully captures the tool's behavior, return format, and lifecycle. It also refers to sync_status for progress, completing the operational picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a 100% coverage description for the 'path' parameter, explaining its optionality, scope, and behavior. The tool description adds no extra parameter context, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Reconcile the index with the files on disk' and enumerates specific behaviors (ingest new/changed, leave unchanged, remove gone entries). This distinguishes it from sibling tools like ingest_file or delete_file, which handle single files.
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 this tool (reconciling an index with disk state) and implicitly contrasts with sync_status for polling. It lacks explicit 'when not to use' statements or alternative tool names, but the context is unambiguous enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current or latest sync job record: { jobId, state ("running" | "succeeded" | "failed"), total (null until scanning has counted the files on disk), completed (upserted + skipped + empty; pruned is counted separately), summary { upserted, skipped, empty, pruned }, warnings, error (null unless the job failed) }. An unknown jobId means the job was replaced by a newer one or lost with a previous server process.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | Identifier returned by sync_start. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes full responsibility for behavioral disclosure. It transparently explains field nullability (total null until scanning, error null unless failed), the enumerated state values, and the unknown jobId case. This gives the agent a complete picture of expected behavior and edge cases.
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 dense but intentionally structured to mirror the returned object, making the field relationships clear. The second sentence adds essential edge-case information without fluff. It is compact given the amount of detail about the response shape.
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 output schema, the description fully defines every return field and its conditional behavior, including a nested summary object. It also references sync_start and server process loss to situate usage, making the tool self-sufficient in context.
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 schema already covers jobId ('Identifier returned by sync_start') at 100% coverage. The description adds extra meaning beyond the schema by explaining the consequences of an unknown jobId, which enriches the parameter's semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get the current or latest sync job record', providing a specific verb+resource. It further details the exact output shape including state values, total/completed semantics, and nested summary, clearly distinguishing it from sibling tools like sync_start.
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 clearly implies usage: after starting a sync job, call this to retrieve its status. It explains the meaning of an unknown jobId (replaced or lost with server process), which guides the agent on interpreting results. However, it does not explicitly name alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.17.3list_files1 field changedInput schema / properties / scope / descriptionPrevious value: -"Optional absolute path prefix(es) — one string or a list (unioned) — restricting the listing to files reachable at a path equal to or under a prefix within the base directories. \"/docs/api\" matches \"/docs/api/x.md\" but not \"/docs/apiv2\". Must be absolute (server OS style); a relative prefix matches nothing. Scope filters files by their scan path; ingest_data sources, which have no base-directory path, are always listed."New value: +"Optional absolute path prefix(es) — one string or a list (unioned) — restricting the listing to files reachable at a path equal to or under a prefix within the base directories. \"/docs/api\" matches \"/docs/api/x.md\" but not \"/docs/apiv2\". Must be absolute (server OS style); a relative prefix matches nothing. A prefix outside every base directory yields an empty files list, so compare it against the baseDirs in the response before concluding no files exist. Scope filters files by their scan path; ingest_data sources, which have no base-directory path, are always listed."sync_startsync_statusv0.16.1list_files1 field changedInput schema / properties / scopeAdded value: +{
+ "description": "Optional absolute path prefix(es) — one string or a list (unioned) — restricting the listing to files reachable at a path equal to or under a prefix within the base directories. \"/docs/api\" matches \"/docs/api/x.md\" but not \"/docs/apiv2\". Must be absolute (server OS style); a relative prefix matches nothing. Scope filters files by their scan path; ingest_data sources, which have no base-directory path, are always listed.",
+ "oneOf": [
+ {
+ "type": "string"
+ },
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ ]
+}v0.15.3ingest_data1 field changedInput schema / properties / metadata / properties / format / descriptionPrevious value: -"Content format: \"text\", \"html\", or \"markdown\""New value: +"Content format: text (plain/copied text), html (fetched web pages), or markdown."ingest_file2 fields changedInput schema / properties / visual / descriptionPrevious value: -"If true and the file is a PDF, run VLM captioning on figure pages. No effect on non-PDF files."New value: +"Run VLM captioning on figure pages (PDF only; default false)."Input schema / properties / visualQuality / descriptionPrevious value: -"VLM profile to use when visual is true. \"fast\" (default) is the lightweight SmolVLM-256M; \"quality\" is Qwen2.5-VL-3B-Instruct-ONNX with higher fidelity on figures with in-image text (~10x model-cache footprint, ~2x per-page inference). The server also accepts an empty string as a synonym for omitted (normalized to \"fast\"). Silently ignored when visual is false."New value: +"VLM profile when visual is true (default \"fast\"). \"quality\" is more accurate on figures with in-image text but much heavier and slower. Ignored when visual is false."query_documents3 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of results to return (default: 10, range: 1-20). Recommended: 5 for precision, 10 for balance, 20 for broad exploration."New value: +"Max results (default 10, range 1-20). Lower favors precision, higher recall."Input schema / properties / query / descriptionPrevious value: -"Search query. Include specific terms and add context if needed."New value: +"Search query. Preserve specific user terms (for keyword match); add context when the query is vague (for semantic match)."Input schema / properties / scopeAdded value: +{
+ "description": "Optional absolute path prefix(es) — one string or a list (unioned) — restricting results to a filePath equal to or under a prefix. \"/docs/api\" matches \"/docs/api/auth.md\" but not \"/docs/apiv2\". Must be absolute (server OS style); a relative prefix matches nothing — derive one from a filePath returned by an earlier query, or omit scope.",
+ "oneOf": [
+ {
+ "type": "string"
+ },
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ ]
+}read_chunk_neighbors2 fields changedInput schema / properties / filePath / descriptionPrevious value: -"Absolute path to the file (for documents ingested via ingest_file). Example: \"/Users/user/documents/manual.pdf\". Provide either filePath or source, not both."New value: +"Absolute path to the file (for ingest_file documents). Provide exactly one of filePath or source. Example: \"/Users/user/documents/manual.pdf\"."Input schema / properties / source / descriptionPrevious value: -"Source identifier used in ingest_data (for data ingested via ingest_data). Examples: \"https://example.com/page\", \"clipboard://2024-12-30\". Provide either filePath or source, not both."New value: +"Source identifier (for ingest_data documents). Provide exactly one of filePath or source. Examples: \"https://example.com/page\", \"clipboard://2024-12-30\"."v0.15.0query_documents3 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of results to return (default: 10). Recommended: 5 for precision, 10 for balance, 20 for broad exploration."New value: +"Maximum number of results to return (default: 10, range: 1-20). Recommended: 5 for precision, 10 for balance, 20 for broad exploration."Input schema / properties / limit / maximumAdded value: +20Input schema / properties / limit / minimumAdded value: +1v0.14.1ingest_file1 field changedInput schema / properties / visualQualityAdded value: +{
+ "default": "fast",
+ "description": "VLM profile to use when visual is true. \"fast\" (default) is the lightweight SmolVLM-256M; \"quality\" is Qwen2.5-VL-3B-Instruct-ONNX with higher fidelity on figures with in-image text (~10x model-cache footprint, ~2x per-page inference). The server also accepts an empty string as a synonym for omitted (normalized to \"fast\"). Silently ignored when visual is false.",
+ "enum": [
+ "fast",
+ "quality"
+ ],
+ "type": "string"
+}v0.14.0ingest_file1 field changedInput schema / properties / visualAdded value: +{
+ "description": "If true and the file is a PDF, run VLM captioning on figure pages. No effect on non-PDF files.",
+ "type": "boolean"
+}v0.13.0read_chunk_neighborsv1.0.0delete_fileingest_dataquery_documents2 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of results to return (default: 5, max recommended: 20)"New value: +"Maximum number of results to return (default: 10). Recommended: 5 for precision, 10 for balance, 20 for broad exploration."Input schema / properties / query / descriptionPrevious value: -"Natural language search query (e.g., \"transformer architecture\", \"API documentation\")"New value: +"Search query. Include specific terms and add context if needed."ingest_filelist_filesquery_documentsstatusEach tool has a distinct purpose: sync_status tracks job progress while status reports index stats; ingest_file vs ingest_data clearly separate file-based and in-memory ingestion; query_documents, read_chunk_neighbors, delete_file, list_files, and sync_start all target different operations. No two tools are likely to be confused.
Most tools follow a verb_noun pattern (query_documents, ingest_file, delete_file, list_files, read_chunk_neighbors), but sync_status, sync_start, and status deviate, using noun compounds or a standalone noun. The mix is readable but not uniform.
9 tools is well-scoped for a local RAG server, covering ingestion (file and data), deletion, querying, context expansion, file listing, and status/sync operations without unnecessary redundancy or bloat.
The set covers the core lifecycle: ingest (file/data), delete, search, and context retrieval. Minor gaps include no direct way to fetch all chunks of a specific document or a bulk clear operation, but these can be worked around with existing tools like query_documents and sync_start.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ingest, manage, and retrieve documents for RAG-powered AI applications
Versioned documentation registry and semantic search for AI tools and coding assistants.
Self-hosted AI-native knowledge workspace with hybrid search, GraphRAG, and MCP.
Search everything you save: YouTube, articles, podcasts, PDFs, Notion, Obsidian. API key or OAuth.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/shinpr/mcp-local-rag'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
