Skip to main content
Glama
Saikiran2412

RAG MCP Server

by Saikiran2412
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

RAG MCP Server

A standalone Model Context Protocol (MCP) server that exposes semantic document retrieval — over a ChromaDB collection of arXiv research papers — as a callable tool for any MCP-compatible client (Claude Desktop, custom agents, etc.).

This project decouples the retrieval layer from the Agentic Corrective RAG System (a separate project), so the same indexed knowledge base can be queried by any LLM client without needing to know about ChromaDB, embeddings, or the underlying pipeline.

MCP Client (Claude Desktop / any MCP-compatible agent)
        │   MCP protocol (stdio)
        ▼
RAG MCP Server (this project)
        │
        ▼
retrieve_documents(query, top_k)
        │
        ▼
ChromaDB collection "research_papers"
(allenai-specter embeddings, dense retrieval)

Why this exists

Most RAG systems bury retrieval inside a single monolithic pipeline — the vector store is only reachable by running the whole application end to end. This project takes just the retrieval component and puts a standard interface in front of it, so:

  • Any MCP client can query the knowledge base directly, without touching LangGraph, Groq, or any generation/correction logic

  • The vector store becomes reusable infrastructure instead of an implementation detail locked inside one app

  • Swapping the underlying vector DB (ChromaDB → Qdrant → Pinecone) would require no changes to any client, only to this server

Related MCP server: mcp-ai-workspace

What it exposes

retrieve_documents(query: str, top_k: int = 5)

Performs dense semantic search over a corpus of arXiv research papers and returns structured, typed results — not a raw text blob.

Returns: a list of RetrievedChunk objects:

Field

Type

Description

content

str

The retrieved chunk text

title

str

Title of the source paper

source

str

Source PDF filename

page

int

Page number within the source document

arxiv_id

str

arXiv identifier / URL for the paper

score

float

Similarity distance score (lower = closer match)

Example call (via an MCP client):

"Use retrieve_documents to find information about attention mechanisms in transformers"

Example structured output:

[
  {
    "content": "Quantifying attention flow in transformers...",
    "title": "Beyond the Leaderboard: Design Lessons for Trustworthy Multimodal VQA",
    "source": "2607.15241v1.pdf",
    "page": 6,
    "arxiv_id": "https://arxiv.org/abs/2607.15241v1",
    "score": 0.42
  }
]

Architecture notes

  • Embeddings: sentence-transformers/allenai-specter, run locally — no API key or embedding cost.

  • Vector store: ChromaDB, loaded read-only from a pre-built persisted collection (research_papers). This server never re-indexes or re-embeds documents — it only queries an existing index built by the source RAG pipeline.

  • Transport: stdio, following the standard local MCP server pattern used by Claude Desktop.

  • Server framework: FastMCP, Anthropic's Python SDK for MCP servers.

Setup

1. Install dependencies

uv add mcp langchain-huggingface langchain-chroma sentence-transformers

2. Provide the vector store

This server expects a pre-built, persisted ChromaDB collection at ./data/chroma_db with collection name research_papers. If you're using this against your own document set, build that collection first using your own ingestion pipeline, or point CHROMA_PERSIST_DIR in vectorstore.py at your existing persisted collection.

3. Run the server directly (sanity check)

uv run python server.py

No output is expected — the server sits idle over stdio waiting for a client to connect. This is normal.

4. Connect to Claude Desktop

Add the server to your claude_desktop_config.json:

{
  "mcpServers": {
    "rag-retrieval-server": {
      "command": "C:\\path\\to\\uv.exe",
      "args": [
        "--directory",
        "C:\\path\\to\\rag-mcp-server",
        "run",
        "python",
        "server.py"
      ]
    }
  }
}

Fully quit and restart Claude Desktop, then check "+" → Connectors in the chat box to confirm rag-retrieval-server is listed with the retrieve_documents tool.

Project structure

rag-mcp-server/
├── server.py          # MCP server + tool definitions
├── vectorstore.py      # Loads the existing Chroma collection (read-only)
├── data/
│   └── chroma_db/      # Persisted ChromaDB collection (copied from source project)
└── README.md

Relationship to the Corrective RAG project

This server reuses the exact same indexed document collection as the Agentic Corrective RAG System — same embeddings, same ChromaDB store — but strips away the LangGraph orchestration, relevance grading, web-search fallback, and Groq-based generation. It exposes only the retrieval primitive, as a standalone, protocol-compliant service.

Possible extensions

  • retrieve_by_paper(arxiv_id, query) — scoped search within a single paper

  • list_indexed_papers() — enumerate all papers currently in the collection

  • HTTP/SSE transport, so the server is reachable over a network instead of only local stdio

Available Tools

1 tool
retrieve_documentsA

Retrieve relevant research paper chunks for a query using semantic search over a corpus of arXiv papers.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
top_kNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'semantic search' which implies relevance-based retrieval, but does not disclose what the output contains (e.g., chunk text, metadata, scores), whether results are sorted, or any limits. For a read operation, it is missing details that would help an agent predict behavior.

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, concise sentence that front-loads the verb and purpose. Every word contributes value, with no filler or redundancy. It is appropriately sized for a simple retrieval tool.

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

Completeness3/5

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

The tool is simple with two parameters and an output schema, but the description is minimal. It covers the main function but omits any explanation of parameters (especially top_k) and does not mention behavioral nuances like ordering or return format, which are not fully covered by the schema either. It is adequate but leaves gaps.

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?

Schema description coverage is 0%, so the description must explain the parameters. The description implies the 'query' parameter (as it retrieves 'for a query'), but it does not mention 'top_k' at all, nor does it explain how top_k affects the results. Given only two parameters, this is a notable gap.

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 a specific verb ('Retrieve'), a specific resource ('research paper chunks'), and the method ('semantic search over a corpus of arXiv papers'). It is unambiguous and distinguishes the tool from any potential alternative, though no siblings are listed. This is a strong, specific statement of purpose.

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 provides clear context: it is used for semantic search over arXiv papers, which implies when it is appropriate (when dealing with arXiv content). However, it does not explicitly state when not to use it or mention alternatives, but since no siblings exist, this is acceptable. The 'arXiv papers' qualifier serves as a usage guideline.

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.

  1. 1 tool updatev0.1.0
    • First observedretrieve_documents
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Only one tool exists, so there is no possibility of confusion between tools. The single tool's purpose is clear and distinct by default.

Naming Consistency5/5

With only one tool, naming is trivially consistent. 'retrieve_documents' follows a clear verb_noun pattern and is appropriately descriptive.

Tool Count2/5

A single tool is too few for a server advertised as a RAG server. RAG typically requires document ingestion, indexing, and management in addition to retrieval, so the tool count is inadequate for the apparent scope.

Completeness1/5

The tool surface is severely incomplete for a RAG workflow. There is no way to add, update, or delete documents in the corpus, nor any indexing or management operations, leaving only retrieval with no supporting lifecycle.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/Saikiran2412/Retrieval_MCP'

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