Uses Ollama to generate text embeddings for semantic search and retrieval of stored passages.
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-local What is Singapore?"
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.
This MCP server provides a simple API for storing and retrieving text passages based on their semantic meaning, not just keywords. It uses Ollama for generating text embeddings and ChromaDB for vector storage and similarity search. You can "memorize" any text and later retrieve the most relevant stored texts for a given query.
You can simply ask the LLM to memorize a text for you in natural language:
User: Memorize this text: "Singapore is an island country in Southeast Asia."
LLM: Text memorized successfully.
You can also ask the LLM to memorize several texts at once:
User: Memorize these texts:
Singapore is an island country in Southeast Asia.
It is about one degree of latitude north of the equator.
It is a major financial and shipping hub.
LLM: All texts memorized successfully.
This will store all provided texts for later semantic retrieval.
You can also ask the LLM to memorize the contents of a PDF file via memorize_pdf_file. The MCP tool will read up to 20 pages at a time from the PDF, return the extracted text, and have the LLM chunk it into meaningful segments. The LLM then uses the memorize_multiple_texts tool to store these chunks.
This process is repeated: the MCP tool continues to read the next 20 pages, the LLM chunks and memorizes them, and so on, until the entire PDF is processed and memorized.
User:
Memorize this PDF file: C:\path\to\document.pdf
LLM: Reads the first 20 pages, chunks the text, stores the chunks, and continues with the next 20 pages until the whole document is memorized.
You can also specify a starting page if you want to begin from a specific page:
MCP to LLM:
Memorize this PDF file starting from page 40: C:\path\to\document.pdf
LLM: Reads pages 40–59, chunks and stores the text, then continues with the next set of pages until the end of the document.
If you have a long text, you can ask the LLM to help you split it into short, meaningful chunks and store them. For example:
User: Please chunk the following long text and memorize all the chunks.
{large body of text}
LLM:
Splits the text into short, relevant segments and calls memorize_multiple_texts to store them. If the text is too long to store in one go, the LLM will continue chunking and storing until the entire text is memorized.
User: Are all the text chunks stored?
LLM: Checks and, if not all are stored, continues until the process is complete.
This conversational approach ensures that even very large texts are fully chunked and memorized, with the LLM handling the process interactively.
To recall information, just ask the LLM a question:
User: What is Singapore?
LLM: Returns the most relevant stored texts along with a human-readable description of their relevance.
Related MCP server: Qdrant MCP Server
First, clone this git repository and change into the cloned directory:
git clone <repository-url>
cd mcp-rag-localInstall uv (a fast Python package manager):
curl -LsSf https://astral.sh/uv/install.sh | shIf you are on Windows, install uv using PowerShell:
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"Run the following command to start ChromaDB and Ollama using Docker Compose:
docker-compose upAfter the containers are running, pull the embedding model for Ollama:
docker exec -it ollama ollama pull all-minilm:l6-v2Add the following to your MCP server configuration:
"mcp-rag-local": {
"command": "uv",
"args": [
"--directory",
"path\\to\\mcp-rag-local",
"run",
"main.py"
],
"env": {
"CHROMADB_PORT": "8321",
"OLLAMA_PORT": "11434"
}
}A web-based GUI for ChromaDB(Memory Server's db) is included for easy inspection and management of stored memory.
The admin UI is available at: http://localhost:8322
You can use this interface to browse, search, and manage the vector database contents.
Greet the user with their name and the server's name.
Returns:
str: A greeting message.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose side effects, permissions, or that it is a read-only, safe operation. It only specifies return type.
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?
Only two sentences with no redundancy, but lacks important details that could fit concisely.
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?
No output schema or annotations. The description does not explain how the user's name is resolved, leaving significant ambiguity for a tool with no input parameters.
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?
There are zero parameters, but the description implies there should be parameters for user and server name, which is misleading. Schema coverage is 100% but description adds confusion.
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 states it greets the user with their name and the server's name, but does not explain how it obtains the user's name since there are no input parameters.
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 guidance on when to use this tool versus sibling tools, which are all about memorization. The context of greeting is different but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Memorize multiple texts for later retrieval based on relevance in meaning, not just keywords.
Args:
texts (list): A list of texts to memorize.
Returns:
str: A message indicating success or failure of the operation.
| Name | Required | Description | Default |
|---|---|---|---|
| texts | Yes | ||
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that retrieval is based on relevance in meaning, not keywords, but omits side effects, authorization, or limitations (e.g., max texts). The return value is described only as a success/failure message, lacking detail on behavior.
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 highly concise: two sentences of purpose followed by structured Args/Returns. Every sentence is essential and front-loaded.
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 tool's complexity (2 params, nested metadata, no output schema), the description is insufficient. It omits metadata details and how this differs from memorize_text. More context like storage size limits or relation to sibling tools would improve completeness.
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 coverage is 0%, so the description must compensate. It explains the 'texts' parameter as a list, but ignores the 'metadata' parameter entirely. The description adds partial meaning for one of two parameters.
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's purpose: memorize multiple texts for later retrieval based on relevance in meaning, not keywords. It uses a specific verb-resource pair and distinguishes from siblings like memorize_text (single text) and remember_similar_texts (retrieval).
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 guidance is given on when to use this tool versus alternatives like memorize_text or remember_similar_texts. The description does not mention when not to use it or provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Chunk the contents of a PDF file into meaningful segments and store them in memory for later retrieval based on relevance in meaning, not just keywords.
Args:
ctx (Context): The context of the request.
file_path (str): The path to the PDF file.
page (int, optional): The starting page number to read from the PDF file. Defaults to 0.
metadata (dict, optional): Metadata to associate with the memorized content.
Returns:
str: A message indicating success or failure of the operation.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| metadata | No | ||
| file_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explains the chunking and storage action, the return value (success/failure), and mentions 'meaningful segments' but lacks details on side effects (e.g., overwriting, memory limits) or required permissions.
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 fairly concise with a one-line summary and a docstring. The Args section repeats schema info but is well-structured. Could be slightly more compact.
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 lack of output schema and annotations, the description covers basic purpose and parameters but omits details on chunking algorithm, error handling, and memory storage behavior. Sibling tool differentiation is absent.
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?
The description adds meaning to all three parameters: clarifies 'page' is starting page (default 0) and 'metadata' is for association. However, it does not mention the default value for metadata ({'topic': 'memory'}) or further specify its structure.
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 action ('Chunk... and store in memory'), the resource ('PDF file'), and the purpose ('based on relevance in meaning, not just keywords'), distinguishing it from simple keyword-based retrieval.
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?
The description hints at semantic memory use but does not explicitly compare to sibling tools like 'memorize_text' or 'remember_similar_texts', nor does it state when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Memorize a text for later retrieval based on relevance in meaning, not just keywords.
Args:
text (str): The text to memorize.
Returns:
str: A message indicating success or failure of the operation.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It indicates the tool memorizes text and returns a success/failure message, but omits details on persistence, side effects (e.g., storage location, data retention), and behavior with metadata. This is insufficient for a mutation-like tool.
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 very concise at two sentences plus args/returns, with no fluff. However, the conciseness comes at the cost of completeness; it could be slightly expanded to improve clarity without adding unnecessary length.
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?
The tool has 2 parameters, no output schema, and low complexity, but the description still falls short. It lacks usage context, error conditions, and differentiation from sibling tools. The return value is vaguely described as 'success or failure' without specifics, leaving gaps for an agent to use correctly.
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%, so the description must compensate. It merely restates that 'text' is the text to memorize, adding no semantic detail. The optional 'metadata' parameter is not described at all, leaving its purpose and format unexplained. The description adds negligible value beyond the schema.
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 verb 'memorize' and the resource 'text', and adds a distinguishing feature: retrieval is based on relevance in meaning, not just keywords. However, it does not explicitly differentiate from sibling tools like memorize_multiple_texts or remember_similar_texts, leaving some ambiguity.
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?
The description provides no guidance on when to use this tool versus alternatives such as memorize_multiple_texts or remember_similar_texts. It lacks explicit when-to-use or when-not-to-use instructions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query memory for texts similar in meaning to the query text.
Args:
query_text (str): The text to find similar meanings for.
n_results (int): The number of results to return. This is recommended to be more than 10.
Returns:
str: A human-readable string with the results and their relevance.
| Name | Required | Description | Default |
|---|---|---|---|
| n_results | No | ||
| query_text | Yes |
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 discloses that results are a human-readable string with relevance, and recommends n_results > 10. It does not mention side effects, authorization, or rate limits, but for a read-only operation this is acceptable.
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 concise, using a standard docstring format with Args and Returns. It is short (4 lines) and front-loaded with the core purpose. Minor waste: the Args/Returns structure could be more compact but is acceptable.
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 tool's simplicity and lack of output schema, the description covers the basics: purpose, parameters, and return type. It contextualizes the tool among siblings (retrieval vs. memorization). Missing details include search scope and performance considerations, but overall sufficient.
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%, so the description must compensate. It provides basic descriptions for both parameters (query_text and n_results) and adds a noteworthy recommendation for n_results. However, it does not explain how similarity is determined or the meaning of relevance scores, leaving gaps.
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's purpose: to query memory for texts similar in meaning to a given query. It uses a specific verb ('query memory') and distinguishes itself from sibling tools like 'memorize_text' which add content rather than retrieve.
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?
The description implies usage context (retrieving from memory) and contrasts with siblings that are for memorization. However, it lacks explicit when-to-use or when-not-to-use guidance, such as alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: greeting, memorizing text, memorizing multiple texts, memorizing PDF files, and retrieving similar texts. No ambiguity between tools.
All tool names follow a consistent snake_case pattern with verb_noun or verb_adjective_noun structure (e.g., greet_user, memorize_text, remember_similar_texts).
5 tools is appropriately scoped for a simple RAG local server, covering core operations without being overwhelming. Slightly on the low side but reasonable.
The tool set provides storage and retrieval but lacks update, delete, or listing operations, which are common in memory systems. This could limit agent capabilities.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Memory system for AI agents with semantic search. Store and recall memories with ease.
Long-term memory for AI assistants. Hybrid retrieval, query expansion, auto-topics.
Persistent memory for AI agents. Search, store, and recall across sessions.
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/renl/mcp-rag-local'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
