mcp-server-qdrant：把 Qdrant 當成 LLM 的語意記憶層
An official Qdrant Model Context Protocol (MCP) server implementation
秒懂
- 它是什麼？
- Qdrant 官方維護的 MCP server，只暴露 qdrant-store 與 qdrant-find 兩個工具，用環境變數設定連線與嵌入模型。它的設計刻意窄，好處是接上 IDE 只要幾行設定，代價是檢索行為幾乎沒有可調空間。
- 適合誰用？
- 如果你要的是讓 Claude、Cursor 這類 MCP 客戶端記住跨對話的片段，而且能接受預設的 all-MiniLM-L6-v2 嵌入與不可調的檢索參數，這個 server 用 uvx 就能跑起來，設定成本極低。若你的場景需要 rerank、混合檢索、多向量或自訂距離度量，這個 repo 沒有對應的環境變數可調，應該直接寫 Qdrant 客戶端而不經過 MCP。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 12 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「LLM 記不住」而不是「搜尋不夠準」
MCP 客戶端本身沒有跨工作階段的記憶。你在 Cursor 裡跟模型討論過的架構決定，換一個對話就沒了。這個 server 的做法是在 Qdrant 前面放一層薄薄的轉接：模型透過工具呼叫把片段寫進向量資料庫，之後用自然語言查回來。README 的定位寫得很直白，說它是「a semantic memory layer on top of the Qdrant database」，而不是一個通用檢索服務。
目標使用者是已經在用 MCP 客戶端、手上又有 Qdrant 實例的人。倉庫主題標籤列了 claude、cursor、windsurf，說明它預設的消費端是 IDE 與桌面助理。如果你的需求是替自家後端服務加一套文件問答，這個專案的工具介面（只有 store 與 find）大概不夠用，你要的是 Qdrant 的 Python 或 Rust 客戶端。
兩個工具，一條從自然語言到向量庫的路
整個 server 只註冊兩個工具。qdrant-store 接受 information（要存的字串）、選填的 metadata（JSON），以及 collection_name；qdrant-find 接受 query 與 collection_name。回傳值方面，store 回一句確認訊息，find 則把命中的內容以「separate messages」的形式回傳，也就是多筆結果分別送出而不是包成一個大 JSON。
collection_name 這個參數的行為值得注意。README 寫明：只有在沒有預設 collection 名稱時，這個欄位才是必填；一旦設了 COLLECTION_NAME，該欄位就不會出現在工具介面裡。這是一個二選一的設計。好處是模型不會亂猜 collection 名稱，壞處是你沒辦法在同一個 server 實例上操作多個 collection，要切換就得改環境變數重啟。
嵌入這一段由 fastembed 負責，README 說目前 EMBEDDING_PROVIDER 只支援 fastembed 一個值，預設模型是 sentence-transformers/all-MiniLM-L6-v2。也就是說，寫入與查詢兩邊的向量化都發生在這個 server 行程內，Qdrant 端只負責儲存與相似度檢索。這解釋了為什麼 uvx 一行指令就能跑：沒有外部嵌入 API 要設定。
啟動方式與真正需要調的環境變數
README 給的最小範例是 uvx 直接執行，不需要先安裝：
QDRANT_URL="http://localhost:6333" COLLECTION_NAME="my-collection" EMBEDDING_MODEL="sentence-transformers/all-MiniLM-L6-v2" uvx mcp-server-qdrant
唯一的命令列參數是 --transport，預設 stdio，可選 sse 與 streamable-http。stdio 只能給本機 MCP 客戶端用；sse 與 streamable-http 給遠端客戶端，其中 README 說 streamable-http 比 SSE 更新。走 SSE 時 server 會監聽指定埠，預設 8000，可用 FASTMCP_SERVER_PORT 改，例如 FASTMCP_SERVER_PORT=1234 搭配 --transport sse。
連線設定有兩個互斥選項：QDRANT_URL 指向遠端或本機的 Qdrant 服務，QDRANT_LOCAL_PATH 指向本機資料庫路徑。README 用一個 NOTE 明確寫出「You cannot provide both QDRANT_URL and QDRANT_LOCAL_PATH at the same time」。遠端實例另外需要 QDRANT_API_KEY。
其餘可調的鍵不多：QDRANT_SEARCH_LIMIT 控制搜尋回傳筆數，預設 10；QDRANT_READ_ONLY 設為 true 時會停用 qdrant-store 工具，只留查詢；TOOL_STORE_DESCRIPTION 與 TOOL_FIND_DESCRIPTION 讓你覆寫工具的說明文字，預設值放在 src/mcp_server_qdrant/settings.py。最後一組對實際使用影響不小：工具描述是模型決定要不要呼叫這個工具的依據，把它改寫成貼近你團隊語彙的說明，往往比調檢索參數更直接。
因為底層是 FastMCP，FASTMCP_LOG_LEVEL、FASTMCP_SERVER_DEBUG、FASTMCP_SERVER_HOST 等變數一併適用，衝突處理則由 FASTMCP_SERVER_ON_DUPLICATE_TOOLS 這類開關控制，可選 warn、error、replace、ignore，預設 warn。README 自己也提醒，FASTMCP_SERVER_ 這個前綴「may change in future versions」。
檢索品質幾乎全押在嵌入模型上
這是採用前最該想清楚的一點。從 README 可見的設定項來看，沒有任何參數能調整相似度度量、分數門檻、混合關鍵字檢索或 rerank。你能動的只有 EMBEDDING_MODEL 與 QDRANT_SEARCH_LIMIT。檢索結果好不好，取決於 all-MiniLM-L6-v2 這個小型模型對你語料的表現，以及 Qdrant collection 建立時使用的距離函數。
all-MiniLM-L6-v2 是輕量模型，換來的是啟動快、不需要 GPU，代價是對長文本與專業術語的語意分辨力有限。若你的記憶內容是簡短的決策紀錄或程式片段，這個取捨合理；若是整份規格文件，切塊策略與嵌入模型都會成為瓶頸，而這個 server 不負責切塊，你丟什麼它就存什麼。
另一個容易踩到的點是 collection 的建立時機。README 沒有描述 collection 不存在時的行為，因此第一次 store 之前是否必須先自行建立 collection、以及維度是否必須與 EMBEDDING_MODEL 相符，都無法從這份材料確認。實務上這是你部署前必須自己驗證的第一件事，因為嵌入維度與 collection 維度不一致會直接寫入失敗。
什麼時候不該用它
當你需要的是檢索品質調校，這個專案是錯的工具。它把 Qdrant 的能力收斂成兩個工具呼叫，換取的是模型端極低的認知負擔。你要 rerank、要 payload 過濾、要對 metadata 做結構化查詢，這些在 Qdrant 本身都做得到，但沒有對應的環境變數或工具參數能從 MCP 這一側觸發。metadata 雖然是 store 的輸入欄位，README 也只說明它會被儲存，沒有說 find 能不能用它過濾。
第二個邊界是多租戶。collection_name 在設定 COLLECTION_NAME 之後就從工具介面消失，代表一個 server 行程綁一個 collection。要服務多個專案，就得開多個行程、多組環境變數，並在 MCP 客戶端分別註冊。這不是缺陷，是刻意的簡化，但會影響你的部署拓撲。
第三，QDRANT_READ_ONLY 是唯一的權限開關，粒度只到「能不能寫」。它不能限制模型寫入哪個 collection，也不能限制寫入內容。若你的 Qdrant 裡同時放著不該被模型改動的資料，這個開關不夠細。
與直接寫 Qdrant 客戶端的差別
真正的替代方案不是另一個 MCP server，而是繞過 MCP，在你的應用程式裡直接用 qdrant-client。差別在控制權的位置：直接使用客戶端時，切塊、嵌入模型、檢索參數、rerank、payload 過濾全部由你的程式碼決定，你可以對同一個 Qdrant 實例做多 collection 路由，也能自建 API 層給多個前端共用。代價是你得自己處理 LLM 的工具呼叫協定，包含工具 schema、訊息格式與串流。
mcp-server-qdrant 把後面那一段做完了，而且做得很薄：兩個工具、一組環境變數、一個 --transport 參數。它適合的是「我現在就想讓 IDE 裡的模型記住東西」這種即時需求，而不是「我要打造一套檢索產品」。兩者的分界線大致就是：你需要為檢索結果負責到什麼程度。需要調校就自己寫，只需要一個可用的記憶抽屜就用這個。
順帶一提，README 開頭自稱「This repository is an example of how to create a MCP server for Qdrant」。這個自我定位值得記住：它同時是可用工具，也是 MCP server 的參考實作。如果你的目標是後者，src/mcp_server_qdrant/settings.py 與工具註冊的寫法比它的功能清單更值得讀。
授權、版本節奏與升級成本
授權是 Apache-2.0，寬鬆授權，允許修改與再散布，包含商業用途。這裡只描述授權條款本身，不構成法律意見；若你要把它包進產品或修改後再散布，條款中的專利授權與聲明保留要求應由法務確認。
版本節奏從釋出紀錄看得出不平均：v0.7.1 在 2025 年 3 月，v0.8.0 在 2025 年 6 月，v0.8.1 在 2025 年 12 月。三個版本都還在 0.x，README 也自己標註 FASTMCP_SERVER_ 前綴可能變動。這代表升級時要預期設定鍵有被改名的可能，尤其當你依賴那些 FastMCP 層的變數。
升級成本主要落在兩處。一是環境變數：若你只用了 QDRANT_URL、COLLECTION_NAME、EMBEDDING_MODEL 這幾個核心鍵，改動風險低；一旦用了 TOOL_STORE_DESCRIPTION 這類覆寫，就得回頭核對 settings.py 的預設值是否調整。二是嵌入模型：換 EMBEDDING_MODEL 等於換向量空間，既有 collection 的資料無法沿用，必須重新嵌入並重建 collection。這個成本不會因為它是 0.x 版本而消失，它來自向量檢索的本質。
部署上還有一件事要記得：走 stdio 時 server 由 MCP 客戶端啟動與終止，走 sse 或 streamable-http 時它是一個長駐行程，得自己管埠與生命週期。兩種模式的運維負擔不同，切換前先想清楚。
編輯結論
如果你要的是讓 Claude、Cursor 這類 MCP 客戶端記住跨對話的片段，而且能接受預設的 all-MiniLM-L6-v2 嵌入與不可調的檢索參數，這個 server 用 uvx 就能跑起來，設定成本極低。若你的場景需要 rerank、混合檢索、多向量或自訂距離度量，這個 repo 沒有對應的環境變數可調，應該直接寫 Qdrant 客戶端而不經過 MCP。採用前先確認三件事：QDRANT_URL 與 QDRANT_LOCAL_PATH 只能擇一、COLLECTION_NAME 是否設定（它決定 collection_name 參數是否出現在工具介面中）、以及 QDRANT_READ_ONLY 是否符合你的寫入政策。
社群筆記