mcp-server-qdrant: semantisches Gedächtnis für MCP-Clients

Zwei Tools statt einer Suchmaschine

Der Server löst ein eng umrissenes Problem: Ein LLM-Client soll sich Textbausteine merken und sie später semantisch wiederfinden können. Dafür stellt das Repository genau zwei Tools bereit. qdrant-store nimmt einen String information, optionale Metadaten als JSON und einen Sammlungsnamen entgegen. qdrant-find nimmt eine Query und einen Sammlungsnamen und liefert die gespeicherten Informationen als einzelne Nachrichten zurück. Das ist die gesamte Oberfläche. Wer Volltextsuche, Filter über Metadatenfelder oder hybride Rankingverfahren erwartet, wird hier nicht fündig; das README beschreibt ausschließlich diese beiden Werkzeuge. Zielgruppe sind Anwender von MCP-Clients, die eine eigene Qdrant-Instanz betreiben und ihr Kontextgedächtnis nicht einem fremden Dienst überlassen wollen. Der Server ist ausdrücklich als Beispiel dafür dokumentiert, wie man einen MCP-Server für Qdrant baut, und wird als offizielle Implementierung geführt.

Vom Text zur Vektordatenbank

Der Datenfluss ist einfach und lässt sich aus der Konfiguration ableiten. Beim Aufruf von qdrant-store wandelt der Server den Text über den konfigurierten Embedding-Anbieter in einen Vektor um und schreibt ihn zusammen mit den Metadaten in die angegebene Sammlung. Beim Aufruf von qdrant-find wird dieselbe Einbettung auf die Query angewendet, die Ähnlichkeitssuche in Qdrant ausgeführt und die Trefferliste als Nachrichten zurückgegeben. Die Anzahl der zurückgegebenen Treffer steuert QDRANT_SEARCH_LIMIT, dessen Standardwert 10 ist. Als Embedding-Anbieter ist laut Tabelle derzeit nur fastembed vorgesehen, das Standardmodell ist sentence-transformers/all-MiniLM-L6-v2. Das bedeutet: Die Qualität des Gedächtnisses hängt direkt an diesem Modell, und ein Wechsel ist an die Unterstützung durch fastembed gebunden. Wer ein anderes Modell braucht, muss prüfen, ob es sich über EMBEDDING_MODEL überhaupt laden lässt.

Installation ohne Projektabhängigkeit

Das README zeigt den Start über uvx, sodass keine lokale Installation nötig ist. Das Beispiel setzt QDRANT_URL, COLLECTION_NAME und EMBEDDING_MODEL und ruft uvx mcp-server-qdrant auf. Für einen lokalen Betrieb ohne Server nennt die Tabelle QDRANT_LOCAL_PATH als Alternative zu QDRANT_URL. Beide gleichzeitig zu setzen ist ausdrücklich nicht erlaubt, das README markiert das in einem Hinweis. Ein API-Schlüssel für einen entfernten Qdrant-Dienst kommt über QDRANT_API_KEY dazu. Ist COLLECTION_NAME gesetzt, wird das Feld collection_name in den Tool-Aufrufen deaktiviert; ohne Standardnamen muss der Client die Sammlung bei jedem Aufruf mitgeben. Das ist eine bewusste Einschränkung, die verhindert, dass ein Modell versehentlich in der falschen Sammlung schreibt, aber sie zwingt den Client, den Namen konsistent zu übergeben. Die Beschreibungen der beiden Tools lassen sich über TOOL_STORE_DESCRIPTION und TOOL_FIND_DESCRIPTION überschreiben, was dann relevant wird, wenn ein Client die Tool-Auswahl anhand dieser Texte trifft.

Transport: stdio, sse oder streamable-http

Das einzige Kommandozeilenargument ist --transport. Ohne Angabe läuft der Server über stdio, was laut README nur von lokalen MCP-Clients genutzt werden kann. Für entfernte Clients stehen sse und streamable-http zur Verfügung, wobei streamable-http als neueres Verfahren bezeichnet wird. Im SSE-Betrieb lauscht der Server auf einem Port, standardmäßig 8000, änderbar über FASTMCP_SERVER_PORT. Das Beispiel im README setzt den Port auf 1234 und startet mit --transport sse. Hier liegt eine praktische Hürde: Ein Server, der auf einem Port lauscht, braucht eine Entscheidung über Erreichbarkeit und Absicherung, die das README nicht trifft. Wer den SSE-Transport wählt, sollte wissen, dass die Konfiguration dann nicht mehr allein in der Umgebung des Clients liegt. Für einen einzelnen Entwicklerarbeitsplatz ist stdio der einfachere Weg.

Schreibzugriff abschalten statt Rechte verwalten

QDRANT_READ_ONLY deaktiviert das Tool qdrant-store, der Standardwert ist false. Das ist die einzige im README dokumentierte Möglichkeit, den Schreibzugriff einzuschränken, und sie wirkt auf Werkzeugebene, nicht auf Datenbankebene. Ein Client mit Lesezugriff kann also weiterhin über qdrant-find suchen, aber nichts ablegen. Für Szenarien, in denen ein Modell nur nachschlagen soll, ist das ausreichend. Es ersetzt jedoch keine Zugriffskontrolle auf der Qdrant-Seite: Wer den Server mit einem API-Schlüssel startet, der Schreibrechte besitzt, verlässt sich allein auf die Tool-Deaktivierung. Das ist eine Designentscheidung, die man kennen sollte, bevor man den Server in eine geteilte Umgebung stellt. Eine granulare Trennung nach Sammlungen bietet der Schalter nicht.

