A Rust-based MCP gateway that bridges OpenAI API with multiple MCP servers (docs knowledge base and Oracle database), providing tool routing, hybrid search, and SQL query execution.
Three tools with clear verb-noun naming (docs_list_sources, docs_search, docs_get_chunk) and reasonable descriptions (50-100 chars). All tools have input schemas with type definitions and parameter descriptions. However, output schemas are not documented in the visible code, parameter descriptions lack detail about format/constraints, and no error handling guidance is provided. Tools follow single-responsibility principle but lack pagination guidance for list_sources despite accepting a limit parameter.
Return full chunk text by chunk_id.
List indexed sources (files) so the agent can know what information is available.
Search across local docs and return top-k chunks with citations (hybrid: vector + SQLite FTS5).
Output schemas not documented. LLMs cannot plan downstream tool calls or extract structured data without knowing what fields to expect from docs_list_sources, docs_search, and docs_get_chunk.
Parameter descriptions lack actionable constraints. 'query' in docs_search has no length limits, format hints, or examples. 'chunk_id' in docs_get_chunk provides no guidance on format or how to obtain valid IDs.
No error handling guidance. Tools provide no recovery hints for common failures (query too broad, chunk_id not found, search timeout). LLMs cannot self-correct without explicit error messages.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | <=2025-11-25 | v2 |
docs_list_sources accepts limit parameter but no pagination guidance. Description does not explain whether results are sorted, how to iterate beyond limit, or what total count means.
docs_search description mentions 'hybrid: vector + SQLite FTS5' but does not explain when to use this tool vs docs_list_sources, or what 'top_k' ranking means to the LLM.