mcp-local-rag
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DB_PATH | No | Vector database location | ./lancedb/ |
| BASE_DIR | No | One document root; default is current directory | . |
| BASE_DIRS | No | JSON array of document roots; takes precedence over BASE_DIR | |
| CACHE_DIR | No | Model cache directory | ./models/ |
| RAG_DTYPE | No | Embedding dtype supplied by the selected model | fp32 |
| MODEL_NAME | No | Hugging Face embedding model | Xenova/all-MiniLM-L6-v2 |
| RAG_DEVICE | No | ONNX Runtime execution device | cpu |
| RAG_GROUPING | No | `similar` keeps the first relevance group; `related` keeps up to two, using significant vector-distance gaps as boundaries. | |
| MAX_FILE_SIZE | No | Maximum file size in bytes | 104857600 |
| RAG_MAX_FILES | No | Limit results to top N files (e.g., 1 for single best file). | |
| CHUNK_MIN_LENGTH | No | Minimum chunk length in characters (1–10000) | 50 |
| RAG_MAX_DISTANCE | No | Filter out low-relevance results (e.g., 0.5). | |
| RAG_HYBRID_WEIGHT | No | Keyword boost factor (0.0–1.0). 0 disables keyword reranking; 1 applies the maximum boost. | 0.6 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| query_documentsA | 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). |
| ingest_fileA | 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 }. |
| ingest_dataA | 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 }. |
| delete_fileA | 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). |
| list_filesA | 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.). |
| statusA | Get index status: { documentCount, chunkCount, memoryUsage (MB), uptime (s), ftsIndexEnabled, searchMode }. |
| read_chunk_neighborsA | 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). |
| sync_startA | 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. |
| sync_statusA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool has a clear, non-overlapping purpose: status, query, two ingestion methods differentiated by source type, delete, list, context reading, and sync start/status. Even the two ingest tools are unambiguous due to explicit input-type distinction.
Most tools follow a verb_noun snake_case pattern (query_documents, ingest_file, delete_file, list_files, read_chunk_neighbors, sync_start, sync_status). The lone 'status' tool deviates slightly by being a bare noun rather than a verb action, but the overall naming is predictable and consistent.
With 9 tools, the server is well-scoped for a local RAG system. Each tool serves a distinct and necessary function: ingestion (file and data), querying, context exploration, deletion, listing, status, and synchronization, with no unnecessary bloat.
The tool set covers the full lifecycle: ingestion (create), querying (read), deletion (delete), and updating via re-ingestion or synchronization. Additional utilities like status, list_files, and read_chunk_neighbors fill out the surface for effective RAG management, leaving no obvious gaps.