Can LanceDB's server store new information?

Its three tools are retrieval-focused — catalog_search, chunks_search, and all_chunks_search over an existing local LanceDB index. For a writable store-and-retrieve memory, the Qdrant server exposes a store tool alongside find.

LanceDB vs Qdrant

Both of these MCP servers give an agent vector-powered retrieval, but they sit at different layers of the stack and expose very different surfaces. The LanceDB server (Adiom) is built for agentic RAG over a local LanceDB index using a two-level data model: a catalog of document-level summaries and a chunk store of the underlying passages. It gives the agent three focused tools — search the catalog for relevant documents, find the right chunks within them, and search all chunks directly — so it is essentially a ready-made hybrid-search RAG layer over your documents. The Qdrant server is the official reference implementation that turns a Qdrant vector database into a semantic memory layer, exposing two deliberately small tools: one to store a piece of information with optional metadata, and one to retrieve the most relevant stored information for a natural-language query. So the choice is between a document-RAG layer (LanceDB) and a store-and-retrieve semantic memory (Qdrant). Here is how they compare for an agent.

How they compare

Dimension	LanceDB	Qdrant
Purpose	Agentic RAG over documents: search a catalog of summaries and the chunks beneath them.	Semantic memory: store arbitrary information and retrieve the most relevant for a query.
Data model	Two levels — document-level catalog plus a chunk store of the underlying passages.	Vectors with optional structured metadata in a Qdrant collection.
Tools	Three retrieval tools: catalog_search, chunks_search, and all_chunks_search.	Two tools: qdrant-store to save information and qdrant-find to retrieve it.
Write/store side	Read-focused — the server searches an existing local LanceDB index of documents.	Includes storing — the agent can write new information into the vector store as memory.
Hosting	Local LanceDB index, an embedded, file-based vector store, ideal for a self-contained RAG corpus.	A Qdrant vector database (self-hosted or cloud) used as a general semantic memory layer.

Verdict

Choose by whether you need document RAG or a writable semantic memory. The LanceDB server is the pick when you have a corpus of documents in a local LanceDB index and want ready-made, two-level retrieval — search summaries, then drill into chunks, or search all chunks directly — without building a RAG layer yourself. The Qdrant server is the choice when you want the agent to both store and recall information as memory: its two tools save pieces of information with metadata and retrieve the most relevant for a query, backed by a Qdrant vector database. They solve different problems — LanceDB for hybrid search over an existing document set, Qdrant for general store-and-retrieve memory. Match the server to whether your job is retrieving from documents or remembering across a session.

FAQ

Can LanceDB's server store new information?: Its three tools are retrieval-focused — catalog_search, chunks_search, and all_chunks_search over an existing local LanceDB index. For a writable store-and-retrieve memory, the Qdrant server exposes a store tool alongside find.
What is Qdrant's server best at?: It acts as a semantic memory layer with two small tools: qdrant-store to save a piece of information (with optional metadata) and qdrant-find to retrieve the most relevant stored information for a query.