Local RAG System for Claude Code — Hybrid search + Cross-encoder Reranking + 13 MCP Tools + 20 Format Parsers. Zero external servers.
The server has 13 tools with generally good naming and descriptions, but inconsistent schema documentation and missing parameter descriptions for some tools. Most tool names follow verb_noun patterns (search, add_document, update_document, remove_document, list_documents, get_document). Descriptions are present for all tools and mostly in the 50-200 character range, meeting basic standards. However, several tools lack complete parameter documentation in the visible source, and output schemas are not formally documented. The schema for 'search' tool is well-structured with all parameters described, but tools like 'add_document', 'update_document', and 'remove_document' show parameter schemas in the JSON input specs but lack validation/constraint details in the descriptions themselves. Error handling and recovery guidance are not evident in the tool descriptions.
Add a document to the knowledge base. Supports markdown, PDF, DOCX, XLSX, PPTX, TXT, JSON, YAML, HTML. Markdown is split by ## sections.
Fetch content from a URL and add it to the knowledge base as a document. Supports plain text, HTML, and PDFs.
Clear the query result cache.
Return statistics about the query cache (hit rate, size, TTL).
Retrieve the full content of a document by filename.
Return knowledge base statistics: document count, total chunks, embedding model info, index sizes.
Check the health of the knowledge base system (embeddings model, reranker, vector store, BM25 index).
Output schemas not documented. Tools return results but no formal schema is specified for what fields/structure the LLM should expect. This forces LLMs to guess at response structure and plan downstream calls blindly.
Missing constraint documentation in parameter descriptions. Parameters like 'max_results' (integer), 'hybrid_alpha' (0-1 range), and 'search_method' (enum) lack explicit constraint descriptions. The rubric requires: 'Specify minimum and maximum for numeric parameters' and 'declare as enum when accepting one of known set of values'.
Destructive operations (remove_document) lack confirmation/dry-run pattern. No evidence of user confirmation step or dry-run capability for irreversible actions. The rubric states: 'Irreversible operations should support a dry-run or confirmation step.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Watch a directory and auto-index documents as they are added or modified. Supports all supported formats.
List all documents in the knowledge base with metadata (filename, category, chunk count, date added).
Rebuild the vector index and BM25 index from all documents. Clears cache. Use after bulk document updates.
Remove a document from the knowledge base by filename.
Hybrid search (semantic + BM25 keyword) with RRF fusion and cross-encoder reranking for precision. Supports category filtering and caching.
Update an existing document by filename. Replaces the content, re-chunks, and reindexes.
No error recovery guidance in tool descriptions. Descriptions do not explain what to do if a call fails (e.g., 'If file not found, try list_documents()'). The rubric requires: 'Error responses must tell the LLM what to do next'.
Pagination not implemented for list_documents and search results. No limit/offset/cursor parameters documented. For large knowledge bases, returning unbounded results blows context window. Rubric states: 'Tools returning lists should accept page/offset and limit parameters and return a total count'.
reindex and clear_cache tools have minimal descriptions (70 chars) and no guidance on when to call them or what they do exactly. The rubric requires descriptions 'state WHAT the tool does, WHEN to use it, and any prerequisites'.