MCP RAG Agent
Provides integration with AWS Bedrock for using foundation models like Claude and Titan for chat and embeddings.
Enables local LLM inference and embeddings using Ollama's models for retrieval and generation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@MCP RAG AgentExplain how RAG pipeline works with MCP"
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.
MCP RAG Agent
A local-first AI backend that combines Model Context Protocol, Retrieval-Augmented Generation, and an agent runtime to answer questions from a private knowledge base.
The project runs an MCP server that exposes retrieval tools. A client-side agent connects to that server, lets the LLM decide when to call tools, retrieves relevant knowledge chunks, and returns grounded answers with source citations.
Features
MCP server exposing retrieval tools
CLI agent client
Interactive chat mode
RAG pipeline over a local knowledge base
ChromaDB vector store
Pluggable LLM providers (Ollama, AWS Bedrock)
Pluggable embedding providers (Ollama, AWS Bedrock)
Optional reranking pipeline
Source-grounded answers with citations
Modular service layout for retrieval, embeddings, chunking, vector stores, and rerankers
Related MCP server: suasor
Example Usage
Ask a single question:
uv run python -m client.src.main "Explain how MCP tools work with RAG"Start interactive mode:
uv run python -m client.src.main --interactiveExample interactive session:
MCP RAG Agent
Type a question and press Enter.
Type 'exit' or 'quit' to stop.
You: Explain how MCP tools work with RAG
Assistant:
MCP tools allow the agent to access external capabilities, such as document retrieval, through a standard protocol...
Sources:
- knowledge/mcp.md#3
- knowledge/rag.md#1Architecture
flowchart TD
User[User] --> Agent[LangGraph Agent]
Agent --> Runtime[Agent Runtime]
Runtime --> LLM["LLM Provider<br/>(Ollama / Bedrock)"]
Runtime --> MCPClient[MCP Client]
MCPClient --> MCPServer[MCP Server]
MCPServer --> RetrievalTool["retrieve_documents()"]
MCPServer --> OtherTools["Other MCP Tools"]
RetrievalTool --> Embed["Embedding Provider<br/>(Ollama / Bedrock)"]
Embed --> VectorStore[ChromaDB Vector Store]
VectorStore --> Reranker[Reranker]
Reranker --> Context[Context Builder]
Context --> RetrievalTool
RetrievalTool --> MCPServer
MCPServer --> MCPClient
Runtime --> Answer[Grounded Answer with Citations]How It Works
The user asks a question through the CLI.
The client starts and connects to the MCP server.
The agent discovers available MCP tools.
The LLM decides whether it needs to call a retrieval tool.
The MCP server runs the RAG pipeline:
embeds the query
searches ChromaDB
optionally reranks retrieved chunks
builds a context payload
returns source metadata
The agent generates a final answer using the retrieved context.
The final response includes citations such as:
[knowledge/mcp.md#2]Project Structure
client/
└── src/
├── main.py # CLI entry point
├── agent_runtime.py # Agent loop and tool-calling runtime
├── mcp_client.py # MCP client wrapper
├── tool_executor.py # Executes MCP tools
├── tool_mapper.py # Converts MCP tools to Ollama tool schema
└── llm/ # LLM provider implementations
├── base.py
├── ollama.py
└── bedrock.py
server/
└── src/
├── server.py # MCP server entry point
└── tools/ # MCP tool registrations
services/
├── rag/
├── chunking/ # Text chunking strategies
├── dto/ # API response DTOs
├── embedding/ # Embedding providers
| ├── base.py
| ├── ollama_provider.py
| └── bedrock_provider.py
├── loaders/ # Document loaders
├── mappers/ # Domain-to-response mappers
├── models/ # RAG domain models
├── pipelines/ # Indexing and retrieval pipelines
├── rerankers/ # Reranking implementations
└── vectorstores/ # Vector store adapters
knowledge/ # Local knowledge base documents
scripts/ # Utility scripts
chroma_db/ # Local ChromaDB dataRequirements
Required
Python 3.13+
uv
Optional
Ollama (for local inference)
AWS credentials with Bedrock access (for Bedrock providers)
Example:
ollama pull llama3.1If your embedding provider uses a separate embedding model, pull that model too.
Setup
Install dependencies:
uv syncStart Ollama:
ollama serveRun a question:
uv run python -m client.src.main "Explain how MCP tools work with RAG"Run interactive chat:
uv run python -m client.src.main --interactiveCLI Options
uv run python -m client.src.main --helpAvailable options:
question Optional question to ask the agent
-i, --interactive Start an interactive chat session
--model Ollama chat model to use
--max-steps Maximum number of tool-calling stepsExamples:
uv run python -m client.src.main "What is AWS Bedrock?" --model llama3.1uv run python -m client.src.main --interactive --max-steps 8Source Citations
The retrieval tool returns source metadata for every retrieved chunk:
{
"context": "...",
"sources": [
{
"document_id": "knowledge/mcp.md",
"chunk_index": 2
}
]
}The agent is instructed to cite retrieved sources in the final answer using this format:
[document_id#chunk_index]Example:
MCP lets an agent call external tools through a standard protocol, which makes the RAG system easier to separate from the LLM runtime [knowledge/mcp.md#2].
Sources:
- knowledge/mcp.md#2
- knowledge/rag.md#4Why MCP + RAG?
Traditional RAG systems often tightly couple the agent, retriever, vector store, and application logic. MCP creates a cleaner boundary:
The agent does not need to know how retrieval is implemented.
Retrieval can be exposed as a reusable tool.
Other MCP-compatible clients can use the same backend.
The server can add more tools without rewriting the agent runtime.
Current Retrieval Tool
The MCP server exposes:
retrieve_documents(query: str, top_k: int = 20, top_n: int = 5)It returns:
retrieved context
document IDs
chunk indexes
vector similarity scores
rerank scores when available
Retrieval Evaluation
Run retrieval evaluation:
uv run python -m scripts.evaluate_retrievalRun with custom retrieval settings:
uv run python -m scripts.evaluate_retrieval --top-k 8 --top-n 4Write detailed results to JSON:
uv run python -m scripts.evaluate_retrieval --json-output scripts/eval/results/latest.jsonWeb API and Browser Demo
Install API dependencies:
uv add fastapi uvicornRun the FastAPI server:
uv run uvicorn api.main:app --reloadOpen the browser UI:
[http://localhost:8000](http://localhost:8000)Open the interactive API docs:
[http://localhost:8000/docs](http://localhost:8000/docs)API Endpoints
Health check:
curl [http://localhost:8000/health](http://localhost:8000/health)Non-streaming chat:
curl -X POST [http://localhost:8000/chat](http://localhost:8000/chat)
-H "Content-Type: application/json"
-d '{"message": "Explain how MCP tools work with RAG"}'Streaming chat:
curl -N -X POST [http://localhost:8000/chat/stream](http://localhost:8000/chat/stream)
-H "Content-Type: application/json"
-d '{"message": "Explain how MCP tools work with RAG"}'Direct retrieval:
curl -X POST [http://localhost:8000/retrieve](http://localhost:8000/retrieve)
-H "Content-Type: application/json"
-d '{"query": "What is Model Context Protocol?", "top_k": 8, "top_n": 4}'List available MCP tools:
curl [http://localhost:8000/tools](http://localhost:8000/tools)The browser UI uses the streaming endpoint so the answer appears token-by-token while the final response is generated.
Configuration
Chat generation and embeddings are configured independently, allowing combinations such as Bedrock + Ollama or Ollama + Bedrock.
Create a local .env file from the example:
cp .env.example .envUse Ollama for chat and embeddings
CLIENT_LLM_PROVIDER=ollama OLLAMA_CHAT_MODEL=llama3.1 RAG_EMBEDDING_PROVIDER=ollama OLLAMA_EMBEDDING_MODEL=nomic-embed-textUse Bedrock for chat and Ollama for embeddings
CLIENT_LLM_PROVIDER=bedrock BEDROCK_CHAT_MODEL=anthropic.claude-3-5-sonnet-20240620-v1:0 AWS_REGION=us-east-1
RAG_EMBEDDING_PROVIDER=ollama OLLAMA_EMBEDDING_MODEL=nomic-embed-textUse Bedrock for chat and embeddings
CLIENT_LLM_PROVIDER=bedrock BEDROCK_CHAT_MODEL=anthropic.claude-3-5-sonnet-20240620-v1:0
RAG_EMBEDDING_PROVIDER=bedrock BEDROCK_EMBEDDING_MODEL=amazon.titan-embed-text-v2:0
AWS_REGION=us-east-1If you switch embedding providers, rebuild or re-index the vector database because vectors from different embedding models are not compatible.
Architecture Decisions
MCP defines the boundary between the agent runtime and backend capabilities.
LangGraph orchestrates workflows but does not implement retrieval logic.
Retrieval is exposed as an MCP tool, allowing any MCP-compatible client to reuse the backend.
LLM providers are swappable through a common interface (Ollama or AWS Bedrock).
Embedding providers are independent of the chat model.
Vector stores are abstracted behind a common interface (ChromaDB by default).
Retrieval results are exposed as DTOs to avoid leaking internal domain models through the MCP API.
Portfolio Highlights
This project demonstrates:
MCP tool design
RAG architecture
Provider abstraction (Ollama / Bedrock)
vector search
source-grounded generation
agent tool-calling loops
modular backend design
Python async programming
clean CLI UX
Future Improvements
Planned improvements:
Docker Compose setup
streaming responses
structured logging
query rewriting
hybrid keyword/vector retrieval
automated tests
CI workflow
Available Tools
1 toolretrieve_documentsC
Retrieve relevant knowledge chunks.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No | ||
| top_n | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits (e.g., read-only, authentication). Minimal information leaves the agent with little understanding of side effects or requirements.
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 extremely short (one sentence). While concise, it lacks structure and fails to provide any details, making it under-specifying rather than efficiently concise.
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 the presence of three parameters and no output schema or annotations, the description is incomplete. It does not explain return values, parameter details, or overall behavior, leaving significant gaps.
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 0%, and the description adds no meaning to the parameters 'query', 'top_k', or 'top_n'. The parameter names are self-explanatory, but the description does not clarify their semantics or usage.
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 retrieves knowledge chunks, which is a specific verb and resource. No sibling tools exist, so no differentiation is needed. However, it could be more descriptive (e.g., 'from a knowledge base').
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 explicit guidelines on when to use the tool. The purpose is implied by the name and description, but no alternatives or context are provided.
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 tool update
v0.1.0- First observed
retrieve_documents
TDQS
With only one tool, there is no possibility of confusion between tools.
The single tool name 'retrieve_documents' follows a clear verb_noun pattern and is descriptive, but there is no set of tools to evaluate consistency.
A RAG agent typically requires multiple tools (e.g., retrieval and generation). A single tool is too few for the stated purpose.
The tool set covers only retrieval, missing essential capabilities like generation or query processing for a RAG agent.
Maintenance
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
Self-hosted AI-native knowledge workspace with hybrid search, GraphRAG, and MCP.
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
- KumbukaOAuthai.kumbuka
Governed, auditable knowledge your team curates for its AI assistants, self-hostable
Your company's brain for AI agents. Cited, permission-aware knowledge across every system.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceA Docker-based local RAG backend that provides advanced document search capabilities using vector, graph, and full-text retrieval via the Model Context Protocol. It supports over 28 file formats and tracks evolving relationships between concepts using a Neo4j-backed graphiti implementation.1MIT
- AlicenseNot gradedqualityAmaintenanceA local-first AI secretary that gathers your work context into private memory and enables AI agents to search and summarize it over MCP.38MIT
- FlicenseNot gradedqualityDmaintenanceA local RAG server using the Model Context Protocol (MCP) to allow AI assistants to query private documents with persistent memory and support for many file formats.1-
- AlicenseNot gradedqualityAmaintenanceA 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.1MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/elandy/mcp-ai-backend'
If you have feedback or need assistance with the MCP directory API, please join our Discord server