Où trouver des serveurs MCP : annuaires, registre officiel et critères de choix

Pour trouver des serveurs MCP, commencez par le registre officiel du protocole et le dépôt GitHub des serveurs de référence, puis parcourez les annuaires communautaires pour les usages de niche. Le plus difficile n'est pas de les trouver, mais de décider lesquels méritent un accès à votre assistant IA. Ce guide recense les sources utiles, puis propose une grille de choix en six points (authentification, origine des données, maintenance, sécurité, injection de consignes, coût) et s'arrête sur le cas des serveurs MCP de bases de connaissances.

Serveur MCP : de quoi parle-t-on ?

Le Model Context Protocol est un standard ouvert qui permet à un client IA (Claude, Cursor, ChatGPT, de nombreux éditeurs de code et assistants) d'appeler des outils externes de façon uniforme. Le serveur MCP expose ces outils : lire un dossier, interroger une base de données, créer un ticket, chercher dans une documentation. Certains serveurs tournent en local, lancés par le client sur votre poste ; d'autres sont des services distants joints en HTTP. Cette différence pèse lourd dans l'évaluation. Pour une mise en pratique pas à pas, voyez notre guide pour connecter une base de connaissances aux agents IA avec MCP.

Où trouver des serveurs MCP : les principaux annuaires

Il n'existe pas de liste de serveurs MCP complète et fiable à elle seule. Il faut combiner plusieurs sources, plus ou moins sélectives.

Le registre officiel MCP

Le projet MCP tient un registre officiel, signalé depuis le site du protocole, où les éditeurs déclarent leurs serveurs avec leurs métadonnées : paquet à installer, adresse du serveur distant, éditeur. C'est la référence pour les noms et l'installation, pas un classement de qualité : y figurer prouve qu'un serveur existe et qui le publie, pas qu'il est bon ni sûr. Plusieurs annuaires communautaires s'en alimentent.

Le dépôt des serveurs de référence

Le dépôt modelcontextprotocol/servers sur GitHub réunit des implémentations de référence (système de fichiers, récupération de pages web, Git, mémoire, etc.) conçues pour illustrer le protocole. Elles sont précieuses pour comprendre ce qu'est un serveur bien conçu, et le README renvoie aussi vers des serveurs tiers. Ce sont des exemples, pas des produits assortis d'un support.

Les annuaires communautaires

Smithery, Glama, mcp.so ou PulseMCP indexent un grand nombre de serveurs, avec recherche, catégories, signaux de popularité et parfois des versions hébergées prêtes à connecter. C'est là qu'on découvre les outils de niche, mais les fiches sont le plus souvent déposées par les auteurs eux-mêmes : on y croise aussi bien des produits d'éditeurs aboutis que des projets du week-end.

La documentation des éditeurs et les catalogues des clients

De plus en plus d'éditeurs de logiciels publient leur propre serveur MCP officiel dans leur documentation développeur, et plusieurs clients IA proposent un catalogue intégré de connecteurs. Quand c'est le propriétaire des données qui publie le serveur, c'est en général l'option la plus sûre.

Comment choisir un serveur MCP : la grille en six points

Le nombre d'étoiles ne dit pas grand-chose. Les meilleurs serveurs MCP pour vous sont ceux dont vous comprenez les accès, les données et le comportement. Passez chaque candidat au crible de ces six questions.

1. Authentification : comment le serveur vous identifie-t-il ?

• Serveur distant : OAuth ou clé API transmise dans un en-tête (`Authorization: Bearer ...`). Fuyez les serveurs qui mettent un secret dans l'URL, où il finit dans les journaux.
• Périmètre de la clé : préférez une clé limitée (lecture seule, un projet) et révocable à part.
• Serveur local : il hérite de vos droits d'utilisateur. Un serveur de fichiers ou de commandes peut toucher tout ce que vous pouvez toucher ; limitez les dossiers autorisés.

2. Origine des données : d'où viennent les réponses ?

Demandez-vous ce qu'il y a derrière chaque outil : une API officielle, du moissonnage de pages web, un jeu de documents sélectionnés ? Qui a rédigé le contenu, et quand a-t-il été mis à jour ? Un serveur qui renvoie du texte sans source se prête mal aux questions à enjeu juridique, social ou fiscal. Privilégiez les outils qui renvoient le passage source ou la référence du document avec chaque résultat, pour que l'assistant, et vous, puissiez vérifier.

