Is there a way to edit or delete a record in mcp-server-qdrant?
The qdrant/mcp-server-qdrant MCP server exposes store() and find(), but the issue thread (July 2025, closed as duplicate) asks whether an EDIT or DELETE tool is intentionally missing. Every store() call appears to insert a new record, so updated memories pile up as duplicates and find() returns stale versions alongside current ones. Is this behavior intended, and is there a way to update or delete an existing record?
Originally asked on GitHub: https://github.com/qdrant/mcp-server-qdrant/issues/74
3 answers
The thread was closed as a duplicate, and no fix or maintainer explanation appears in it. Commenters explained the behavior: store() generates a random UUID and stores it as the point's payload ID, so Qdrant's upsert can never match an existing point — every store() inserts a new vector instead of updating one. A commenter pointed at line 86 of src/mcp_server_qdrant/qdrant.py as the source of that behavior.
A commenter suggested that find() should return each record's UUID and that store(content[, metadata[, uuid]]) should delete or replace the existing record when a UUID is supplied. Another commenter also asked for a way to remove or edit old memories. Nothing in the thread indicates this is implemented.
The only workaround in the thread is the reporter's: add a timestamp to each record's metadata, store a duplicate record whenever content changes, and sort find() results by timestamp. The reporter notes this bloats the collection — a top-10 query returns the last 10 versions of the same record instead of 10 unique records (for example, five of "X" and five of "reprecate x").
A later commenter raised an unanswered question: when new and old "understandings" are both returned from a search, how does the AI know which one is correct, and won't outdated data build up over time?
General advice: if you depend on this server today, treat the collection as append-only and filter or deduplicate by your own metadata (such as a timestamp) in your application layer, since the thread shows no removal or update mechanism.
Did this work for you?What a GitHub user tried on GitHub (Partly worked)
The reporter timestamps every record's metadata, stores a duplicate record when content changes, and sorts find() results by timestamp. They say this is the only workaround they found, but it bloats the collection: a top-10 query shows the last 10 versions of the same record instead of 10 unique records.
Source: https://github.com/qdrant/mcp-server-qdrant/issues/74 (opens external site)
Did this work for you?What @a-canary tried on GitHub (Outcome unclear)
A commenter suggested that find() should return each record's UUID and that store(content[, metadata[, uuid]]) should delete or replace the existing record when a UUID is supplied. The thread does not show this being implemented; a later commenter confirmed the server's random-UUID-per-store() behavior prevents upsert from updating existing vectors.
Source: https://github.com/qdrant/mcp-server-qdrant/issues/74#issuecomment-3064482926 (opens external site)
Did this work for you?
Related questions
- mcp-server-qdrant 400: "Vector with name fast-bge-small-en-v1.5 is not configured in this collection"
- How do I connect mcp-server-qdrant to a local Qdrant database by folder path?
- How to fix timeout when storing Japanese text with mcp-server-qdrant on Windows?
- qdrant-find fails with 'document': what payload structure does the MCP server expect?
- How to use mcp-server-qdrant with existing Qdrant collections when vector name doesn't match?