Loading ToolBench
MCP server for managing vector databases and embeddings with support for multiple vector database backends (Weaviate, Milvus, Pinecone, Qdrant, MongoDB, Neo4j, Elasticsearch, OpenSearch, Supabase)
The server defines 18 tools for vector database operations with explicit JSON Schema inputs and descriptions. Tool naming follows verb_noun convention consistently (list_, create_, delete_, get_, query_, show_, count_). However, several critical gaps reduce the score: (1) No output schemas are documented anywhere in the provided code, the rubric requires documentation of return types for A-grade work (baseline: 100% of A+ tools have documented return types). (2) Parameter descriptions are present but often generic or incomplete, e.g., 'embedding_model' description references a list operation but doesn't explain the consequence of choosing different models. (3) No parameter validation rules, ranges, or format constraints are specified in descriptions (e.g., collection name length limits, valid characters). (4) Four destructive tools (delete_collection, delete_document, delete_all_documents, delete_document_by_name) lack confirmation/dry-run patterns. (5) The 'metadata' parameter in create_document defaults to {} but lacks a schema for what metadata keys/values are acceptable. (6) Tool descriptions average ~80-120 chars, which is below the baseline of 194 chars for A+ tools, many are terse. (7) Error handling is not documented in any tool description, violating the 'error responses must tell the LLM what to do next' pattern. Individual tool scores range from 55-72.
Count the total number of collections in the database
Count documents in a collection
Create a new collection in the vector database with optional embedding model selection
Create a new document in a collection
Delete all documents from a collection or all collections
Delete a collection from the vector database
No output/return schemas documented for any tool. The rubric requires 100% of A+ tools to have documented return types. Agents cannot plan downstream tool calls without knowing what fields to expect in responses.
Four destructive tools (delete_collection, delete_document, delete_all_documents, delete_document_by_name) lack confirmation/dry-run patterns. Agents make mistakes, irreversible operations should support a dry-run or explicit confirmation step.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Delete a document from a collection
Delete a document by filename instead of ID
Get statistics for a collection including document count and schema info
Get a specific document by ID
Check the health and connectivity of the vector database
List all collections in the vector database
List documents in a collection
List all available embedding models and their properties
Query documents using semantic search
Show detailed information about a collection including schema, count, and properties
Show embedding configuration for a specific collection
Show a document by filename instead of ID
Parameter descriptions lack validation rules, format constraints, and ranges. E.g., 'limit' parameter has no max bound; 'name' parameter has no length constraint; 'embedding_model' lacks explanation of consequences. Rubric requires: 'Specify minimum and maximum for numeric parameters... Unbounded numbers let LLMs pass absurd values.'
No error handling guidance in tool descriptions. Rubric requires: 'Error responses must tell the LLM what to do next.' No tool documents what errors can occur, how to recover, or which operations are retryable.
Tool descriptions are below production baseline (avg 194 chars for A+ tools). Most descriptions are 30-80 chars, providing minimal context for LLM selection. E.g., 'health_check': 'Check the health and connectivity of the vector database' (56 chars) lacks WHEN to call it, what it returns, or what to do on failure.
create_document's 'metadata' parameter defaults to {} but lacks a schema specifying valid keys/types. This invites the LLM to pass arbitrary metadata without knowing what the system accepts. Rubric: 'Document the expected format, range, and allowed values directly in the parameter description.'
create_collection includes a 'vectorizer' parameter marked as legacy with a note to use 'embedding_model' instead. Deprecated parameters create confusion, either remove it or document the migration path clearly. This violates the pattern of having a single, canonical way to accomplish a task.
delete_all_documents allows deletion without specifying a collection (optional parameter), creating a foot-gun where an LLM could accidentally delete all data across all collections. Rubric: 'A mode param defaulting to delete or an overwrite flag defaulting to true invites accidental destruction when an LLM omits the parameter.'
No pagination support documented for list tools (list_collections, list_documents, list_embedding_models). Rubric: 'Tools returning lists should accept page/offset and limit parameters and return a total count or next_cursor.' Current limit defaults are minimal (10, 5) but without documented max bounds.