Keepygaga RAG
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., "@Keepygaga RAGsearch my notes for why we chose LanceDB for vector storage"
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.
Keepygaga RAG
Keepygaga RAG is the independently runnable Knowledge/RAG subproject of Keepygaga. It indexes authorized local Markdown and plain-text sources, combines SQLite FTS5 and LanceDB vector recall with reciprocal-rank fusion, and applies online reranking while preserving traceable source coordinates.
Project status: personal software in active development (pre-alpha). This repository is published for early testing and collaboration. Interfaces, data formats, and behavior may change without notice. There is no support, uptime, or compatibility commitment, and issues or pull requests may be handled at the maintainer's discretion.
Its only public MCP tool is raw search. When the MCP host registration ID is
keepygaga_rag, the complete host tool name is mcp__keepygaga_rag__search. The MCP
Server display name is Keepygaga RAG.
Requirements
Python 3.12+
A local directory containing Markdown or plain-text material
Configured and user-authorized embedding and reranking APIs
uvis recommended
Related MCP server: search-docs
Install and use
git clone https://github.com/TimWongUp/keepygaga-rag.git
cd keepygaga-rag
uv sync --extra dashboard
cp keepygaga-rag.example.toml keepygaga-rag.toml
uv run keepygaga-rag doctor
uv run python mcp_server.py
uv run keepygaga-rag dashboard
uv run keepygaga-rag indexerThe Dashboard listens on 127.0.0.1:8765 by default. Runtime overrides use
KEEPYGAGA_RAG_CONFIG, KEEPYGAGA_RAG_DASHBOARD_PORT, and
KEEPYGAGA_RAG_DASHBOARD_AUTO_CLOSE.
Safety boundaries
Original files remain authoritative; indexes are rebuildable derived data.
agents-memory/**and_context-backups/**are always excluded at every depth.Indexed text is sent only to the authorized embedding provider. Query text and candidate chunks are sent only to the authorized reranker.
Provider, model, or source-scope changes require renewed user consent.
Hybrid results locate sources; read the returned source file before treating a match as authoritative.
For the exact local/external data boundary, credential handling, and provider responsibilities, see Privacy and data flow.
Contributing and security
Contributions are welcome within the project's pre-alpha scope. Before opening an issue or pull request, read Contributing.
Do not report vulnerabilities in a public issue. Follow the private reporting instructions in Security.
License
Available Tools
1 toolsearchARead-onlyIdempotent
Search ordinary local knowledge with hybrid FTS and vector recall, reciprocal rank fusion, and online reranking. Results are grouped by text table and include source paths, headings, chunk text, and scores.
This tool never searches core Agent memory or context-backup trees, even when either appears below a configured source root. Indexing text is sent to the configured Embedding provider; query text and candidate chunks are sent to the configured Reranker provider only for sources with current user consent.
Args: query: Natural-language or exact-text knowledge query. top_k: Results to return, from 1 through 20. table_ids: Optional text-table filters, at most 20. source_ids: Optional source filters, at most 20.
Results locate candidate source material. Read the returned source file before treating a match as authoritative.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language or exact-text knowledge query | |
| top_k | No | Maximum results to return | |
| table_ids | No | Optional retrieval-table filters | |
| source_ids | No | Optional source filters |
Output Schema
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| groups | Yes | |
| status | Yes | |
| warnings | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and idempotent, so the description correctly builds on that. It adds meaningful behavioral details: results are grouped by text table, network calls are made to Embedding and Reranker providers, and reranking happens only with user consent. This is valuable context beyond the structured annotations.
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 well-structured and front-loaded with purpose, followed by scope/exclusions, privacy details, argument summaries, and a verification caveat. It is somewhat long and the Args block partially duplicates the schema, but every section earns its place for a search tool with privacy and authority caveats.
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 is complete for a read-only search tool: it defines scope, results contents, privacy behavior, parameter constraints, and the need to verify matches against the source file. The presence of an output schema also covers return-value details, so no essential context 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?
Schema description coverage is 100%, so the schema already documents all parameters well. The description's Args section restates the schema (query, top_k range, table_ids, source_ids limits) rather than adding deeper semantic details, so a baseline of 3 is appropriate.
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 a specific verb ('Search'), a clear resource ('ordinary local knowledge'), and the retrieval mechanism (hybrid FTS and vector recall, RRF, reranking). It also explicitly distinguishes what this tool is not for by saying it never searches core Agent memory or context-backup trees.
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 gives clear scope: search ordinary local knowledge, not memory or backup trees. It also tells the agent that results are only candidate sources and that the returned source file should be read before treating a match as authoritative, which is a practical, actionable usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
With only one tool exposed, there is no possible overlap or misselection between tools. The single search operation is unambiguous.
The lone tool is named with a clear, lowercase verb ('search') that accurately describes its action. There are no other names to create mixed conventions or inconsistent patterns.
A single tool is borderline: acceptable for a retrieval-only endpoint, but thin for a server branded as a RAG system, which would typically benefit from source/table discovery or management tools.
The search tool itself is feature-rich with hybrid retrieval, reranking, and filters, but the surface is incomplete for a RAG lifecycle: agents cannot ingest, update, delete, or even enumerate available sources/tables without external knowledge.
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
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Search your knowledge bases from any AI assistant using hybrid RAG.
Securely search and manage workspace context files for AI agents and teams.
Self-hosted AI-native knowledge workspace with hybrid search, GraphRAG, and MCP.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables semantic search over local Markdown documentation using hybrid retrieval combining embeddings, keyword search, and graph traversal with automatic file watching and zero-configuration setup.2MIT
- AlicenseAqualityCmaintenanceEnables AI agents to search local Markdown documents using natural language, with automatic indexing and section-level retrieval.951MIT
- AlicenseNot gradedqualityBmaintenanceEnables Claude Code to search and retrieve from a local knowledge base of markdown notes using hybrid semantic+keyword search, keeping data entirely offline.9MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to search, read, and traverse a local knowledge base of Markdown files using full-text search and relationship graph, reducing token usage.MIT
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/TimWongUp/keepygaga-rag'
If you have feedback or need assistance with the MCP directory API, please join our Discord server