Which integrations are available for this server?

Allows using a local Ollama daemon as the embedding backend for document retrieval, enabling offline vector embeddings. Allows using an OpenAI-compatible API (e.g., SiliconFlow) as the embedding backend for document retrieval, leveraging cloud-based embeddings.

How do I use rag-retriever-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rag-retriever-mcp search my indexed documents for references to machine learning" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

rag-retriever-mcp

by code-lawyer

Overview Schema Related Servers Score Discussions

Python

Local

rag-retriever

A lightweight, local-first document retrieval engine that mounts to an agent as an MCP tool. Drop files in; the agent searches them and answers with its own LLM. There is no LLM in here — this is only the "front half" of RAG (extract → chunk → embed → store + similarity search).

your agent (owns the LLM)
   │  calls MCP tool: search("question")
   ▼
rag-retriever ──► extract ─► chunk ─► embed ─► LanceDB
   ▲                                              │
   └────────── returns relevant passages ◄────────┘
   │
   agent reads passages → answers with its own LLM

Built from the same proven pieces as Open Notebook (file extraction + bge-m3 embeddings + vector search), minus the heavyweight backend, UI, and answer/podcast generation you don't need.

Why this shape

One LLM, not two. The retriever never answers; your agent does. You keep full control of reasoning, prompts, and cost.
Local-first. Default backend (fastembed) runs entirely offline, no server.
Pluggable embeddings. Switch between fully local and a China-friendly cloud API (SiliconFlow) with one env var — no code change.

Related MCP server: RecallForge

Install

cd rag-retriever
uv sync
cp .env.example .env   # then pick your embedding backend

Configure the embedding backend (`.env`)

`RAG_EMBED_BACKEND`	What it uses	Notes
`local` (default)	fastembed (ONNX, in-process)	100% offline, no server, heavier first install
`ollama`	local Ollama daemon	`ollama serve` + `ollama pull bge-m3`
`openai`	OpenAI-compatible API (e.g. SiliconFlow)	needs `RAG_OPENAI_API_KEY`; text leaves the machine

⚠️ Index-time and query-time must use the same backend + model. Changing the model means re-indexing everything.

Use (CLI, for testing)

uv run rag-retriever index "C:\path\to\docs"     # a file or a whole folder
uv run rag-retriever search "什么是表见代理" -k 5
uv run rag-retriever list
uv run rag-retriever stats

Mount as an MCP server (the real entry point)

Run uv run rag-retriever-mcp (stdio). Register it with your MCP client. For Claude Code, add to your MCP config:

{
  "mcpServers": {
    "rag-retriever": {
      "command": "uv",
      "args": ["run", "--directory", "D:\\Vibe Coding Items\\rag-retriever", "rag-retriever-mcp"]
    }
  }
}

Tools exposed: index_path, search, list_sources, stats.

Supported files

pdf, docx, pptx, xlsx, html, md, txt, csv, json, epub (via markitdown). Scanned / image-only PDFs need an OCR engine (tesseract) installed separately; without it they extract empty and are reported as skipped.

Layout

rag_retriever/
  config.py     # env-driven config; picks the embedding backend
  extract.py    # file -> text (markitdown)
  chunk.py      # token-based chunking with overlap
  embed.py      # local | ollama | openai-compatible backends
  store.py      # LanceDB vector store (embedded, no server)
  pipeline.py   # ingest + search orchestration (no LLM)
  server.py     # MCP server (agent-facing)
  cli.py        # manual CLI

Available Tools

4 tools

index_pathA

Index a file or a whole folder of documents (pdf, docx, pptx, xlsx, html, md, txt...). Extracts text, chunks it, embeds it, and stores vectors for later search. Returns a summary of how many files/chunks were indexed and what was skipped.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`recursive`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavioral traits. It describes the indexing process and return value, but does not mention that this is a write operation that may be resource-intensive, require authentication, or have potential side effects like modifying the vector store. The description is incomplete for behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the action and supported types, followed by the process and return summary. Every sentence is informative and there is no extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, and the description adequately explains the return value (summary of indexed/skipped counts). However, it lacks details on error handling, permission requirements, or performance implications for large directories. Given the tool's simplicity and the presence of output schema, the description is reasonably complete but could be enhanced.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description has 0% schema coverage, meaning it does not explicitly name or explain the parameters 'path' or 'recursive'. It vaguely implies path via 'file or folder', but does not clarify the default recursive behavior or how to control it. The description adds minimal semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Index' and the resource 'a file or a whole folder of documents'. It lists supported file types (pdf, docx, etc.) and explains the process (extracts text, chunks, embeds, stores vectors). This effectively distinguishes it from sibling tools like 'search' (which queries indexed data) and 'list_sources' (which lists sources).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies that this tool is used to add documents to the index before searching, but it does not explicitly state when to use it versus alternatives, nor does it mention prerequisites or limitations. No guidance is given on when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_sourcesB

