Loading ToolBench
MCP-compatible vector database server exposing semantic search, document insertion/deletion, and RAG queries for AI agent integration
The Domicile MCP server defines 4 tools with reasonable structure and mostly clear descriptions. All tools have explicit input schemas with typed parameters and meaningful descriptions. Tool naming follows verb_noun conventions (search_vectors, insert_document, delete_document, rag_query). However, there are significant gaps in completeness: no documented output schemas are visible in the source, parameter relationships lack explicit documentation, error handling guidance is absent, and the implementation details suggest basic error responses without recovery hints. The filter parameter structure is underdocumented (nested object with field/operator/value but no clarity on how to construct valid filters). Overall, the definitions are better than typical STDIO-only servers but fall short of production-grade agent tool standards.
Delete a document from the vector database by its ID.
Insert a document with text content and optional metadata into the vector database. The text will be automatically embedded.
Execute a RAG (Retrieval-Augmented Generation) query. Retrieves relevant documents and generates an answer using a local LLM.
Search for similar vectors using a text query. Returns the most semantically similar documents from the vector database.
No documented output schemas for any tool. LLMs cannot predict what fields will be returned, forcing them to treat responses as opaque and unable to chain into downstream tools. Pattern pattern:tool and pattern:response-shaper require explicit response structure documentation.
Filter parameter structure is underdocumented. Schema shows nested object with 'field', 'operator', 'value' but does not enumerate valid field names, valid operators per field type, or provide examples. 'operator' enum lists 8 values (eq, ne, gt, gte, lt, lte, in, contains) but does not clarify which apply to which data types. LLMs cannot construct valid filters without explicit guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
delete_document lacks destructive-operation framing. Description does not mention irreversibility or recovery options. Per pattern:confirmation-request, destructive tools should support dry-run or require explicit confirmation. Current description (60 chars) is minimal and does not guide LLM on the risk or whether to ask the user first.
No error handling guidance. None of the tools include descriptions of what errors might occur (network failure, model not loaded, document not found, invalid filter, embedding timeout) or how to recover. Per pattern:recovery-guide, error responses must guide the LLM on next steps.
No idempotency guarantees documented. insert_document and delete_document do not state whether they are safe to retry. Per pattern:idempotent-operation, if an agent retries on ambiguous failure, non-idempotent tools risk duplicate documents or failed deletes that succeed on retry. Needs explicit guidance.
search_vectors response content unclear. Does 'Returns the most semantically similar documents' mean full text or summaries? Are similarity scores included? Are document IDs, metadata, and embeddings always returned or depends on includeVectors flag? Without documented response structure, agents cannot plan chains (e.g., get document ID from search result, then delete or update).
rag_query output schema missing. Does it return just the generated answer text, or also the source documents used? LLMs need to know if follow-up tools (e.g., cite sources, fact-check) can access retrieval details.
insert_document output schema missing. Does it return the new document ID, the full document object, or just a success boolean? Agents need the ID to reference the inserted document in downstream calls (search, delete, update).