Loading ToolBench
MCP server for retrieving context from a Qdrant vector database
The server defines 2 tools (qdrant-find, qdrant-store) with basic descriptions and partially visible schemas. Both tools have non-empty descriptions but they are generic and lack the specificity required for reliable LLM tool selection. Input schemas are present in the code but descriptions for individual parameters are minimal or missing. The tool names follow verb_noun convention (find, store), which is good. However, parameter descriptions are severely underdeveloped, 'collection_name' is described as 'optional' but lacks guidance on valid values or when to use it. The 'metadata' parameter in qdrant-store has a description ('JSON metadata to store with the information, optional') but no schema format specification. Return types are not documented in the visible code. Error handling guidance is absent, there is no documentation of what happens when a query returns no results, when the Qdrant service is unreachable, or when metadata is malformed. The tool descriptions mention use cases ('Find memories by their content', 'Access memories for further analysis') but do not state whether the tools have side effects or are safe to retry. Overall, the definitions are functional but lack the depth and rigor expected of production-grade agent tools.
Look up memories in Qdrant. Use this tool when you need to: - Find memories by their content - Access memories for further analysis - Get some personal information about the user
Keep the memory for later use, when you are asked to remember something.
Parameter descriptions are minimal or missing. 'collection_name' and 'metadata' parameters lack actionable guidance on format, constraints, or when to use them. The 'metadata' parameter is defined as a JSON object but has no schema specification or example.
Tool descriptions are generic and do not explain when to call qdrant-find vs other search tools, or what makes qdrant-store different from storing data elsewhere. 'Look up memories' and 'Keep the memory' lack specificity about use cases, prerequisites, or downstream impact.
No return type or output schema documentation. Code shows qdrant-find returns List[str] and qdrant-store returns str, but the LLM has no way to know this from the tool definition. No documentation of response structure, fields, or format.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
No error handling guidance. Tool descriptions do not explain what happens if the Qdrant service is down, a query returns no results, or metadata is invalid. The LLM has no recovery path if a call fails.
Idempotency and side effects not documented. qdrant-store is a write operation, the description does not state whether repeated calls with the same data create duplicates or update existing records. This matters for agent retry logic.
Parameter 'metadata' is defined as non-optional in the schema (type: 'object') but the Python code treats it as optional with a default of None. This mismatch could confuse LLMs about whether the parameter is required.