retrieval-mcp
Related Servers
Alternatives to retrieval-mcp
No user-submitted related servers found.
Related Servers
- AlicenseAqualityCmaintenanceEnables MCP clients to search and retrieve approved, role-filtered internal knowledge with PII redaction, citations, content-integrity checks, and tamper-evident audit logging.3MIT
- AlicenseNot gradedqualityBmaintenanceEnables MCP clients to search technical document collections using hybrid BM25 and embedding retrieval, returning cited page-level passages to support grounded, evidence-based answers.MIT
- AlicenseNot gradedqualityCmaintenanceEnables MCP clients to ask questions over the indexed document corpus and search handbook passages, returning cited answers and ranked results.MIT
- AlicenseNot gradedqualityDmaintenanceProvides hybrid retrieval (dense + BM25 + RRF) with collection-based isolation and document ingestion for private knowledge access via MCP.MIT
- AlicenseNot gradedqualityBmaintenanceEnables MCP clients to connect document sources, prepare searchable documents, and run RAG-ready lexical, vector, or hybrid search with account-scoped document access.40 PyPIBSD 3-Clause
- AlicenseAqualityCmaintenanceEnables MCP-compatible clients to search SignalRank with dense, BM25, or hybrid retrieval and receive ranked evidence with provenance.1MIT
TDQS
Scored across 3 tools
Each tool occupies a distinct stage of the retrieval workflow: list_sources for discovery, search for candidate chunks, fetch for full context. The descriptions explicitly state 'when to use' and 'when not to use' for every tool, including the boundary case of 'search is enough to confirm existence, use fetch for content'. No two tools can be reasonably confused.
All three names are lowercase snake_case verbs, which is readable and conventional. Minor deviation: list_sources follows verb_noun while search and fetch are bare verbs, but they are standard terms for this domain and no mixing of styles (camelCase, capitalization) occurs.
Three tools is exactly right for a read-only retrieval server: one for capability/filter discovery, one for search, one for expansion. Each tool has a clear, non-redundant role and nothing feels padded or missing at the surface level.
The read-only lifecycle (discover sources → search → fetch full text by doc_id or window) is fully closed, with guidance on empty results and truncation. A minor gap remains: there is no way to browse or enumerate documents within a source, so an agent cannot list what exists without first searching.