Weaviate vs Qdrant
Weaviate and Qdrant are two of the most popular open-source vector databases, and both ship official MCP servers — but they make almost opposite design choices about what an agent should be able to do. Weaviate's server is built directly into the database engine: as of Weaviate 1.37.1 there is no separate package, you flip the MCP_SERVER_ENABLED feature flag and it is served on the same port as the REST API at /v1/mcp, reusing Weaviate's existing API-key auth and RBAC. It exposes database-grade operations — hybrid (vector + keyword) search, schema/config inspection, tenant listing, and object upserts. Qdrant's official server takes the opposite tack: it is a deliberately minimal 'semantic memory layer' with just two tools, qdrant-store and qdrant-find, and it generates embeddings internally with FastEmbed so an agent can persist and recall information by meaning with almost no setup. So the real question is whether you want the agent to operate a real vector database or to use one as drop-in long-term memory. Here is how they line up.
How they compare
| Dimension | Weaviate | Qdrant |
|---|---|---|
| Design intent | A database surface: hybrid search, schema/config inspection, tenant listing, and object upserts against a Weaviate instance. | A semantic memory layer: two tools (store, find) that turn Qdrant into drop-in long-term memory for an agent. |
| Tool count and granularity | A small but database-shaped set — weaviate-query-hybrid, weaviate-collections-get-config, weaviate-tenants-list, weaviate-objects-upsert. | Just qdrant-store and qdrant-find, deliberately tiny so the agent reasons about 'remember this' and 'recall that' rather than collections and schemas. |
| Embeddings | Relies on the vectors and modules configured in your Weaviate instance; the agent works against collections you've already set up. | Generates embeddings internally with FastEmbed by default, so an agent can store and retrieve text with no external embedding pipeline. |
| Deployment and auth | Built into the engine — enable a feature flag and it serves at /v1/mcp on the same port and the same API-key/RBAC security as the database itself. | A standalone reference server you point at a Qdrant instance (local, Docker, or Qdrant Cloud); the minimal surface keeps configuration light. |
| Best-fit task | Letting an agent run real hybrid search and manage objects against a Weaviate database you already operate. | Giving an agent durable, embedding-free 'memory' it can write to and recall from without managing schema. |
Verdict
Pick by what you want the agent to do with the vectors. Weaviate's in-engine server is the choice when you already run Weaviate and want the agent to perform real database work — hybrid search, schema inspection, multi-tenant listing, and upserts — secured by the same API keys and RBAC as the database. Qdrant's official server is the choice when you want the simplest possible long-term memory: two tools, internal FastEmbed embeddings, and a 'store this / find that' mental model with almost no setup. Both are excellent and both are open source; the deciding factor is database-grade control (Weaviate) versus minimal drop-in memory (Qdrant). If you need richer Qdrant database operations, note that other community Qdrant servers exist, but the official one is intentionally memory-shaped.
FAQ
- Does the official Qdrant server expose collections and schema?
- No — it is intentionally minimal, exposing only store and find so it behaves like long-term memory. Weaviate's server, by contrast, exposes config inspection, tenant listing, and upserts because it lives inside the database engine.
- Do I need a separate embedding model?
- With Qdrant's server, no — it embeds text internally via FastEmbed. With Weaviate, the agent uses whatever vectorizer/modules your instance is configured with, so embedding behavior follows your existing Weaviate setup.