A RAG (Retrieval-Augmented Generation) server using geometric/vector search with hybrid two-tower architecture, ChromaDB for persistence, and re-ranking via cross-encoder models. Implements MCP protocol via JSON-RPC 2.0 HTTP endpoint.
Motor RAG Geométrico exposes 2 tools with basic HTTP transport via FastAPI/Uvicorn. Tool naming follows verb conventions ('retrievel_geometric_context', 'alimentar'), but descriptions are functional yet lack depth on selection criteria and downstream value. Input schemas are present and typed, but parameter descriptions are minimal. Output schemas are undocumented. Error handling and composition are not evident. The server's core RAG functionality is clear, but the tool interface does not meet production standards for agent guidance and LLM-driven tool selection.
Ingests/feeds a text document into the RAG collection with automatic UUID assignment and vector embedding.
Performs hybrid two-tower RAG retrieval: executes geometric/cosine-distance vector search on query against collection, re-ranks top-3 candidates using cross-encoder model, returns best result with geometric distance and re-ranking confidence score.
Tool name 'retrievel_geometric_context' contains a typo: 'retrievel' should be 'retrieve'. The naming convention starts with a verb, which is correct, but the misspelling will confuse both agents and users.
Tool name 'alimentar' is not in English and does not follow the verb_noun convention. LLMs trained primarily on English may not infer the action clearly. Rename to 'add_document' or 'ingest_document' for clarity across international agents.
Output schemas are not documented. The 'retrievel_geometric_context' tool description mentions it returns 'geometric distance and re-ranking confidence score', but the full structure (field names, types, presence of supporting metadata) is not specified. LLMs cannot plan downstream tool calls without knowing return structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Parameter descriptions are too brief. 'retrievel_geometric_context' accepts 'query' (string) with description 'The query text to retrieve relevant context for', lacks guidance on query format, expected length, language, and whether partial matches or exact phrases are supported. 'alimentar' accepts 'texto' with minimal description.
No error handling guidance. If 'retrievel_geometric_context' finds no matches, or if 'alimentar' fails to generate embeddings (e.g., due to invalid text or service overload), the tool responses do not indicate whether to retry, fall back, or ask the user for clarification.
No idempotency or confirmation for the 'alimentar' (write) tool. If ingestion partially fails or is retried, the system could add duplicate documents. No dry-run or confirmation step documented.
Tool composition is unclear. The 'retrievel_geometric_context' tool claims to return 'best result' with confidence, but the response format does not indicate whether it includes the document ID, source, or metadata needed for follow-up actions (e.g., cite the result, delete it, or update it). Broken tool chains.