Loading ToolBench
MCP server for Qdrant vector database with local embedding support
mcp-server-qdrant provides two core tools with clear, actionable descriptions and well-structured JSON schemas. Both tools have descriptions, input schemas with typed parameters, and proper field documentation. However, the server has several quality gaps: (1) tool names lack action verbs, 'qdrant-store' and 'qdrant-find' use nouns rather than verb_noun patterns like 'store_information' and 'search_memory', reducing LLM clarity; (2) parameter descriptions are present but minimal (avg 15-20 chars), falling short of the 72-char baseline for A+ tools; (3) output schemas are not documented in the visible source, no evidence of documented return types; (4) error handling is absent from tool definitions, no guidance on recovery strategies or error classification. The schemas themselves are sound (proper types, required fields declared), and descriptions are non-empty, placing this server solidly in the 'fair to good' range but not exceptional.
Find information in the Qdrant vector database using semantic search
Store information in the Qdrant vector database
Tool names lack action verbs. 'qdrant-store' and 'qdrant-find' are noun-based; verb_noun patterns like 'store_information' or 'search_memory' are self-documenting and let LLMs infer intent from the name alone before reading descriptions.
Parameter descriptions are sparse (avg 15-20 chars). Baseline for A+ tools is 72 chars. Descriptions lack context on when to use each parameter, what formats are expected, and relationships between parameters (e.g., does 'collection_name' require special format? What happens if not provided?). Example: 'Collection name (uses default if not provided)' is minimal; should explain default fallback behavior and when explicit collection_name is necessary.
Output schemas not documented. No visible documentation of return types for either tool. LLMs need to know what fields to expect (e.g., does store return an ID? Does find return relevance scores?) to plan downstream calls and extract data correctly. Baseline: 100% of A+ tools have documented return types.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Error handling absent from tool definitions. No guidance on error recovery, error categories, or actionable next steps. If find returns 'collection not found', should the LLM create it? Retry? Ask the user? No recovery guidance documented.
Parameter constraints not formally specified. 'metadata' and 'query_filter' are object types with no schema validation or constraints. LLMs cannot validate JSON structure and will hallucinate invalid objects. Should use oneOf/properties or constrain structure in parameter descriptions.
Tool descriptions could better explain WHEN to use each tool and what dependencies exist. For 'qdrant-find', the description mentions three use cases but doesn't explain that you must call 'qdrant-store' first to have data to search. Dependency hints guide multi-step planning.
No pagination parameters visible on qdrant-find. If find returns many results, the response could exceed context limits. Should support limit and/or offset/cursor parameters with documented defaults (e.g., 'default limit 20, max 100'). Baseline pattern: paginated-result.