Qdrant

Qdrant's official MCP turns the vector database into a persistent memory layer for Claude or any compatible host. The pitch is simple: your agent can store embeddings, search semantically, and retrieve context across sessions without you writing a single vector search query. It's a first-party integration, which means the implementation is clean and the API surface is narrow. I've used it to build a personal knowledge base where Claude can file away notes, articles, and code snippets, then pull them back when relevant. The setup requires three environment variables: your Qdrant instance URL, an API key, and a collection name. Once wired in, the agent gets tools to upsert vectors, run similarity searches, and filter by metadata. The workflow I keep coming back to is scraping technical articles into a collection, then asking Claude to summarise related posts when I'm researching a new topic. It works because Qdrant handles the heavy lifting—embedding generation, indexing, and retrieval—while the MCP layer keeps the interface dead simple. The main quirk is that you need a running Qdrant instance, either self-hosted or on their cloud. If you're not already using Qdrant, the friction of spinning up a new service might outweigh the benefit unless you're serious about long-term agent memory. The server doesn't bundle a local fallback or in-memory mode, so it's all or nothing. For developers already running Qdrant in production, this is a no-brainer: it's the cleanest way to give your agent semantic recall. For everyone else, the question is whether you need cross-session memory badly enough to justify the infrastructure. If you're building a RAG pipeline or a personal knowledge assistant, the answer is probably yes. If you're just experimenting with MCP, start with something lighter.