Local Markdown RAG system MCP with semantic search capabilities
This MCP server has significant gaps in definition quality. Of 5 tools, only 1 (index) has a complete, visible input schema in the source code. The other 4 tools have minimal or no schema documentation visible. Descriptions vary widely: 'index' has a detailed 161-char description, but 'search' has only 74 chars and 'status'/'config'/'generate_docs' have descriptions under 40 chars. No tool input schemas are visible for search, status, config, or generate_docs, only index has an explicit schema shown. Parameter descriptions are completely absent from visible tool definitions. No error handling guidance is documented. Tool naming is reasonable (all verb-first) but parameter and output documentation is nearly absent across the codebase provided.
Manage and view configuration settings
Generate documentation from markdown files
Index markdown files in a directory. Processes markdown documents and creates searchable vector embeddings. Supports YAML frontmatter extraction and incremental indexing.
Search markdown files using semantic search with natural language queries
Check system status and configuration
4 of 5 tools lack visible input schemas. Only 'index' has documented input parameters (index_dir, recursive, force, watch, output_format). Tools 'search', 'status', 'config', 'generate_docs' have no schema visible in the provided code.
Descriptions too brief for 3 tools: 'status' (20 chars), 'config' (27 chars), and 'generate_docs' (40 chars) fall below the 50-char floor for LLM reasoning. These provide no context for when or why to invoke them.
No parameter descriptions are visible for any tool. The 'index' tool shows parameter names and types but lacks descriptions explaining what each parameter controls. LLMs cannot infer intent from name alone.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 35 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Output schemas not documented. No tool describes what fields it returns or what structure agents should expect. This forces LLMs to guess downstream parameter types for chained calls.
No error handling guidance. Tools do not document recovery paths (e.g., 'If indexing fails, check directory permissions'). Agents receive no actionable next steps on failures.
Tool 'status' is vague. Does it check MCP server health, vector database connectivity, or configuration validity? The 20-char description provides no context.
Tool 'config' description is generic ('Manage and view configuration settings'). Does it read config, update it, validate it, or list options? Ambiguity will cause wrong tool selection.
'search' tool description (74 chars) omits key details: What is the output format? Does it return snippets or full documents? What metadata is included? Agents cannot plan downstream usage.