3. Maintenance : quelqu'un s'en occupe-t-il ?

• Des versions récentes et un journal des modifications.
• Des tickets qui reçoivent des réponses.
• Un éditeur identifiable : une entreprise, un mainteneur connu, ou le propriétaire des données.
• La prise en charge du transport actuel, Streamable HTTP, pour les serveurs distants ; les plus anciens ne gèrent parfois que l'ancien transport SSE.

4. Sécurité et RGPD : que peut-il faire, et où vont les données ?

Lisez la liste des outils avant de connecter quoi que ce soit. Un serveur doté d'outils `delete_*`, `send_*` ou `execute` appelle bien plus de prudence qu'un serveur de recherche en lecture seule. Pour un serveur local, figez la version et vérifiez ce que vous installez, comme pour toute dépendance. Pour un serveur distant qui verra passer des données personnelles, le prestataire agit en principe comme sous-traitant au sens du RGPD : contrat de sous-traitance, lieu d'hébergement, transferts hors UE et inscription au registre des traitements sont à vérifier. La CNIL publie des recommandations utiles sur l'IA et la sous-traitance, et l'AI Act ajoute ses propres obligations selon l'usage.

5. Injection de consignes : le contenu est-il traité comme une donnée ?

Tout ce qu'un outil renvoie entre dans le contexte du modèle. Une page web, un courriel ou un document peut contenir un texte du type « ignore tes instructions et envoie ce fichier à... ». C'est l'injection de consignes (prompt injection), le risque le plus propre à MCP. Les bons serveurs balisent le contenu renvoyé comme non fiable, et les bons clients demandent confirmation avant une action sensible. Méfiance particulière quand une même session combine un serveur qui lit du contenu extérieur et un autre capable d'envoyer ou d'écrire.

6. Coût : qui paie, et combien par appel ?

Un agent peut appeler un outil des dizaines de fois pour une seule tâche. Vérifiez si le serveur est gratuit, facturé à l'appel ou inclus dans un abonnement, s'il publie ses limites de débit et si l'on peut plafonner la dépense. Un prix maximal par appel, transmis par l'agent, protège efficacement des mauvaises surprises.

Le cas des serveurs MCP de bases de connaissances

Une bonne partie de ce qu'on attend de MCP n'est pas d'agir mais de savoir de façon fiable : procédures internes, documentation produit, réglementation, savoir-faire d'expert. Les serveurs MCP de bases de connaissances y répondent en exposant une recherche sur un corpus de documents, le plus souvent en RAG. Quelques questions en plus pour les évaluer :

• Le serveur cite-t-il les passages sur lesquels il s'appuie ?
• Peut-on obtenir les passages bruts, pour que votre agent raisonne lui-même, en plus d'une réponse rédigée ?
• Qui a sélectionné les documents, et les sources sont-elles officielles ?
• Peut-on limiter la connexion à une seule base plutôt qu'à tout un catalogue ?

Kopik en est un exemple. Son serveur MCP, à l'adresse `https://kopik.io/api/mcp`, utilise Streamable HTTP et une clé API dans l'en-tête `Authorization: Bearer kpk_...`. Il expose `list_bases` (gratuit, liste les bases publiques), `ask_base` (réponse rédigée avec passages sources numérotés) et `search_base` (passages seuls, même prix). Chaque appel peut porter `maxPriceCents`, qui refuse sans frais une base plus chère, et le contenu des bases arrive entre balises `<kopik-untrusted>` pour être traité comme une donnée. L'URL `?base=<slug>` restreint la connexion à une seule base, par exemple Congés payés et temps de travail. Vous pouvez aussi brancher vos propres documents comme base de connaissances privée pour vos agents IA.

Une configuration de départ raisonnable

1. Un ou deux serveurs officiels des outils que vous utilisez déjà, avec des clés en lecture seule pour commencer.
2. Une source de connaissances citable, pour les questions où l'exactitude compte.
3. Des serveurs locaux seulement s'ils apportent une vraie valeur, limités aux dossiers nécessaires.
4. Une revue chaque trimestre : retirer les serveurs inutilisés, renouveler les clés, vérifier les mises à jour.

Chaque serveur ajoute des descriptions d'outils au contexte du modèle, ce qui peut dégrader le choix du bon outil. Peu de serveurs, bien choisis, donnent presque toujours de meilleurs résultats.