mrkeyoor.com_
Tue 01 Sept 16:15 UTC

This page is what happened when we ran it. The project itself — code, maintenance, community — has its own review: full repo review →

DatabasesMCP servermeasured 19 Aug 2026

Qdrant

Qdrant's MCP server, published by the Qdrant team as the Python package mcp-server-qdrant, turns a Qdrant vector collection into a semantic memory an assistant can write to and search. You point it at a Qdrant URL and a collection, it embeds text and stores it, and later retrieves the closest matches over stdio.

BootDID NOT BOOTWe started it and it never completed initialize: exited with code 1 before initialize completed
Tools0tools/list payload 0 bytes
Context tax~0estimated tokens for the whole tools/list, chars/4 estimate
Resources / prompts / counts returned by resources/list and prompts/list
Measured19 Aug 2026one run of the harness, clean environment, no credentials · how we test

How we started it

uvx mcp-server-qdrant
Verdict

We could not get it to start, and the reason is worth knowing before you blame your own config: it reads a .env file at startup through pydantic-settings, and in our clean sandbox that read raised a permission error and killed the process with exit code 1 before initialize ever ran. Nothing about Qdrant itself failed. Use it if you already run Qdrant and can give the process a working directory it owns plus real connection settings; skip it if you wanted a memory layer you could drop in unconfigured and try, because this one will not even greet you until the environment is right.

Use it if

You already operate a Qdrant instance or Qdrant Cloud cluster and want an assistant to read and write one collection of it
You want persistent semantic memory across sessions rather than whatever fits in the context window
You can launch the server from a directory it has read access to, with the connection and embedding settings supplied as environment variables
You prefer a small, single-purpose store-and-find tool surface over a database client that exposes every operation

Skip it if

You expected it to boot with no configuration so you could look at the tools first; ours never got that far
You have no Qdrant to point it at and no appetite to stand one up
Your MCP client launches servers from a directory the server process cannot read, which is exactly what broke our run
You want SQL-shaped querying, filtering and joins; this is embed, store, retrieve
You need the server to fail loudly and legibly, because what we got was a Python traceback ending in a permission error on a file we never created

The bill for your context window

The Context Tax column stays blank for Qdrant. The tools list is the first thing a server sends after initialize, and this one exited before initialize, so the measured token cost is nothing and that zero is an absence rather than a virtue. For reference, the healthy servers in this batch cluster around a couple of thousand tokens of tool descriptions, and Qdrant's published tool surface is small: store and find, with an optional read-only mode. If it boots for you, expect it to sit at the light end rather than anywhere near the heavyweights, but treat that as a forecast, not a measurement.

Setup reality

It runs under uvx as mcp-server-qdrant, so uv is the only prerequisite besides a reachable Qdrant. The startup path loads settings through pydantic-settings, which looks for a .env file in the current working directory before anything else; when that read fails, as it did for us, the process dies during import and no JSON-RPC handshake happens. The README documents the connection URL, API key and collection name as environment variables, plus an embedding model choice. Our harness scraped no env-var names from stderr, because the crash arrived before the server got as far as complaining about missing configuration. Practically: launch it from a directory the user owns, set the variables in the client config rather than relying on a dotenv file, and confirm the collection exists first.

Questions people ask

Why did the Qdrant MCP server fail to start when you measured it?

We started it as an unprivileged probe user with a clean environment. Before reaching initialize, pydantic-settings tried to open a .env file in the working directory and hit a permission error, so Python raised and the process exited with code 1. That is a launch-environment problem, not a bug in Qdrant.

Do I need my own Qdrant server to use it?

Yes. It is a client to a Qdrant instance, not an embedded database. Either run Qdrant locally or use Qdrant Cloud, then give the MCP server the URL, API key where required, and a collection name. Without those it has nothing to search.

Is it an official Qdrant project?

It lives under the Qdrant organisation on GitHub and is published by that team, so it is vendor-maintained rather than community fan work. We still list it as unofficial in our directory because it is not part of the reference MCP server set.

What would you change to make it boot?

Run it from a directory the launching user can read, pass configuration through your MCP client's env block instead of a dotenv file, and verify the target collection exists. That removes the failure we hit and lets the handshake complete.

Other databases servers we started

ServerVendorBootsContext tax
ChromaChroma~0 tokens
ElasticsearchElastic~0 tokens
MongoDBMongoDB~9,462 tokens
MySQLcommunity (benborla29)~100 tokens
PineconePinecone~6,165 tokens
PostgreSQL (archived)Anthropic (archived)~33 tokens
SupabaseSupabase~0 tokens

How this page is made: the server is spawned as an unprivileged user with a clean environment and no credentials, then asked for its tools, resources and prompts over stdio. Token figures are estimates at four characters per token, not a tokenizer count. One run, one machine. Corrections: contact the desk.

← All measured MCP servers