FastMCP als Fundament und seine Nebenwirkungen

Der Server baut auf FastMCP und übernimmt dessen Umgebungsvariablen. Dazu gehören FASTMCP_LOG_LEVEL mit dem Standard INFO, FASTMCP_SERVER_DEBUG, FASTMCP_SERVER_HOST mit 127.0.0.1 und die drei Variablen für doppelte Ressourcen, Tools und Prompts, die jeweils auf warn stehen. Diese letzte Gruppe ist für Erweiterungen relevant: Wer den Server um eigene Tools ergänzt, kann über FASTMCP_SERVER_ON_DUPLICATE_TOOLS festlegen, ob ein Namenskonflikt eine Warnung, einen Fehler, eine Ersetzung oder ein Ignorieren auslöst. Das README weist darauf hin, dass serverspezifische Einstellungen das Präfix FASTMCP_SERVER_ verwenden und dass sich das in künftigen Versionen ändern kann. Wer diese Variablen in einer Deployment-Konfiguration festschreibt, sollte diesen Hinweis ernst nehmen. FASTMCP_SERVER_DEPENDENCIES erlaubt es, Abhängigkeiten in der Serverumgebung zu installieren, was für angepasste Embedding-Modelle oder zusätzliche Bibliotheken gedacht sein dürfte.

Wann ein anderer Ansatz sinnvoller ist

Der Server ist kein Ersatz für eine vollständige Suchanwendung. Wer Dokumente chunkweise indexiert, Metadatenfilter kombinieren oder mehrere Einbettungsmodelle gegeneinander testen will, arbeitet direkt mit dem Qdrant-Client besser, weil die MCP-Schnittstelle nur zwei Operationen freigibt. Auch für Anwendungen, die eine verwaltete Vektordatenbank ohne eigenen Betrieb bevorzugen, ist der Ansatz falsch: Der Server setzt auf QDRANT_URL oder QDRANT_LOCAL_PATH, also auf eine Instanz, die der Betreiber selbst bereitstellt. Ein weiterer Unterschied liegt im Umfang der Konfiguration. Andere MCP-Server für Vektordatenbanken erlauben häufig die Wahl zwischen mehreren Embedding-Anbietern oder bringen eigene Chunking-Strategien mit. Hier ist EMBEDDING_PROVIDER laut Tabelle auf fastembed festgelegt, und Chunking kommt im README nicht vor. Wer lange Dokumente ablegt, muss selbst entscheiden, wie er sie zerlegt, weil der Server den Text als Ganzes einbettet.

Pflege, Lizenz und was vor dem Einsatz zu klären ist

Das Repository steht unter Apache-2.0, einer permissiven Lizenz, die kommerzielle Nutzung und Änderungen erlaubt und eine Patentgewährung enthält. Wer den Code forkt und anpasst, muss die Lizenzbedingungen einhalten, also Lizenz- und Urheberrechtshinweise beibehalten und Änderungen kennzeichnen. Das ist keine Rechtsberatung, sondern nur der Hinweis, dass die Lizenzangabe im Repository zu prüfen ist, bevor der Code in ein Produkt eingebettet wird. Die Release-Historie zeigt Versionen v0.7.1, v0.8.0 und v0.8.1, wobei die Abstände zwischen den Veröffentlichungen unregelmäßig sind. Der letzte Push liegt laut Repository-Angaben im September 2026, die letzte Version stammt aus Dezember 2025. Daraus lässt sich keine Aussage über die zukünftige Pflegeintensität ableiten; wer den Server produktiv einsetzt, sollte die Abhängigkeit von fastembed und dem Standardmodell im Auge behalten, weil ein Modellwechsel die bestehenden Vektoren in der Sammlung ungültig macht. Vor dem Einsatz ist konkret zu prüfen, welcher Transport zum Client passt, ob QDRANT_READ_ONLY gesetzt werden soll und ob COLLECTION_NAME fest vorgegeben wird oder der Client den Namen bei jedem Aufruf liefern muss.

Redaktionelles Fazit

Wer einen MCP-fähigen Client wie Claude, Cursor oder Windsurf mit einer eigenen Qdrant-Instanz verbinden will und die Konfiguration über Umgebungsvariablen akzeptiert, findet hier einen schlanken, offiziell gepflegten Server mit Apache-2.0-Lizenz. Wer eine verwaltete Lösung ohne eigenen Qdrant-Betrieb sucht oder mehrere Embedding-Anbieter kombinieren muss, sollte zuerst prüfen, ob EMBEDDING_PROVIDER ausschließlich fastembed unterstützt und ob der gewählte Transport zum Client passt. Vor dem Produktiveinsatz ist zu klären, ob QDRANT_READ_ONLY aktiviert werden soll und ob der Standardwert von QDRANT_SEARCH_LIMIT von 10 für die eigene Sammlung ausreicht.

Offizielle Quellen

1. License: Apache-2.0
2. Project website
3. qdrant/mcp-server-qdrant on GitHub
4. README
5. Releases