Loading ToolBench
Model Context Protocol Server for RAG Access to project documentation and code using semantic search
DAUT RAG MCP server exhibits fundamental definition quality gaps. Three tools are present and registered with the FastMCP framework, each with basic descriptions and minimal parameter documentation. However, the definitions lack the structured rigor required for reliable agent interaction. All tool descriptions fall within acceptable length (100-200 chars), but parameter-level documentation is sparse or absent. Output schemas are not explicitly documented, tools return unstructured strings rather than structured JSON objects. Error handling is minimal (basic 'not found' messages with no recovery guidance). The server implements basic RAG functionality but does not follow production-grade tool patterns for LLM interaction. Transport is HTTP (FastMCP), which is current, but the tool definitions themselves would require significant refinement before deployment to production agents.
List all available documentation files in the project.
Semantically search the project documentation and code using the RAG system.
Read the full content of a specific documentation file.
All three tools return unstructured strings instead of structured JSON objects with typed fields. LLMs cannot reliably parse string output to extract IDs, references, or metadata needed for downstream tool calls.
Output schemas are not documented. The code shows tools returning formatted strings, but there is no formal JSON Schema definition in the tool registration or docstring explaining the structure of responses to the LLM.
read_documentation_file accepts file_path as a free-form string with no path traversal protection or format constraints. An LLM could be tricked into passing '../../../etc/passwd' or other malicious paths. Input validation is absent.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 55 | - | v1 |
No pagination support. list_documentation_files returns all files as a single unstructured string with no limit, offset, or count. If the documentation set grows large, this tool will return unbounded output and exhaust token budget.
Error handling provides minimal recovery guidance. Errors are bare strings ('No relevant results found', 'File not found') without actionable next steps or context about what the LLM should try next.
query_rag parameter n_results has no documented min/max bounds. LLMs could pass 0, -1, or 10000 without validation. Numeric parameters require explicit range constraints.
read_documentation_file description includes an example path ('docs/my_doc.md'). Per the rubric, examples in descriptions encourage LLMs to reuse them literally rather than adapt to context. Use formal constraints (regex, enum) instead.