Qdrant
Work a Qdrant vector database — create collections, upsert points, query by vector with filters, scroll and count, and manage aliases, indexes and snapshots.
About
Qdrant ships in the w6w first-party pack. It declares 19 actions, 4 health checks, and the host runs its code in a sandbox that never sees the credential.
- App id
io.w6w.qdrant- Version
- 0.1.1
- Author
- w6w
- Licence
- MIT
- Categories
- Search · Databases · AI & Machine Learning
Overview
Qdrant is an open-source vector database, and this app puts a whole collection lifecycle into a workflow whether it runs on Qdrant Cloud or a self-hosted instance in your own network: create, inspect and delete collections; query points with filters, hybrid search or multi-stage ranking through Qdrant’s single unified query endpoint; upsert, fetch, scroll and delete points; set or remove payload fields without touching a vector; build indexes on filtered fields; move an alias atomically for a zero-downtime re-index; and back up a collection to a snapshot.
Because a vector database’s recovery story is re-embedding the whole corpus, destructive actions are deliberately guarded — deleting a collection requires its name twice, a filtered point delete requires acknowledgement, and an empty filter, which matches every point, is refused outright rather than silently wiping a collection. Writes default to waiting until the change is actually queryable, since Qdrant’s own default returns as soon as an operation is merely queued, which otherwise makes an upsert-then-search fail intermittently for no visible reason.
The app also corrects a few defaults that work against a typical workflow: search results include their payload data by default even though Qdrant’s own endpoint returns just ids and scores unless asked, point counts are exact rather than an index estimate, and fetching points reports which requested ids came back missing rather than returning a silently short list.
Build with Qdrant
Three routes to the same 19 actions. The Workflow tab is generated from Qdrant's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
List aliases
alias-list The names pointing at collections — the mechanism behind zero-downtime re-indexing, and the reason a collection that looks unused may not be.
Point an alias at a collection
alias-update Move an alias atomically — the zero-downtime re-index. An existing alias is MOVED rather than rejected, and the old collection stays until somebody deletes it.
Create a collection
collection-create Create a collection. Vector size and distance are PERMANENT — changing embedding model later means a new collection and a full re-embed, not an update.
Delete a collection
collection-delete Destroy a collection and every point in it, permanently. Recovery means re-embedding the whole corpus — real money and hours — so this asks for the name twice.
Check a collection exists
collection-exists A boolean rather than a 404 to catch — which matters, because catching the error would also swallow a bad key or an unreachable host as 'not there'.
Get a collection
collection-get Configuration and state. `yellow` means the optimiser is still building — the collection answers queries slowly and incompletely, which is what a fresh bulk load looks like.
List collections
collection-list The collections in this instance — NAMES only. Sizes and vector configuration are `collection-get`, one call per collection.
Index a payload field
index-create Make filters on a field fast. Filtering works WITHOUT this — by scanning — so the cost appears gradually as the collection grows rather than as a failure.
Get instance info
instance-info Which Qdrant this is. Version drift is real on a self-hosted database, and an old instance refuses `points/query` in a way that looks like a bad request.
Delete payload fields
payload-delete Remove named fields from payloads, leaving the vectors and the rest intact — the shape a retention rule takes. Setting a field to null is not the same as removing it.
Set payload fields
payload-set Merge fields into points' payloads without touching their vectors — what `point-upsert` cannot do, since that replaces the point entirely.
Count points
point-count How many points match a filter. Qdrant's default is an ESTIMATE from the index — this asks for the real count, because a number that might be wrong is hard to spot.
Delete points
point-delete Remove points by id, or by filter. A filtered delete removes everything matching, has no undo, and an EMPTY filter matches everything — so it is gated.
Get points by id
point-get Fetch specific points. Asking for five and getting three back is a SUCCESS — Qdrant does not say which were missing, so this works it out.
Query points
point-query Find the nearest vectors, optionally filtered by payload. Qdrant returns ids and scores ONLY by default — this asks for payloads, because a workflow needs the data.
Scroll points
point-scroll Walk a collection page by page, filtered but not scored — for exports, re-embedding and audits. Payloads are on by default here, unlike `point-query`.
Upsert points
point-upsert Insert or REPLACE points — an existing id is overwritten entirely, so upserting without a payload deletes the payload it had. Waits for the write by default.
Create a snapshot
snapshot-create Back up a collection — the only recovery this database has. Stored on the node by default, so it protects against a bad delete rather than against losing the volume.
List snapshots
snapshot-list What backups exist and how old they are — the question that decides whether a destructive operation is recoverable. Qdrant never expires them, so the total size matters.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying Qdrant's real ids.
{
"manifestVersion": "2",
"name": "qdrant-example",
"steps": [
{
"id": "alias-update",
"uses": {
"app": "io.w6w.qdrant",
"action": "alias-update",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"alias": "<alias>",
"collection": "<collection>"
}
}
]
}Here are some of the things you can do
-
Point an alias at a collection
performalias-update -
List aliases
readalias-list -
Create a collection
performcollection-create -
Check a collection exists
readcollection-exists -
Get a collection
readcollection-get
+14 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for Qdrant, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to Qdrant. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "alias-update",
payload: {
alias: "<value>",
collection: "<value>",
// deleteOthers: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value);npm install -g @w6w/cliw6w run conn_YOUR_CONNECTION_ID --action alias-update --payload '{"alias":"<value>","collection":"<value>"}'Give an AI agent Qdrant — without giving it Qdrant's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.qdrant#alias-update",
"input": {
"alias": "<alias>",
"collection": "<collection>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's Qdrant connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
What the agent gets
Credentials it can't read
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
A tool surface scoped to the caller
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
A durable workflow in one call
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
Health-aware discovery
Qdrant's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. Qdrant itself is MIT, and the runtime that executes it is source-available (FSL).
Health checks
Qdrant declares its own checks, so its health is a property of the app rather than something the host guesses at.
Qdrant Cloud status
Resource status from status.qdrant.io (Better Stack). Covers Qdrant CLOUD — the console, the provisioning API, and the cluster regions. It cannot know which region a connection is in, or whether it is self-hosted, so it is informational and capped at degraded.
Instance readiness
Whether this Qdrant is ready to serve — `readyz`, not `livez`. A restarting instance is alive long before it can answer a query.
Collections reachable
Whether this key can read the instance, and whether there is anything in it. An instance that lost its volume comes back ready and empty, which `instance` correctly calls healthy.