qdrant-store
Store some information in the Qdrant database
metadatainformationrequiredcollection_name
io.github.CloudCorpRecordsPublished by GitHub account CloudCorpRecordsv0.1.0Updated Nov 7, 2026
Store and retrieve text in a Qdrant vector database by similarity search.
A small local memory server that stores text in a Qdrant vector database and retrieves it later by similarity search.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Follow the launch instructions in the repository.
vectorsearch is a small memory for agents: store a piece of information now, then ask for it back later with a plain-language query. It keeps exactly two operations — store and find — and backs them with a Qdrant vector database over its REST API.
Set QDRANT_URL to reach a non-default service (it assumes
http://localhost:6333). The collection used when a call does not
name one comes from COLLECTION_NAME and defaults to documents.
Storing into a collection that does not exist yet creates it first,
sized to this tool's embedding dimension with cosine distance.
Or run the container image:
The container defaults to the MCP server (see below). Pass CLI arguments to use it as a CLI instead.
Exit codes: 0 on success, 1 when the service call fails (the error
includes the HTTP status), 2 for usage errors.
One bin serves both faces. The mcp subcommand starts a stdio MCP
server:
MCP client configuration:
The reference design pairs Qdrant with an external embedding model. This rebuild deliberately calls no external embedding service. Instead it embeds text locally with a deterministic hash-based function: the same text always produces the same unit vector, and texts that share tokens land near each other, which keeps store and find self-consistent and fully offline. Be clear-eyed about the trade-off: this is a local fallback with token-overlap similarity, not model-grade semantic embeddings. Swapping in a real embedding provider later only changes the executor's vector function — the tools, schemas, and storage shape stay the same.
Point ids are likewise deterministic, derived from a hash of the text (and metadata when present), so re-storing the same information updates the same point instead of piling up duplicates.
Dispatch, default-collection resolution, and error propagation are tested against a fake executor; the Qdrant REST executor is tested against a fake fetch that records its requests (collection ensure / create-on-missing, point upsert shape, search mapping).
MIT — see LICENSE.
Source: README.md at commit 9626c3d
Store some information in the Qdrant database
metadatainformationrequiredcollection_nameRetrieve relevant information from the Qdrant database
queryrequiredcollection_name90% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
npx @reneturcios/vectorsearch find "how do we deploy the staging app"docker run -i ghcr.io/cloudcorprecords/vectorsearch# Store something (optionally into a named collection)vectorsearch store "the staging deploy runs from the release branch" --collection notes
# Ask for it backvectorsearch find "staging deploy" --collection notes
# Start the MCP servervectorsearch mcp
vectorsearch --versionnpx -y @reneturcios/vectorsearch mcp{ "mcpServers": { "vectorsearch": { "command": "npx", "args": ["-y", "@reneturcios/vectorsearch", "mcp"], "env": { "QDRANT_URL": "http://localhost:6333", "COLLECTION_NAME": "documents" } } }}npm installnpm run build # tsc -> dist/npm test # node test runner over test/*.test.ts, fakes only, no live servicenpm run dev # run the CLI from source via tsx