mcp-server-qdrant を採用する前に読む: 2つのツールと環境変数だけで動く意味記憶レイヤー
An official Qdrant Model Context Protocol (MCP) server implementation
ひと目でわかる
- これは何？
- Qdrant 公式の MCP サーバーが何を解決し、どこで破綻するのかを、README に書かれている範囲だけで整理する。ツールは2つ、設定は環境変数、埋め込みは fastembed 固定という構成の帰結を追う。
- 誰に向いている？
- すでに Qdrant を運用していて、LLM クライアントから記憶を読み書きさせたいチームには向く。逆に、埋め込みモデルを自前で管理している、複数コレクションを動的に切り替えたい、書き込みを監査したいといった要件がある場合は、このサーバーが提供する2つのツールでは足りない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 12 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
このサーバーが埋めるのは「記憶」という1つの隙間だけ
MCP は LLM アプリケーションと外部データソースをつなぐためのプロトコルだと README は説明している。mcp-server-qdrant はそのプロトコルに乗るサーバーの1つで、役割は「Qdrant の上に意味記憶レイヤーを載せること」だと明記されている。ここで扱う記憶とは、会話の履歴やドキュメント全体ではなく、任意のテキスト片をベクトル化して保存し、後から意味的に近いものを引き出す操作を指す。
対象読者は、Claude、Cursor、Windsurf といった MCP 対応クライアントを使っていて、セッションをまたいで知識を持ち越したい人だ。トピックに claude、cursor、llm、windsurf が並んでいるのはそのためで、サーバー自体を自作する層ではなく、既存クライアントに外部記憶を差し込みたい層を想定している。
注意したいのは、README 自身がこのリポジトリを「Qdrant 用の MCP サーバーを作る例」と表現している点だ。汎用の記憶基盤というより、Qdrant を MCP に接続する最小構成のリファレンス実装という性格が強い。
qdrant-store と qdrant-find の2ツールしか公開しない設計
サーバーが公開するツールは2つだけだと README に列挙されている。1つは qdrant-store で、information（文字列）、metadata（JSON、任意）、collection_name（文字列）を入力に取り、確認メッセージを返す。もう1つは qdrant-find で、query（文字列）と collection_name を入力に取り、保存された情報を個別のメッセージとして返す。
ここに1つ、見落としやすい挙動がある。collection_name は「デフォルトのコレクション名が設定されていない場合に必須」であり、デフォルトが設定されている場合は「このフィールドは有効にならない」と書かれている。つまり COLLECTION_NAME 環境変数を設定した瞬間、LLM 側からコレクションを選ぶ手段が消える。用途別にコレクションを分けたいなら、この変数を設定せずクライアントに毎回指定させるという選択になる。
削除や更新のツールは用意されていない。保存した情報を訂正する手段は README の範囲では示されておらず、書き込みが一方向に積み上がる前提で設計されている。
埋め込みは fastembed 固定、モデルだけ差し替えられる
EMBEDDING_PROVIDER は「現在 fastembed のみサポート」と表に明記されている。OpenAI や Cohere の埋め込み API に切り替える口は現時点で用意されていない。差し替えられるのは EMBEDDING_MODEL で、デフォルトは sentence-transformers/all-MiniLM-L6-v2 だ。
この制約は運用に直接効いてくる。埋め込みはサーバープロセス側で計算されるため、外部 API のレイテンシや課金は発生しない代わりに、モデルのダウンロードと推論が動くマシンのリソースを消費する。すでに別のモデルで Qdrant にベクトルを投入している場合、このサーバーが使うモデルと次元数やベクトル空間が一致していなければ、同じコレクションに混ぜることはできない。README はこの点に触れていないので、既存コレクションへの接続を検討するなら自分で確認する必要がある。
EMBEDDING_MODEL のデフォルトが all-MiniLM-L6-v2 であることは、多言語の記憶を扱う場合に効いてくる。日本語のテキストを保存して日本語で検索する用途でこのモデルが十分かを判断する材料は README にはない。
起動は uvx 1行、接続先は URL かローカルパスの二者択一
インストール不要で走らせる方法として README が示すのは uvx だ。QDRANT_URL、COLLECTION_NAME、EMBEDDING_MODEL を環境変数で与えて uvx mcp-server-qdrant を実行する。
接続先には2つの選択肢がある。QDRANT_URL でサーバーを指すか、QDRANT_LOCAL_PATH でローカルのデータベースパスを指すかだ。README の注記は「QDRANT_URL と QDRANT_LOCAL_PATH を同時に指定することはできない」と明言している。両方書いてしまうと起動しない。QDRANT_API_KEY は Qdrant サーバー側の認証用で、ローカルパス運用では不要になる。
コマンドライン引数は --transport だけだと README は述べている。設定のすべてが環境変数側に寄っている。
トランスポートは3種類ある。stdio がデフォルトで、ローカルの MCP クライアントからのみ使える。sse と streamable-http はリモートクライアント向けで、streamable-http のほうが新しい。SSE を使う場合、サーバーはポートで待ち受け、デフォルトは 8000、FASTMCP_SERVER_PORT で変更できる。README の例では FASTMCP_SERVER_PORT=1234 と --transport sse を組み合わせている。
QDRANT_READ_ONLY は書き込みを止めるが、読み取り範囲は絞らない
QDRANT_READ_ONLY を true にすると qdrant-store ツールが無効化される、と表に書かれている。読み取り専用のクライアントに記憶を参照させるだけなら、この1つの変数で書き込み経路を塞げる。
ただし、これが防ぐのは「このサーバー経由の書き込み」だけだ。同じコレクションに別の経路で書き込むプロセスがあれば、そちらには何の影響もない。また、qdrant-find の検索対象を絞る設定は README には見当たらない。QDRANT_SEARCH_LIMIT は返す件数の上限を決める（デフォルト10）だけで、どのコレクションを見るか、どの metadata を持つ情報だけを返すかといった制御は用意されていない。
複数テナントの記憶を1つのコレクションに同居させ、テナントごとに見える範囲を変えたい、という要件はこのサーバーの守備範囲外だ。metadata は保存できるが、README はそれをフィルタ条件として使う手段を説明していない。
ツール説明文を書き換えられることが、実務では一番効く
TOOL_STORE_DESCRIPTION と TOOL_FIND_DESCRIPTION で、各ツールの説明文を差し替えられる。デフォルトは settings.py にあると README は案内している。
MCP クライアントはツールの説明文を読んで、いつそのツールを呼ぶかを決める。つまりこの2つの変数は、LLM に対するプロンプトの一部を差し替えるのと同じ効果を持つ。「ユーザーが明示的に覚えてと指示したときだけ保存する」「検索は必ず保存より先に試す」といった運用ルールを、クライアント側の設定ではなくサーバー側の説明文に埋め込める。
逆に言えば、説明文を放置すると、デフォルトの文言がそのまま呼び出し判断の基準になる。保存すべきでない雑談が次々とコレクションに入る、といった挙動が起きたとき、最初に見るべきはこの2つの変数だ。README はデフォルト文面そのものを本文には載せていないので、実際の文言は settings.py を読む必要がある。
FastMCP 由来の設定群と、将来変わりうるという但し書き
このサーバーは FastMCP をベースにしているため、FastMCP の環境変数もそのまま使える。README が重要として挙げるのは、FASTMCP_LOG_LEVEL（デフォルト INFO）、FASTMCP_SERVER_DEBUG、FASTMCP_SERVER_HOST（デフォルト 127.0.0.1）、FASTMCP_SERVER_PORT（デフォルト 8000）、そして重複時の挙動を決める FASTMCP_SERVER_ON_DUPLICATE_RESOURCES、FASTMCP_SERVER_ON_DUPLICATE_TOOLS、FASTMCP_SERVER_ON_DUPLICATE_PROMPTS（いずれも warn、ほかに error、replace、ignore）だ。
FASTMCP_SERVER_HOST のデフォルトが 127.0.0.1 である点は、SSE や streamable-http で外部から接続させたいときに必ず引っかかる。リモートクライアント向けのトランスポートを選んでも、バインド先を変えなければローカルからしか届かない。
README は「サーバー固有の設定は FASTMCP_SERVER_ 接頭辞を使う。これは将来のバージョンで変わる可能性がある」と注記している。設定名が固定されたインターフェースとして扱われているわけではない。バージョン間で環境変数名が動く前提で、デプロイ手順をバージョンと一緒に記録しておくほうが安全だ。
代替として Qdrant を直接叩く構成と比べたときの差
同じことを実現する別の方法は、Qdrant のクライアントライブラリを自分のアプリケーションに組み込み、検索と投入のロジックを自分で書くことだ。この場合、埋め込みモデルの選択、コレクション設計、metadata によるフィルタ、削除や更新の扱いをすべて自分で決められる。mcp-server-qdrant が固定している部分（fastembed のみ、2ツール、削除なし）は、すべて可変になる。
代わりに失うのは、MCP クライアントとの接続部分だ。stdio、sse、streamable-http の3トランスポートへの対応、ツール定義の公開、クライアントごとの接続設定を自前で用意することになる。mcp-server-qdrant の価値は、この接続部分と Qdrant の接続部分を、環境変数だけで埋め合わせてくれる点に集約されている。
判断の分かれ目は、記憶の操作をどれだけ細かく制御したいかだ。保存と検索の2操作で足りるなら前者、フィルタや削除や複数モデルの併用が要るなら後者になる。中間として、このサーバーをフォークして tools を追加する道もある。Apache-2.0 なので、その選択はライセンス上ふさがれていない。
ライセンスとメンテナンスの見取り図
ライセンスは Apache-2.0 で、リポジトリはアーカイブされていない。フォークしてツールを追加する、社内用に説明文だけ差し替えて再配布する、といった使い方はこのライセンスの下で可能だ。ただし Apache-2.0 が求める表示や変更点の明示といった条件の解釈は個別の状況によるので、配布する場合は法務に確認してほしい。ここでは法的助言はしない。
更新の頻度は README からは判断できない。手元の材料で確認できるのは v0.8.1 が 2025-12-10、v0.8.0 が 2025-06-27、v0.7.1 が 2025-03-11 という日付だけだ。リリース間隔が一定であるとは言えない。
バージョンを固定して使う場合、注意すべきは FastMCP 側の設定名が変わりうると README が明記している点だ。サーバー本体のバージョンだけでなく、依存する FastMCP のバージョンも固定しないと、FASTMCP_SERVER_ 接頭辞の変数が黙って無視される可能性がある。
編集部の結論
すでに Qdrant を運用していて、LLM クライアントから記憶を読み書きさせたいチームには向く。逆に、埋め込みモデルを自前で管理している、複数コレクションを動的に切り替えたい、書き込みを監査したいといった要件がある場合は、このサーバーが提供する2つのツールでは足りない。導入前に確認すべきは QDRANT_URL と QDRANT_LOCAL_PATH が排他である点、COLLECTION_NAME を設定するとツールの引数から collection_name が消える点、そして QDRANT_READ_ONLY=true が qdrant-store を無効化するだけで qdrant-find の検索範囲を絞らない点である。
コミュニティノート