mcp-server-qdrant
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mcp-server-qdrantRemember that the project deadline is March 15th."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
mcp-server-qdrant: A Qdrant MCP server
The Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. Whether you're building an AI-powered IDE, enhancing a chat interface, or creating custom AI workflows, MCP provides a standardized way to connect LLMs with the context they need.
This repository is an example of how to create a MCP server for Qdrant, a vector search engine.
Overview
An official Model Context Protocol server for keeping and retrieving memories in the Qdrant vector search engine. It acts as a semantic memory layer on top of the Qdrant database.
Related MCP server: better-qdrant-mcp
Components
Tools
qdrant-storeStore some information in the Qdrant database
Input:
information(string): Information to storemetadata(JSON): Optional metadata to storecollection_name(string): Name of the collection to store the information in. This field is required if there are no default collection name. If there is a default collection name, this field is not enabled.
Returns: Confirmation message
qdrant-findRetrieve relevant information from the Qdrant database
Input:
query(string): Query to use for searchingcollection_name(string): Name of the collection to store the information in. This field is required if there are no default collection name. If there is a default collection name, this field is not enabled.
Returns: Information stored in the Qdrant database as separate messages
Environment Variables
Configuration is done via environment variables. The only command-line argument is --transport, used to select the transport protocol.
You cannot provide bothQDRANT_URL and QDRANT_LOCAL_PATH at the same time.
Name | Description | Default Value |
| URL of the Qdrant server | None |
| API key for the Qdrant server | None |
| Name of the default collection to use. | None |
| Path to the local Qdrant database (alternative to | None |
| Embedding provider to use (currently only "fastembed" is supported) |
|
| Name of the embedding model to use |
|
| Custom description for the store tool | See default in |
| Custom description for the find tool | See default in |
| Maximum number of results to return from search |
|
| Enable read-only mode (disables |
|
FastMCP Environment Variables
Since mcp-server-qdrant is based on FastMCP, it also supports all the FastMCP environment variables. The most
important ones are listed below:
Environment Variable | Description | Default Value |
| Set logging level (DEBUG, INFO, WARNING, ERROR, CRITICAL) |
|
| Enable debug mode |
|
| Host address to bind the server to |
|
| Port to run the server on |
|
| Behavior for duplicate resources (warn, error, replace, ignore) |
|
| Behavior for duplicate tools (warn, error, replace, ignore) |
|
| Behavior for duplicate prompts (warn, error, replace, ignore) |
|
| List of dependencies to install in the server environment |
|
Server-specific settings use theFASTMCP_SERVER_ prefix. This may change in future versions.
Installation
Using uvx
When using uvx no specific installation is needed to directly run mcp-server-qdrant.
QDRANT_URL="http://localhost:6333" \
COLLECTION_NAME="my-collection" \
EMBEDDING_MODEL="sentence-transformers/all-MiniLM-L6-v2" \
uvx mcp-server-qdrantTransport Protocols
The server supports different transport protocols that can be specified using the --transport flag:
QDRANT_URL="http://localhost:6333" \
COLLECTION_NAME="my-collection" \
uvx mcp-server-qdrant --transport sseSupported transport protocols:
stdio(default): Standard input/output transport, might only be used by local MCP clientssse: Server-Sent Events transport, perfect for remote clientsstreamable-http: Streamable HTTP transport, perfect for remote clients, more recent than SSE
The default transport is stdio if not specified.
When SSE transport is used, the server will listen on the specified port and wait for incoming connections. The default
port is 8000, however it can be changed using the FASTMCP_SERVER_PORT environment variable.
QDRANT_URL="http://localhost:6333" \
COLLECTION_NAME="my-collection" \
FASTMCP_SERVER_PORT=1234 \
uvx mcp-server-qdrant --transport sseUsing Docker
A Dockerfile is available for building and running the MCP server:
# Build the container
docker build -t mcp-server-qdrant .
# Run the container
docker run -p 8000:8000 \
-e FASTMCP_SERVER_HOST="0.0.0.0" \
-e QDRANT_URL="http://your-qdrant-server:6333" \
-e QDRANT_API_KEY="your-api-key" \
-e COLLECTION_NAME="your-collection" \
mcp-server-qdrantPlease note that we setFASTMCP_SERVER_HOST="0.0.0.0" to make the server listen on all network interfaces. This is
necessary when running the server in a Docker container.
Installing via Smithery
To install Qdrant MCP Server for Claude Desktop automatically via Smithery:
npx @smithery/cli install mcp-server-qdrant --client claudeManual configuration of Claude Desktop
To use this server with the Claude Desktop app, add the following configuration to the "mcpServers" section of your
claude_desktop_config.json:
{
"qdrant": {
"command": "uvx",
"args": ["mcp-server-qdrant"],
"env": {
"QDRANT_URL": "https://xyz-example.eu-central.aws.cloud.qdrant.io:6333",
"QDRANT_API_KEY": "your_api_key",
"COLLECTION_NAME": "your-collection-name",
"EMBEDDING_MODEL": "sentence-transformers/all-MiniLM-L6-v2"
}
}
}For local Qdrant mode:
{
"qdrant": {
"command": "uvx",
"args": ["mcp-server-qdrant"],
"env": {
"QDRANT_LOCAL_PATH": "/path/to/qdrant/database",
"COLLECTION_NAME": "your-collection-name",
"EMBEDDING_MODEL": "sentence-transformers/all-MiniLM-L6-v2"
}
}
}This MCP server will automatically create a collection with the specified name if it doesn't exist.
By default, the server will use the sentence-transformers/all-MiniLM-L6-v2 embedding model to encode memories.
For the time being, only FastEmbed models are supported.
Support for other tools
This MCP server can be used with any MCP-compatible client. For example, you can use it with Cursor and VS Code, which provide built-in support for the Model Context Protocol.
Using with Cursor/Windsurf
You can configure this MCP server to work as a code search tool for Cursor or Windsurf by customizing the tool descriptions:
QDRANT_URL="http://localhost:6333" \
COLLECTION_NAME="code-snippets" \
TOOL_STORE_DESCRIPTION="Store reusable code snippets for later retrieval. \
The 'information' parameter should contain a natural language description of what the code does, \
while the actual code should be included in the 'metadata' parameter as a 'code' property. \
The value of 'metadata' is a Python dictionary with strings as keys. \
Use this whenever you generate some code snippet." \
TOOL_FIND_DESCRIPTION="Search for relevant code snippets based on natural language descriptions. \
The 'query' parameter should describe what you're looking for, \
and the tool will return the most relevant code snippets. \
Use this when you need to find existing code snippets for reuse or reference." \
uvx mcp-server-qdrant --transport sse # Enable SSE transportIn Cursor/Windsurf, you can then configure the MCP server in your settings by pointing to this running server using SSE transport protocol. The description on how to add an MCP server to Cursor can be found in the Cursor documentation. If you are running Cursor/Windsurf locally, you can use the following URL:
http://localhost:8000/sseWe suggest SSE transport as a preferred way to connect Cursor/Windsurf to the MCP server, as it can support remote connections. That makes it easy to share the server with your team or use it in a cloud environment.
This configuration transforms the Qdrant MCP server into a specialized code search tool that can:
Store code snippets, documentation, and implementation details
Retrieve relevant code examples based on semantic search
Help developers find specific implementations or usage patterns
You can populate the database by storing natural language descriptions of code snippets (in the information parameter)
along with the actual code (in the metadata.code property), and then search for them using natural language queries
that describe what you're looking for.
The tool descriptions provided above are examples and may need to be customized for your specific use case. Consider adjusting the descriptions to better match your team's workflow and the specific types of code snippets you want to store and retrieve.
If you have successfully installed the mcp-server-qdrant, but still can't get it to work with Cursor, please
consider creating the Cursor rules so the MCP tools are always used when
the agent produces a new code snippet. You can restrict the rules to only work for certain file types, to avoid using
the MCP server for the documentation or other types of content.
Using with Claude Code
You can enhance Claude Code's capabilities by connecting it to this MCP server, enabling semantic search over your existing codebase.
Setting up mcp-server-qdrant
Add the MCP server to Claude Code:
# Add mcp-server-qdrant configured for code search claude mcp add code-search \ -e QDRANT_URL="http://localhost:6333" \ -e COLLECTION_NAME="code-repository" \ -e EMBEDDING_MODEL="sentence-transformers/all-MiniLM-L6-v2" \ -e TOOL_STORE_DESCRIPTION="Store code snippets with descriptions. The 'information' parameter should contain a natural language description of what the code does, while the actual code should be included in the 'metadata' parameter as a 'code' property." \ -e TOOL_FIND_DESCRIPTION="Search for relevant code snippets using natural language. The 'query' parameter should describe the functionality you're looking for." \ -- uvx mcp-server-qdrantVerify the server was added:
claude mcp list
Using Semantic Code Search in Claude Code
Tool descriptions, specified in TOOL_STORE_DESCRIPTION and TOOL_FIND_DESCRIPTION, guide Claude Code on how to use
the MCP server. The ones provided above are examples and may need to be customized for your specific use case. However,
Claude Code should be already able to:
Use the
qdrant-storetool to store code snippets with descriptions.Use the
qdrant-findtool to search for relevant code snippets using natural language.
Run MCP server in Development Mode
The MCP server can be run in development mode using the mcp dev command. This will start the server and open the MCP
inspector in your browser.
COLLECTION_NAME=mcp-dev fastmcp dev src/mcp_server_qdrant/server.pyUsing with VS Code
For one-click installation, click one of the install buttons below:
Manual Installation
Add the following JSON block to your User Settings (JSON) file in VS Code. You can do this by pressing Ctrl + Shift + P and typing Preferences: Open User Settings (JSON).
{
"mcp": {
"inputs": [
{
"type": "promptString",
"id": "qdrantUrl",
"description": "Qdrant URL"
},
{
"type": "promptString",
"id": "qdrantApiKey",
"description": "Qdrant API Key",
"password": true
},
{
"type": "promptString",
"id": "collectionName",
"description": "Collection Name"
}
],
"servers": {
"qdrant": {
"command": "uvx",
"args": ["mcp-server-qdrant"],
"env": {
"QDRANT_URL": "${input:qdrantUrl}",
"QDRANT_API_KEY": "${input:qdrantApiKey}",
"COLLECTION_NAME": "${input:collectionName}"
}
}
}
}
}Or if you prefer using Docker, add this configuration instead:
{
"mcp": {
"inputs": [
{
"type": "promptString",
"id": "qdrantUrl",
"description": "Qdrant URL"
},
{
"type": "promptString",
"id": "qdrantApiKey",
"description": "Qdrant API Key",
"password": true
},
{
"type": "promptString",
"id": "collectionName",
"description": "Collection Name"
}
],
"servers": {
"qdrant": {
"command": "docker",
"args": [
"run",
"-p", "8000:8000",
"-i",
"--rm",
"-e", "QDRANT_URL",
"-e", "QDRANT_API_KEY",
"-e", "COLLECTION_NAME",
"mcp-server-qdrant"
],
"env": {
"QDRANT_URL": "${input:qdrantUrl}",
"QDRANT_API_KEY": "${input:qdrantApiKey}",
"COLLECTION_NAME": "${input:collectionName}"
}
}
}
}
}Alternatively, you can create a .vscode/mcp.json file in your workspace with the following content:
{
"inputs": [
{
"type": "promptString",
"id": "qdrantUrl",
"description": "Qdrant URL"
},
{
"type": "promptString",
"id": "qdrantApiKey",
"description": "Qdrant API Key",
"password": true
},
{
"type": "promptString",
"id": "collectionName",
"description": "Collection Name"
}
],
"servers": {
"qdrant": {
"command": "uvx",
"args": ["mcp-server-qdrant"],
"env": {
"QDRANT_URL": "${input:qdrantUrl}",
"QDRANT_API_KEY": "${input:qdrantApiKey}",
"COLLECTION_NAME": "${input:collectionName}"
}
}
}
}For workspace configuration with Docker, use this in .vscode/mcp.json:
{
"inputs": [
{
"type": "promptString",
"id": "qdrantUrl",
"description": "Qdrant URL"
},
{
"type": "promptString",
"id": "qdrantApiKey",
"description": "Qdrant API Key",
"password": true
},
{
"type": "promptString",
"id": "collectionName",
"description": "Collection Name"
}
],
"servers": {
"qdrant": {
"command": "docker",
"args": [
"run",
"-p", "8000:8000",
"-i",
"--rm",
"-e", "QDRANT_URL",
"-e", "QDRANT_API_KEY",
"-e", "COLLECTION_NAME",
"mcp-server-qdrant"
],
"env": {
"QDRANT_URL": "${input:qdrantUrl}",
"QDRANT_API_KEY": "${input:qdrantApiKey}",
"COLLECTION_NAME": "${input:collectionName}"
}
}
}
}Contributing
If you have suggestions for how mcp-server-qdrant could be improved, or want to report a bug, open an issue! We'd love all and any contributions.
Testing mcp-server-qdrant locally
The MCP inspector is a developer tool for testing and debugging MCP servers. It runs both a client UI (default port 5173) and an MCP proxy server (default port 3000). Open the client UI in your browser to use the inspector.
QDRANT_URL=":memory:" COLLECTION_NAME="test" \
fastmcp dev src/mcp_server_qdrant/server.pyOnce started, open your browser to http://localhost:5173 to access the inspector interface.
License
This MCP server is licensed under the Apache License 2.0. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the Apache License 2.0. For more details, please see the LICENSE file in the project repository.
Available Tools
2 toolsqdrant-findA
Look up memories in Qdrant. Use this tool when you need to:
Find memories by their content
Access memories for further analysis
Get some personal information about the user
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to search for | |
| collection_name | Yes | The collection to search in |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'look up memories,' which implies a read-only operation but does not explicitly state that, nor does it mention return format, permissions, or potential side effects. This is a significant gap for a lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. The bullet list adds some redundancy (e.g., 'Find memories by their content' is nearly synonymous with 'Look up memories'), but the overall length is appropriate and no words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema), and the description covers its main purpose and key use cases. However, it does not describe what the tool returns (since there is no output schema), and it does not clarify that it is strictly a retrieval tool (as opposed to qdrant-store). This leaves some gaps, but the description is adequate for a basic lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both 'query' and 'collection_name' have descriptions), so the baseline is 3. The tool description itself adds no extra parameter context, but the schema already adequately explains what each parameter does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource construction ('Look up memories in Qdrant'), immediately distinguishing this tool from its sibling 'qdrant-store'. The bulleted use cases further reinforce the purpose by listing specific retrieval scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool with three concrete use cases. However, it does not mention when not to use it or reference the sibling 'qdrant-store' as an alternative, so it falls short of the explicit when/when-not guidance required for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qdrant-storeB
Keep the memory for later use, when you are asked to remember something.
| Name | Required | Description | Default |
|---|---|---|---|
| metadata | No | Extra metadata stored along with memorised information. Any json is accepted. | |
| information | Yes | Text to store | |
| collection_name | Yes | The collection to store the information in |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that memory is kept for later use, but does not disclose potential side effects, idempotency, permission requirements, or return behavior. This is a significant gap for a write-type tool, similar to the update_drive example.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, making it concise. However, it under-specifies in terms of purpose, but that is a matter of content, not conciseness. The structure is efficient and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with fully documented parameters and no output schema. However, the description lacks details about return values or behavior on failure/success, and the relationship to qdrant-find is not addressed. Given the simplicity, this is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters with descriptions, so the baseline is 3. The tool description does not add any additional meaning about the parameters beyond what the schema already provides for 'information', 'collection_name', and 'metadata'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Keep the memory for later use' conveys a storing/remembering action but is metaphorical and lacks specificity about the resource (e.g., 'store information in a qdrant collection'). It does not explicitly differentiate from the sibling tool qdrant-find, though the contrast is implied. The verb 'keep' is less precise than 'store' or 'save'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'when you are asked to remember something' provides a clear context for when to use the tool. However, it does not mention alternatives or exclusion cases, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
The two tools have clearly distinct purposes: qdrant-find retrieves memories while qdrant-store saves them. There is no overlap or ambiguity between them.
Both tools follow the same 'qdrant-<verb>' pattern, using lowercase snake case. The verb clearly indicates the action (find vs. store), making the naming predictable and consistent.
With only two tools, the server feels minimal for a memory system. While find and store cover basic operations, the count is borderline and could easily support more operations like delete or list.
The tool surface covers create (store) and read (find) but lacks update and delete operations for memories. This is a notable gap for a complete lifecycle, though the core functionality works.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
An MCP memory server. One memory your agents share — across models, devices and apps.
Cloud-hosted MCP server for durable AI memory
Cross-vendor AI memory over MCP. One semantic store, readable and writeable from every MCP client.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA Machine Control Protocol (MCP) server that enables storing and retrieving information from a Qdrant vector database with semantic search capabilities.Apache 2.0
- AlicenseAqualityDmaintenanceAn MCP server that provides long-term memory and semantic search using Qdrant and OpenAI embeddings, with tools for storing, searching, and managing knowledge.61MIT
- AlicenseNot gradedqualityDmaintenanceMCP server that gives AI coding agents persistent, semantic memory via Qdrant vector search, enabling workspace-aware codebase, documentation, and decision search.MIT
- AlicenseBqualityCmaintenanceAn MCP server for storing and retrieving memories using Qdrant vector search, acting as a semantic memory layer.2Apache 2.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bartest5/qdrant_mcp-server-qdrant'
If you have feedback or need assistance with the MCP directory API, please join our Discord server