Loading ToolBench
An MCP server for Qdrant vector database that provides tools for searching, reading, and managing vector collections. Supports both read-only and write-enabled modes.
Kdrant offers 8 well-named tools with clear verb-noun patterns (list_, describe_, search_, scroll_, retrieve_, count_, upsert_, delete_). All tools have descriptions (avg 120 chars, within baseline 34 - 392). Input schemas are present and properly typed with JSON Schema. However, parameter descriptions are sparse or missing for several tools (e.g., scroll_points lacks descriptions for match_key/match_value semantics), and output schemas are not documented. Error handling is basic (catch-all failure messages). No tool annotations (readOnlyHint/destructiveHint) despite clear risk classification in code. Write tools (upsert_points, delete_points) lack confirmation/dry-run patterns. Overall solid naming and schema structure, but parameter documentation and output clarity need work.
Count the points in a collection, optionally filtered by an exact payload match.
Delete points from a collection by id.
The vector configuration, shard layout and payload indexes of one collection. Worth calling before search_points, because it names the vector sizes and the indexed payload fields a filter can use.
List the collections on this Qdrant, with their point counts and status.
Fetch points by id.
Read points in id order without a query vector, optionally filtered by an exact payload match. For looking at what a collection holds rather than searching it.
upsert_points lacks schema detail for 'points' array structure. The description says 'The points to insert or update' but does not specify required fields (id, vector, payload) or their types. LLMs cannot construct valid payloads without this.
scroll_points parameters match_key and match_value lack descriptions explaining the filtering semantics. Are they case-sensitive? What happens if match_key does not exist? This forces LLMs to guess.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract fields without knowing the response structure. E.g., search_points returns {id, score, payload} but this is inferred from code, not declared.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | <=2025-11-25 | v2 |
Nearest-neighbour search with a dense vector. The vector has to have the dimension the collection was created with; describe_collection reports it.
Insert or update points in a collection. Points are identified by id; an id that exists is updated, and one that does not is inserted.
Destructive tools (upsert_points, delete_points) lack confirmation or dry-run patterns. An agent could accidentally delete all points in a collection with no recovery path.
Tool definitions in code carry risk metadata (write=true/false) but MCP registration does not expose tool annotations (readOnlyHint, destructiveHint, idempotentHint). Clients cannot distinguish safe from unsafe tools at discovery time.