TinyRAG
Provides optional semantic retrieval through an OpenAI-compatible Embedding API for vector-based similarity search.
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., "@TinyRAGwhat does the knowledge base contain about RAG?"
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.
TinyRAG
Your agent already has an LLM. TinyRAG gives it a private knowledge base through MCP.
No Docker. No vector database. No mandatory API key. Add your .txt documents to data/raw/; TinyRAG automatically chunks and indexes them, then exposes the relevant source text to your agent through MCP.
Zero RAG configuration: the defaults work out of the box, with optional semantic retrieval when you need it.
You do not need to install or configure anything yourself. Give this repository to an agent with terminal access, and it can set up TinyRAG for you.
Give this repository to your agent and tell it:
Install TinyRAG, add my text documents, run its evaluation, and configure it as a local stdio MCP server. Do not commit secrets or private documents.
Repository: https://github.com/spacecat398/TinyRAG-MCP
你的 Agent 已经拥有 LLM,TinyRAG 通过 MCP 为它提供一个私有知识库。
无需 Docker,无需向量数据库,也不强制要求 API Key。把 .txt 文档放入 data/raw/,TinyRAG 会自动切块并建立索引,再通过 MCP 把相关原文提供给你的 Agent。
RAG 零配置:默认设置开箱即用,需要时再开启语义检索。
你不需要亲自安装或配置任何东西。把这个仓库交给拥有终端权限的 Agent,它会替你完成 TinyRAG 的安装和接入。
把这个仓库地址发给你的 Agent,并告诉它:
安装 TinyRAG,添加我的文本文档,运行项目评估,并将它配置为本地 stdio MCP 服务器。不要提交密钥或私人文档。
仓库地址:https://github.com/spacecat398/TinyRAG-MCP
Agent Instructions
This section is written for AI agents that install, configure, or operate TinyRAG.
Objective
Install TinyRAG as a local MCP server and expose the user's UTF-8 .txt documents as searchable knowledge. Prefer the smallest working configuration. Do not add Docker, a vector database, or an LLM dependency unless the user explicitly requests one.
Requirements
Python 3.12 or newer
uvpreferred;pipis supportedGit
A host that can launch local stdio MCP servers
Install
git clone https://github.com/spacecat398/TinyRAG-MCP.git
cd TinyRAG-MCP
uv sync
uv run python -m unittest discover -s tests -v
uv run python scripts/eval.pyExpected test result: all unit tests pass. Expected evaluation result: 3 passed, 0 failed.
If uv is unavailable:
python -m venv .venv
python -m pip install -r requirements.txt
python -m unittest discover -s tests -v
python scripts/eval.pyActivate .venv first when required by the operating system.
Add Knowledge
Put UTF-8
.txtfiles indata/raw/.Run a query or restart the MCP server.
TinyRAG automatically rebuilds
data/processed/when source file names, modification times, or chunk settings change.
Do not commit private documents unless the user explicitly approves it. The included sample documents may be removed.
Configure MCP
Use the following local stdio server definition. Replace cwd with the absolute repository path on the current machine.
{
"mcpServers": {
"tinyrag": {
"command": "uv",
"args": ["run", "python", "rag_app/mcp_server.py"],
"cwd": "/absolute/path/to/TinyRAG-MCP"
}
}
}Windows paths may use forward slashes, for example C:/Users/name/TinyRAG-MCP.
Configuration file names and locations vary by MCP host. Adapt the object to the host's schema without changing the command, arguments, or working directory. TinyRAG uses stdio; do not configure it as an HTTP server.
Available Tools
Tool | Purpose |
| Retrieve relevant context and return a lightweight grounded answer or excerpt |
| Return source chunks for the calling agent to reason over |
| List indexed source documents |
For agentic workflows, prefer search_relevant_chunks when the calling agent should produce the final answer itself.
Retrieval Modes
TinyRAG works without an API key:
Default: local keyword retrieval
Optional: semantic retrieval through an OpenAI-compatible Embedding API
Fallback: keyword retrieval when the Embedding API is unavailable
To enable semantic retrieval, create .env from .env.example:
TINYRAG_ENABLE_REMOTE_EMBEDDINGS=true
OPENAI_API_KEY=
OPENAI_BASE_URL=https://api.openai.com/v1
EMBEDDING_MODEL=text-embedding-3-smallNever commit .env. Remote embeddings stay disabled unless TINYRAG_ENABLE_REMOTE_EMBEDDINGS=true is set explicitly. When enabled, document chunks and queries are sent to the configured API endpoint. Inform the user before enabling a remote endpoint for private data.
Direct Query
uv run python scripts/query.py "What does the knowledge base say about RAG?"Interactive mode:
uv run python scripts/query.pyOperational Constraints
Supported source format:
.txtonlyTransport: local MCP stdio only
Generation: lightweight rule/excerpt generation, not a general-purpose LLM
Storage: JSON cache under
data/processed/Default chunk size: 500 characters
Default overlap: 80 characters
Default retrieval count: 3 chunks
The calling agent is expected to handle general reasoning and answer generation. TinyRAG focuses on loading, caching, and retrieving local context.
Safety Rules
Never expose or commit
.env.Never commit
.venv/ordata/processed/.Treat files in
data/raw/as potentially private.Do not silently enable a remote Embedding API.
Do not delete user documents when rebuilding the cache.
Keep paths relative to the repository except for the MCP host's required absolute
cwd.
Important Files
rag_app/mcp_server.py MCP stdio entry point
rag_app/pipeline.py retrieval pipeline
rag_app/retriever.py keyword and embedding retrieval
rag_app/cache.py automatic local cache
data/raw/ user source documents
data/processed/ generated cache, ignored by Git
scripts/eval.py smoke evaluation
scripts/query.py command-line query tool
.env.example optional embedding configuration
CHANGELOG.md release notes and upgrade changes
LICENSE MIT license termsCompletion Check
Before reporting installation complete, verify all of the following:
uv run python -m unittest discover -s tests -vanduv run python scripts/eval.pypass.data/raw/contains the intended documents.The MCP configuration uses an absolute and existing
cwd.The MCP host can see
query_knowledge_base,search_relevant_chunks, andlist_documents.No secret or private generated file is staged in Git.
Available Tools
3 toolslist_documentsA
列出知识库中的所有文档。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 only says 'lists all documents' without mentioning whether the operation is read-only, paginated, ordered, or what metadata is returned. This is minimal behavioral context.
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 a single, front-loaded sentence with no unnecessary words. It is maximally 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 simplicity of a zero-parameter list tool, the description is minimally adequate. However, it lacks any additional context such as ordering, scope, or performance implications. While an output schema exists, the description still feels sparse for a tool with no other documentation or annotations.
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 tool has zero parameters, and the schema coverage is 100% (vacuous). The baseline for zero parameters is 4, and the description correctly imposes no additional parameter requirements.
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 the tool lists all documents in the knowledge base, with a specific verb 'list' and resource 'documents'. It clearly distinguishes from sibling tools like query_knowledge_base and search_relevant_chunks, which focus on searching/querying rather than full listing.
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 use case is implied: listing all documents when a complete inventory is needed. However, there is no explicit guidance on when to prefer this over the sibling search tools, nor any mention of exclusion criteria or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_knowledge_baseA
从本地知识库中查找与问题最相关的内容并生成答案。
Args:
question: 用户问题,如"小明的宠物叫什么?"
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself must convey behavior. It explicitly describes the search-and-generate behavior, implying a read-only operation, but omits any details about response format, permissions, or side effects. For a simple query tool, this basic disclosure is minimally adequate.
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, with a front-loaded action sentence and a brief Args note. Every sentence offers useful information; the example contributes to parameter clarity without redundancy.
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 description covers the core purpose and parameter semantics, and an output schema exists. However, it does not provide explicit guidance on when to choose this tool over sibling tools, leaving a gap in the overall contextual picture.
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 input schema only provides a 'question' string with no description. The tool description adds meaning by explaining it is the user's question and gives a concrete example ('小明的宠物叫什么?'). This fully compensates for the 0% schema description coverage.
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 finds the most relevant content from a local knowledge base and generates an answer. This is a specific verb+resource+action, and it distinguishes from sibling tools like search_relevant_chunks (which likely just returns chunks without generation) and list_documents.
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 use for answering questions from a local knowledge base, but it does not explicitly contrast with search_relevant_chunks or list_documents. No when-to-use versus alternatives guidance is provided, leaving usage context somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_relevant_chunksA
搜索与问题最相关的知识片段(不经过生成器,返回原文)。
Args:
question: 搜索关键词
top_k: 返回片段数量(默认 3)
| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No | ||
| question | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It explicitly states that the tool bypasses the generator and returns original text, adding meaning beyond the name and schema. While it doesn't mention read-only guarantees or other effects, for a search tool this is sufficient.
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 concise: a single sentence plus a compact Args list. Every element earns its place with no redundant wording, and the key information is 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 simplicity (2 params, search-only) and the presence of an output schema, the description is complete: it covers purpose, parameter semantics, and the key behavioral trait (no generation, returns raw text). No critical information is missing.
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 schema has 0% description coverage, but the description compensates fully with an Args section explaining 'question' as the search keyword and 'top_k' as the number of chunks to return (default 3). This adds clear semantics beyond the schema's bare property titles.
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 uses a specific verb and resource: '搜索...知识片段' (search knowledge chunks) and clarifies that it returns original text without passing through a generator. This clearly distinguishes it from sibling tools like query_knowledge_base and list_documents.
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 parenthetical '不经过生成器,返回原文' provides clear context that this tool is for raw retrieval rather than generated answers, implying when to use it. However, it does not explicitly name alternative tools or state when not to use it, so it lacks a full exclusions statement.
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.
3 tool updates
v0.3.1- First observed
list_documents - First observed
query_knowledge_base - First observed
search_relevant_chunks
TDQS
query_knowledge_base and search_relevant_chunks both search the knowledge base for relevant content, differing only in whether the response is generated or raw chunks. An agent might select the wrong one if not attentive. list_documents is clearly distinct.
All tool names follow a consistent verb_noun pattern using snake_case: query_, list_, search_. The naming is predictable and clear.
Three tools is an appropriate size for a focused RAG server, covering retrieval and listing without unnecessary bulk.
The tools cover querying and listing but lack document management (add, update, delete). This is a notable gap for a knowledge base server, though the core retrieval workflow is present.
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
Make your knowledge agent-ready. One MCP endpoint, 5 connectors, 3 search modes.
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to search, deep-read, and build knowledge bases from Markdown, PDF, DOCX, and PPTX documents via MCP tools for retrieval, document navigation, and ingestion.50627MIT
- AlicenseNot gradedqualityBmaintenanceConverts unstructured documents into a searchable knowledge base and exposes retrieval tools via MCP protocol for AI agents to query.1MIT
- FlicenseAqualityBmaintenanceA local-first document retrieval engine that mounts as an MCP tool for agents to index files, search for relevant passages, and let the agent's own LLM answer.4-
- FlicenseNot gradedqualityCmaintenanceEnables users to build and query a private knowledge base by uploading documents, which are embedded and stored locally, then accessible via MCP for semantic search and retrieval.-
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/spacecat398/TinyRAG-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server