Le problème de découverte des serveurs MCP : pourquoi trouver des outils IA est dur

Le paradoxe de l'abondance

Il existe en ce moment plus de 10 000 serveurs MCP disponibles, dispersés à travers des dépôts GitHub, des paquets npm, des registres dédiés et des répertoires communautaires. D'un côté, c'est formidable. Quoi que vous vouliez connecter à votre assistant IA, il existe probablement un serveur MCP pour cela.

De l'autre côté, essayer de trouver le bon donne l'impression de chercher un livre précis dans une bibliothèque sans système de catalogue. Plusieurs serveurs peuvent faire des choses similaires avec des niveaux de qualité différents, des pratiques de sécurité différentes et des trajectoires de maintenance différentes. Le problème n'est pas la disponibilité. Le problème, c'est l'évaluation.

La question de la fragmentation

Les serveurs MCP vivent dans de nombreux endroits différents. Certains sont référencés sur mcp.so. D'autres sur Smithery. Certains n'existent que sous forme de dépôts GitHub que vous pourriez trouver via une recherche. Quelques-uns sont distribués via npm. Et de nouveaux répertoires communautaires apparaissent régulièrement.

Chaque répertoire a sa propre manière de catégoriser les serveurs, ses propres seuils de qualité (ou leur absence) et sa propre cadence de mise à jour. Un serveur peut être listé dans trois répertoires avec des descriptions différentes, des numéros de version différents et des métadonnées différentes. Pour un développeur qui cherche à prendre une décision, cette fragmentation ajoute des frictions inutiles.

La fragmentation n'est la faute de personne. C'est le résultat naturel d'un écosystème en croissance rapide où l'infrastructure de découverte n'a pas suivi la cadence de production des outils. La résoudre exige de l'agrégation entre sources, sans remplacer les répertoires existants mais en superposant une vue unifiée par-dessus.

Les signaux de qualité sont éparpillés

Quand vous évaluez un paquet logiciel traditionnel, vous disposez de plusieurs signaux de qualité. Les compteurs de téléchargements npm vous parlent de l'adoption. Les étoiles GitHub indiquent l'intérêt. Les trackers d'issues montrent l'activité de maintenance. L'analyse de dépendances révèle la santé de la chaîne d'approvisionnement.

Pour les serveurs MCP, ces signaux existent mais sont éparpillés et incomplets. Un serveur publié comme paquet npm a des stats de téléchargement, mais celui distribué comme script Python sur GitHub n'en a pas. Un dépôt très étoilé peut avoir été abandonné depuis des mois. Un serveur avec peu d'étoiles peut être excellent mais récent.

Aucun signal seul ne vous dit si un serveur MCP est digne de confiance, bien maintenu et adapté à votre cas d'usage. Vous devez regarder plusieurs signaux ensemble : récence de la maintenance, santé des dépendances, réputation de l'auteur, adoption communautaire et caractéristiques de sécurité. Le faire manuellement pour chaque serveur candidat prend du temps, et c'est pourquoi la notation automatisée et le recoupement comptent.

La question de la confiance

Installer un serveur MCP, c'est exécuter du code qui interagira avec votre assistant IA et potentiellement avec vos données et systèmes. C'est une décision de confiance, et prendre des décisions de confiance sur du logiciel d'auteurs inconnus est intrinsèquement difficile.

La nature open source de la plupart des serveurs MCP aide ici. Vous pouvez lire le code. Mais en pratique, la plupart des gens n'auditent pas chaque dépendance qu'ils installent. C'est vrai pour les paquets npm, les paquets pip et les serveurs MCP également.

Ce qui aide, c'est de disposer de signaux de confiance intermédiaires. L'auteur maintient-il d'autres projets bien connus ? Le serveur a-t-il été revu par des chercheurs en sécurité ? Est-il listé dans un répertoire curé qui a des standards de qualité ? Est-il utilisé par des organisations qui ont leurs propres processus de revue de sécurité ? Ces signaux indirects ne remplacent pas l'audit du code, mais ils rendent le processus d'évaluation plus pratique.

Les catégories sont floues

Essayer de catégoriser les serveurs MCP révèle que les frontières entre catégories ne sont pas nettes. Un serveur qui interroge une base Postgres est-il un outil de « base de données » ou d'« analyse de données » ? Un serveur MCP qui génère des images est-il un outil d'« IA » ou un outil « créatif » ? Un serveur qui lit les messages Slack est-il un outil de « communication » ou de « productivité » ?

La plupart des répertoires assignent des catégories, mais ils sont souvent en désaccord. Un utilisateur qui cherche des outils de base de données peut passer à côté d'un serveur pertinent parce qu'un répertoire l'a catégorisé en « outils de développement » à la place. La recherche en texte intégral aide, mais elle dépend du fait que la description du serveur soit suffisamment exhaustive pour inclure les termes que l'utilisateur pourrait chercher.

Le rôle de l'agrégation

Le problème de découverte est résoluble, mais pas par un seul répertoire. Il exige d'agréger les données de plusieurs sources, de normaliser les métadonnées, de calculer des signaux de qualité et de présenter le résultat d'une manière qui aide les développeurs à prendre des décisions rapides et informées.

Le recoupement est particulièrement précieux. Si un serveur apparaît dans plusieurs répertoires curés, c'est un signal plus fort que d'apparaître dans un seul. Si les indicateurs GitHub d'un serveur, ses indicateurs npm et sa présence dans les répertoires racontent tous une histoire cohérente, vous pouvez avoir plus de confiance dans votre évaluation.

C'est ce qui a finalement motivé la création d'outils comme Skillful.sh. Les répertoires individuels résolvent chacun une partie du problème, mais l'image complète n'émerge que quand on rassemble ces pièces et qu'on ajoute de l'analyse par-dessus.

Lectures complémentaires

Parcourez les serveurs MCP sur Skillful.sh. Cherchez plus de 137 000 outils IA sur Skillful.sh.