mcp-server-qdrant : une mémoire sémantique branchée sur MCP

Deux outils, pas un framework de recherche

Le README est explicite : ce dépôt est un exemple de serveur MCP pour Qdrant, un moteur de recherche vectorielle. Le projet se présente comme une couche de mémoire sémantique posée au-dessus de la base. Concrètement, il expose deux outils. qdrant-store enregistre une chaîne information, éventuellement accompagnée d'un objet metadata au format JSON. qdrant-find prend une requête en langage naturel et renvoie les informations stockées sous forme de messages séparés. C'est tout. Il n'y a pas d'outil de suppression, pas d'outil de mise à jour, pas d'outil de listage des collections. Le public visé est donc précis : quelqu'un qui utilise déjà un client compatible MCP (les topics du dépôt mentionnent Claude, Cursor et Windsurf) et qui veut que son assistant se souvienne de faits d'une session à l'autre, sans écrire de code d'intégration. Si votre besoin est de construire un pipeline de recherche documentaire avec filtrage par métadonnées, découpage de fichiers et reranking, vous êtes au mauvais endroit : ces briques ne figurent pas dans l'interface décrite.

Le trajet d'une information, de l'appel d'outil à la collection

Le flux est linéaire. Un client MCP appelle qdrant-store avec un texte. Le serveur calcule un vecteur via le fournisseur d'embeddings configuré, puis écrit le point correspondant dans une collection Qdrant. Lors d'un qdrant-find, le même fournisseur vectorise la requête, la recherche s'exécute dans la collection, et les résultats remontent au client sous forme de messages distincts. Deux paramètres d'entrée méritent attention. D'abord collection_name : le README précise qu'il est obligatoire s'il n'existe pas de nom de collection par défaut, et qu'il est désactivé dans le cas contraire. Autrement dit, définir COLLECTION_NAME change la signature visible de l'outil pour le modèle. Ensuite QDRANT_SEARCH_LIMIT, qui plafonne le nombre de résultats renvoyés et vaut 10 par défaut. Ce plafond compte : chaque résultat renvoyé consomme du contexte dans la fenêtre du modèle appelant. Un plafond à 10 est un compromis raisonnable pour de la mémoire conversationnelle, moins pour de la recherche exploratoire. Le mode lecture seule existe aussi : QDRANT_READ_ONLY, à false par défaut, désactive purement et simplement l'outil qdrant-store.

Installation : uvx, variables d'environnement et rien d'autre

La documentation indique que uvx permet de lancer le serveur sans installation préalable. L'exemple du README est celui-ci : QDRANT_URL="http://localhost:6333", COLLECTION_NAME="my-collection", EMBEDDING_MODEL="sentence-transformers/all-MiniLM-L6-v2", puis uvx mcp-server-qdrant. Le serveur accepte un unique argument en ligne de commande, --transport, avec trois valeurs possibles. stdio est la valeur par défaut et ne convient qu'aux clients MCP locaux. sse ouvre un port et attend les connexions entrantes, ce qui vise les clients distants. streamable-http remplit le même rôle avec un protocole plus récent. Le port par défaut est 8000 et se change avec FASTMCP_SERVER_PORT, comme le montre l'exemple qui fixe FASTMCP_SERVER_PORT=1234 avec --transport sse. Côté stockage, deux voies s'excluent : QDRANT_URL pour un serveur, QDRANT_LOCAL_PATH pour une base locale. Le README signale dans une note que fournir les deux en même temps n'est pas permis. C'est une contrainte à garder en tête si vous migrez d'un déploiement local vers un cluster. Enfin, le projet reposant sur FastMCP, il hérite des variables FASTMCP_SERVER_* : niveau de log, mode debug, hôte, port, et comportement en cas de doublon de ressources, d'outils ou de prompts, avec warn comme valeur par défaut. La documentation prévient elle-même que ce préfixe pourrait changer dans de futures versions.

Fastembed seul, et ce que cela impose

La variable EMBEDDING_PROVIDER n'accepte aujourd'hui que la valeur fastembed, et le README le dit sans détour. Le modèle par défaut est sentence-transformers/all-MiniLM-L6-v2. Ce point est la limite la plus structurante du projet. Vous ne pouvez pas brancher l'API d'embeddings d'un fournisseur externe via une variable d'environnement, ni choisir un modèle multilingue lourd sans passer par la configuration de fastembed. Pour un usage en français, all-MiniLM-L6-v2 n'est pas le choix évident, et le dépôt ne fournit pas de tableau comparatif pour vous aider à trancher. Il faut donc tester soi-même la qualité de rappel sur ses propres contenus avant de généraliser le déploiement. Autre conséquence : le calcul des vecteurs se fait dans le processus du serveur, ce qui déplace la charge de calcul côté client MCP plutôt que côté Qdrant. Sur un poste de développeur c'est indolore. Sur un serveur partagé qui sert plusieurs sessions, cela devient un paramètre de dimensionnement à part entière.

