Loading ToolBench
Official n8n node to interface with Qdrant - a vector database for similarity search and AI applications
This is an n8n node package, not an MCP server. The repository contains 27 Qdrant operation nodes built for the n8n workflow automation platform using the n8n-workflow framework. Critical issues: (1) This is NOT an MCP server, it has no MCP protocol implementation, no transport layer for MCP clients, and no tool registration via MCP's CallToolRequest/CallToolResponse mechanism. (2) Tool definitions are embedded in n8n's INodeProperties/INodePropertyOptions format, not exposed as MCP tools with standardized schemas. (3) Most parameter schemas are incomplete or missing required type information. (4) Many parameter descriptions are generic or trivial. (5) No output schemas documented. (6) Error handling is not visible in provided code samples. (7) No authentication/permission gating patterns evident. This evaluation treats the 27 Qdrant operations as pseudo-tools, but the fundamental mismatch is that n8n nodes are NOT MCP tools and cannot be scored on the MCP rubric.
Batch update points, including their respective vectors and payloads
Removes the entire payload for specified points
Check if a collection exists in the Qdrant instance
Counts the number of points that match a specified filtering condition
Create a new collection in the Qdrant instance
Creates a payload index for a field in the specified collection
Not an MCP server, this is an n8n node package. Tool definitions use n8n's INodeProperties format, not MCP's tool registration protocol. Cannot be evaluated against the MCP rubric. Requires fundamental architectural redesign to expose as an MCP server.
Most operation definitions show only minimal parameter schemas in the provided code samples. updateCollection, scrollPoints, queryPoints, queryBatchPoints, queryPointsGroups, upsertPoints, and others lack visible input parameter definitions beyond the collection name.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 35 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Delete the specified collection
Deletes specified payload keys from points
Deletes a payload index for a field in the specified collection
Delete specified points from the collection
Delete vectors from existing points
Calculate distance matrix using offsets
Calculate distance matrix for point pairs
Get detailed information about a collection
List all collections in the Qdrant instance
Overwrite the entire payload for specific points
Retrieve faceted search results for payload fields
Batch search for multiple point queries
Search for points using vector similarity
Search for points with result grouping
Retrieve a single point from a collection
Retrieve multiple points from a collection by their IDs
Scroll through points in a collection with pagination
Set payload for specific points in a collection
Update parameters of an existing collection
Update vectors for existing points
Insert or update points in a collection
Parameter descriptions are uniformly generic and short (under 50 characters). Examples: 'Name of the collection', 'Retrieve a single point from a collection'. These provide minimal guidance to an LLM agent about what values are valid, when to call the tool, or what happens next. Descriptions should be 50-200 characters, include constraints, and answer WHAT, WHEN, and WHY.
No output schemas documented anywhere in the provided code. Agents have no visibility into what fields each operation returns, which breaks downstream tool chaining. For example, after queryPoints, what fields are in the result? Do they include point_id, vector, payload? Without this, agents cannot extract the right data for subsequent calls.
No visible error handling or recovery guidance in provided code samples. If deleteCollection fails because the collection is in use, what is returned? Can the agent retry? Should it call a different tool? No error classification or actionable guidance for agents.
Destructive operations (deleteCollection, deletePoints, clearPayload) lack confirmation or dry-run support. Agents can delete data without a reversibility check, risking data loss.
No pagination declared for list/scroll operations. scrollPoints and queryBatchPoints likely return many results; without limit/offset and a total count, agents risk context window exhaustion or missing data. Pagination should be a first-class parameter.
Parameter type mismatches. resourceLocator type used for some parameters (updateCollection, getCollection, deleteCollection, upsertPoints, etc.) suggests the definitions may rely on n8n-specific type handling. In standard JSON Schema, these should be typed as 'string' with a description clarifying whether they accept IDs, names, or both.
No permission or scope declarations visible. Tools like deleteCollection should declare what permissions they require (e.g., 'write:collections', 'admin'). No audit trail mechanism mentioned.
Generic JSON parameters (vectors, sparseVectors, hnswConfig, walConfig, etc. in createCollection) lack schema validation or format documentation. Agents cannot infer the internal structure of these JSON blobs, increasing the risk of malformed inputs.