RAG-MCP
Related Servers
Alternatives to RAG-MCP
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityFmaintenanceLocal-first Markdown vault retrieval for agents. Read-only MCP stdio server exposing search, get, status, and doctor over Obsidian-compatible Markdown with hybrid BM25/vector/wikilink/title retrieval and first-class CJK support.37 PyPI11MIT
- AlicenseNot gradedqualityBmaintenanceTurns any folder of PDFs, markdown, and text files into a local, queryable knowledge base exposed as an MCP server. Enables MCP-compatible agents to semantically search indexed documents, retrieve relevant passages with source and relevance scores, list or reindex documents, and inspect cache and token usage — instead of reading whole files into context.1MIT
- AlicenseAqualityAmaintenanceLocal deterministic BM25 memory for AI agents — offline-first, no API key, SHA-256 content-addressed shards, stdio MCP transport. Same query always returns the same ranked result.1145 npmMIT
- AlicenseAqualityBmaintenanceEnables fast, low-token code search for AI coding agents via a local BM25 engine built on SQLite FTS5, with support for camelCase, snake_case, and Japanese text. Provides a stateless MCP stdio server and a Hermes adapter for multi-agent environments.1MIT
- FlicenseNot gradedqualityCmaintenanceA local BM25 knowledge retrieval MCP server that indexes configured files and directories for agents like Claude Code, Kiro CLI, and Codex, providing interpretable search and chunk retrieval tools.-
- AlicenseNot gradedqualityAmaintenanceTurns a local folder of documents into a queryable index that an LLM agent can pull from on demand, keeping only a compact table of contents in context. Exposes five tools (index, search, read, grep, neighbours) over a single offline SQLite FTS5 store so the model retrieves exact, citable sections instead of being handed whole files.MIT
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose: search returns ranked passages, get_chunk retrieves a specific chunk, get_document retrieves a full document, and list_documents provides an overview. There is no overlap or ambiguity between them.
All tool names follow the same verb_noun pattern with lowercase and underscores: search_documents, get_chunk, get_document, list_documents. The convention is perfectly consistent.
Four tools form a tight, well-scoped set for a RAG server. Each tool earns its place by covering the essential retrieval workflow without redundancy or bloat.
The tool surface covers the full retrieval lifecycle: discover what's indexed (list_documents), search the corpus (search_documents), read a specific passage (get_chunk), and read the full source (get_document). No obvious gaps exist for the stated purpose.