Les cas où ce serveur n'est pas le bon outil

Trois situations le disqualifient assez vite. La première est la recherche documentaire sur corpus hétérogène. Les outils acceptent du texte brut et un objet metadata libre, mais rien dans l'interface décrite ne permet de filtrer une recherche sur ce metadata. Vous stockez des métadonnées que vous ne pouvez pas interroger via MCP. La deuxième est la gestion de contenu : sans outil de suppression ni de mise à jour, une information erronée enregistrée par le modèle reste dans la collection. Le seul recours est d'agir directement sur Qdrant, en dehors du serveur MCP. La troisième concerne la sécurité. Le serveur ne décrit aucun contrôle d'accès propre : la protection repose sur QDRANT_API_KEY côté Qdrant et sur le transport choisi. En stdio, le serveur tourne en local et le problème est circonscrit. En sse ou en streamable-http, vous exposez un port. Le README ne documente pas de mécanisme d'authentification des clients MCP sur ce port, et c'est un point à vérifier avant toute exposition réseau. Le mode QDRANT_READ_ONLY limite les dégâts en supprimant l'écriture, ce qui reste la parade la plus simple pour une instance partagée.

MCP face à une intégration directe du client Qdrant

L'alternative la plus directe n'est pas un autre serveur MCP, c'est le client Qdrant utilisé directement dans votre application. La différence tient au contrat d'interface. Avec le client, vous contrôlez le schéma de collection, les index de payload, le choix du modèle d'embedding, le découpage des documents et la stratégie de filtrage. Vous écrivez du code, mais vous décidez de tout. Avec mcp-server-qdrant, le contrat est fixé à deux outils et à un ensemble de variables d'environnement. Vous gagnez l'intégration immédiate avec n'importe quel client MCP, sans écrire une ligne, et vous perdez la main sur tout ce qui n'est pas exposé. Le projet se présente d'ailleurs comme un exemple, ce qui situe honnêtement son ambition. Un choix intermédiaire consiste à reprendre le dépôt et à ajouter vos propres outils, puisque la licence Apache-2.0 le permet. C'est probablement la trajectoire naturelle si vous butez sur l'absence de filtrage ou de suppression.

Maintenance, versions et licence

Le dépôt n'est pas archivé et la dernière publication en date est v0.8.1, en décembre 2025, après v0.8.0 en juin 2025 et v0.7.1 en mars 2025. Le rythme observé sur ces trois versions est irrégulier, avec un écart de plusieurs mois entre chacune. Ce n'est pas un signal d'abandon, mais cela invite à ne pas compter sur des correctifs rapides. Le coût de mise à jour est faible en apparence : la configuration passe par des variables d'environnement et un seul argument de ligne de commande, donc changer de version se limite souvent à modifier un tag dans la commande uvx. Deux réserves cependant. La documentation signale que le préfixe FASTMCP_SERVER_ pourrait évoluer, ce qui toucherait vos réglages de port, d'hôte et de gestion des doublons. Et la montée de version de fastembed ou du modèle par défaut peut modifier les vecteurs produits, donc la qualité du rappel sur une collection existante. Sur la licence, Apache-2.0 autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et d'état des modifications. Ce paragraphe décrit la licence telle qu'identifiée dans le dépôt et ne constitue pas un avis juridique.

Conclusion éditoriale

Adoptez mcp-server-qdrant si vous voulez une mémoire partagée entre plusieurs clients MCP et que vous acceptez d'exploiter vous-même le Qdrant sous-jacent. Passez votre chemin si vous cherchez une recherche documentaire riche : il n'y a ni reranking, ni filtrage, ni ingestion de fichiers, et EMBEDDING_PROVIDER n'accepte que fastembed. Avant de vous engager, vérifiez trois choses concrètes : que votre client MCP sait lancer une commande uvx, que la variable COLLECTION_NAME est bien définie pour éviter que collection_name devienne un paramètre obligatoire à chaque appel, et que le modèle par défaut sentence-transformers/all-MiniLM-L6-v2 correspond à la langue de vos contenus.

Sources officielles

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