Qdrant MCP Server vs Pinecone MCP Server

When to pick Qdrant MCP Server

• You want an assistant to remember information and retrieve it later by meaning. qdrant-store embeds text and stores it with optional metadata; qdrant-find retrieves information matching a natural-language query.
• You want a searchable collection of reusable code snippets. The documented approach puts a description in information and the code in metadata.code. Customize TOOL_STORE_DESCRIPTION and TOOL_FIND_DESCRIPTION to explain that convention to the assistant.
• You need a choice between a database stored at a local path, a local Qdrant service or Qdrant Cloud. Configure QDRANT_LOCAL_PATH for local storage or QDRANT_URL for a server connection.
• You want an assistant to search an existing collection without adding memories. Set QDRANT_READ_ONLY to disable qdrant-store, leaving retrieval available.

When to pick Pinecone MCP Server

• You are building an application around Pinecone and want the coding assistant to inspect its indexes. list-indexes, describe-index and describe-index-stats expose configuration, record counts and namespaces for development work.
• You need to create an index with an integrated embedding model, then insert or update text records. Use create-index-for-model and upsert-records within that workflow. The server supports indexes with integrated inference.
• You want to evaluate retrieval while developing. search-records accepts text queries with metadata filtering and reranking options; cascading-search searches multiple indexes, removes duplicate results and reranks them.
• You want the assistant to consult Pinecone documentation while writing code. search-docs searches the official documentation, and the README says this remains available without a project API key.

Main differences

• Qdrant focuses on storing and retrieving semantic memories. Pinecone covers index setup, inspection, record operations and documentation lookup. Choose according to whether the assistant needs a memory collection or access to the development workflow around Pinecone indexes.
• Qdrant uses FastEmbed to encode memories and lets you select a supported model through EMBEDDING_MODEL. Pinecone's record tools depend on integrated inference in the index. Its documented limitations exclude indexes without integrated inference, standalone embeddings and vector search.
• Qdrant defaults to a local stdio connection and also supports sse and streamable-http for remote clients. Pinecone's documented configuration starts a local Node process over stdio, which connects to Pinecone services. A locally running MCP process does not imply local database storage.
• Qdrant can use QDRANT_LOCAL_PATH without a database server URL; cloud connections add QDRANT_API_KEY. Pinecone requires PINECONE_API_KEY to manage or query project indexes. Its documentation-search exception means the key requirement depends on which tools you need.
• Qdrant lets you define a default collection with COLLECTION_NAME; without one, callers must supply the collection name. Pinecone exposes index discovery and statistics, plus rerank-documents for reranking supplied records or text documents. Qdrant's documented tool scope stays with store and find.

Setup

For Qdrant, run uvx mcp-server-qdrant with QDRANT_URL and COLLECTION_NAME in the environment. For local database mode, replace QDRANT_URL with QDRANT_LOCAL_PATH; do not set both. Add QDRANT_API_KEY for Qdrant Cloud. The server creates the named collection if it does not exist. Select remote transport with uvx mcp-server-qdrant --transport streamable-http or --transport sse.

For Pinecone, install Node.js v20 or later and make sure node and npx are on PATH. Configure the client to launch npx -y @pinecone-database/mcp and pass PINECONE_API_KEY through its environment for index access. The README documents Cursor configuration in .cursor/mcp.json and Claude Desktop configuration in claude_desktop_config.json.