List the documents currently indexed and how many chunks each has.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It only states the tool lists documents and chunks, without mentioning side effects, authentication needs, rate limits, or whether it's read-only. Minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single concise sentence that front-loads the purpose. No unnecessary words, every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and an output schema exists, the description is mostly complete. It could mention scope (e.g., all indexed documents) or output sorting, but the basic functionality is clear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist in the schema, so baseline 4 applies. The description adds no parameter info, but with zero parameters, it is adequate. Schema coverage is trivially 100%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists documents and their chunk counts, distinguishing it from siblings like index_path, search, and stats. The verb 'List' and resource 'documents currently indexed' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like stats or search. The description does not mention any context, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

searchA

Search the indexed documents for passages relevant to query and return the top k chunks (with source path and similarity score). Use these passages as grounding to answer the user's question yourself — this tool does NOT answer.

ParametersJSON Schema

Name	Required	Description	Default
`k`	No
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description fully compensates by disclosing that results are chunks with scores and that the tool itself does not answer. No contradictions present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first for function and output, second for usage advice. No redundancy, front-loaded with essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 params, no annotations), the description covers purpose, output, and usage pattern thoroughly. No missing critical details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description explains both parameters: 'query' as the search term and 'k' as the top number of chunks with a default of 5. Could add constraints like allowed range for k, but sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Search' and the resource 'indexed documents', listing the returned fields (source path, similarity score). It distinguishes from sibling tools like index_path and list_sources by focusing on retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs to use the passages as grounding and warns that the tool does not answer, guiding the agent on proper usage. However, it lacks contrasting with alternatives for when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

statsA

Show retriever status: embedding backend/model, storage location, and counts.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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 implies a read-only operation via 'Show,' but does not explicitly guarantee no side effects or mention any behavioral traits like speed or auth requirements. Adequate for a simple status tool but could be more explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence of nine words, front-loaded with the action and resource. No wasted words; every part adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and an output schema exists (not shown but referenced), the description is complete enough. It lists the key output elements and is sufficient for this simple status tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema description coverage is 100% trivially. The description does not need to add parameter semantics, so baseline 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool shows retriever status and lists specific components (embedding backend/model, storage location, counts). It is a specific verb+resource and clearly distinguishes from siblings like search or list_sources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., search, list_sources). The description only states what it does without context on prerequisites or exclusion criteria.

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. Dates show when Glama detected each change.

4 tool updatesv0.1.0Jul 30, 2026
- First observedindex_path
- First observedlist_sources
- First observedsearch
- First observedstats

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool has a distinct purpose: indexing files, searching passages, listing indexed sources, and showing system stats—no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., index_path, list_sources) with clear, predictable naming.

Tool Count5/5

With only 4 tools, the set is well-scoped for a document retrieval MCP, covering core operations without unnecessary bloat.

Completeness4/5

The set covers key operations (index, search, list, stats) but lacks a tool to delete indexed documents, which is a minor but notable gap.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

saagarpatel.dev Portfolio A
io.github.saagpatel
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Search Documentation Access
82
Dewey
com.meetdewey
Agentic search over your Dewey document collections from any MCP-compatible client.
Search Knowledge & Memory RAG Systems
2
Frenchie A
io.github.Lab94
OCR, transcription, file extraction, and image generation for AI agents via MCP.
AI & Machine Learning Image & Video Processing Speech Processing
72
qsearch A
io.github.theYahia
Multi-engine search for AI agents. Trust scoring, local corpus, MCP-native. Self-hostable, BYOK.
Search RAG Systems
22

Related MCP Servers

ragi
RAG Systems Search
SusuTawar
A
license
A
quality
D
maintenance
Local-first RAG indexing and semantic search MCP server. Enables document retrieval and context-aware queries using local embedding models.
Updated 24 days ago (2026-08-13 16:07 UTC)
3
16
MIT
RecallForge
RAG Systems Search
brianmeyer
A
license
Not graded
quality
D
maintenance
Local-first MCP server enabling cross-modal search across text, images, documents, video, and audio transcripts. Provides 26 tools for ingesting, searching, and navigating local file systems with a 3-stage pipeline including reranking.
Updated 4 months ago (2026-05-17 20:50 UTC)
3
MIT
devitway-rag-starterofficial
RAG Systems Search
devitway
F
license
Not graded
quality
C
maintenance
Minimal local RAG stack with an MCP server that provides document search for any agent.
Updated 2 months ago (2026-07-04 18:39 UTC)
1
-
io.github.Brightdotdev/darwinofficial
RAG Systems Knowledge & Memory Search
Brightdotdev
A
license
Not graded
quality
A
maintenance
A local-first RAG engine that ingests documents (PDF, Markdown, images, etc.) and provides hybrid search, reranking, and LLM answer synthesis via MCP for AI agent integration.
Updated 10 days ago (2026-08-26 21:52 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/code-lawyer/rag-retriever'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

rag-retriever

Why this shape

Install

Configure the embedding backend (.env)

Use (CLI, for testing)

Mount as an MCP server (the real entry point)

Supported files

Layout

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

ragi

RecallForge

devitway-rag-starterofficial

io.github.Brightdotdev/darwinofficial

Latest Blog Posts

MCP directory API

Configure the embedding backend (`.env`)