Skip to main content
Glama
roilanrodriguez55

mcp-local-rag

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
DB_PATHNoVector database location./lancedb/
BASE_DIRNoOne document root; the CLI flag is repeatable on `ingest`, `list`, and `sync`Current directory
BASE_DIRSNoJSON array of document roots; takes precedence over `BASE_DIR`
CACHE_DIRNoModel cache directory./models/
RAG_DTYPENoEmbedding dtype passed to the selected modelfp32
MODEL_NAMENoHugging Face embedding modelXenova/all-MiniLM-L6-v2
RAG_DEVICENoONNX Runtime execution devicecpu
HF_ENDPOINTNoHugging Face model download endpoint; use a mirror URL when direct downloads are blockedhttps://huggingface.co
RAG_GROUPINGNo`similar` keeps the first relevance group; `related` keeps up to two, using significant vector-distance gaps as boundaries.
STORE_IMAGESNoMCP server only: store supported PDF/DOCX images and return them with matched chunks. CLI uses `--images`.false
MAX_FILE_SIZENoMaximum file size in bytes104857600
RAG_MAX_FILESNoLimit results to top N files (e.g., `1` for single best file).
RAG_RERANK_CMDNoMCP server only: external command template that reorders results. Matched text is sent on stdin; `{query}` passes the query.
CHUNK_MIN_LENGTHNoMinimum length in characters (1–10000) for ordinary chunks; a fragment of content split to fit the model's token limit can be shorter50
RAG_MAX_DISTANCENoFilter out low-relevance results (e.g., `0.5`).
RAG_HYBRID_WEIGHTNoKeyword boost factor (0.0–1.0). 0 disables keyword reranking; 1 applies the maximum boost.0.6
RAG_RERANK_TIMEOUT_MSNoTime budget per rerank call in milliseconds (100–600000).10000

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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
query_documentsA

Search ingested documents with hybrid keyword + semantic matching. Use the returned order as the ranking; score may disagree with it. Each has filePath, chunkIndex, text, fileTitle, score (lower is closer), 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. Each changed PDF is re-ingested with the visual profile ("fast" or "quality") already recorded for it, so a PDF indexed with VLM captions keeps them; a PDF with no recorded profile stays text-only. There is no option to change a profile here — use the CLI (mcp-local-rag sync --visual) to set one, or ingest_file to replace the file, where a normal ingest clears the recorded profile. Stored images are unrelated: STORE_IMAGES applies to whatever this run re-ingests and never makes a file changed. 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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 9 tools

Disambiguation5/5

Each tool has a distinct purpose: ingest_file vs ingest_data are cleanly split by path vs in-memory string, delete_file consolidates deletion for both, query_documents is search, read_chunk_neighbors is follow-up context, and sync_start/sync_status form a clear job/poll pair. list_files and status both give overviews but their descriptions clearly separate file scanning from index metrics.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (query_documents, ingest_file, ingest_data, delete_file, list_files, read_chunk_neighbors, sync_start, sync_status). The lone 'status' noun breaks the pattern, and sync_ prefix is a minor variant, but overall it reads predictably.

Tool Count5/5

Nine tools is well-scoped for a local RAG server, with each tool earning its place across search, ingest, delete, listing, status, context retrieval, and sync operations. No redundancy or bloat.

Completeness4/5

The surface covers the RAG lifecycle well: create/update via ingest and re-ingest, read via query and chunk neighbors, delete, list, status, and disk reconciliation via sync. Minor gaps exist (no explicit whole-index reset or single-document metadata fetch), but agents can work around them via delete_file and query_documents.

Maintenance

ActivityActive
ResponsivenessNo issues