Registres de serveurs MCP comparés : Smithery, Glama, mcp-get

Où vous allez réellement chercher des serveurs MCP

Si vous avez passé un peu de temps à construire avec le Model Context Protocol, vous avez probablement remarqué que l'écosystème est éclaté entre au moins quatre ou cinq endroits différents. Il n'existe pas de registre canonique unique, ce qui fait que les développeurs naviguent entre Smithery, Glama, mcp-get et une poignée d'awesome lists GitHub selon ce qu'ils cherchent et la confiance qu'ils accordent à la source.

Chacun de ces registres a une philosophie distincte sur ce qui mérite d'y figurer et sur l'effort de vérification à fournir. Comprendre ces différences vous évite d'installer quelque chose de douteux ou de passer un après-midi à évaluer un outil qui est à l'abandon depuis janvier.

Smithery : l'approche gestionnaire de paquets

Smithery se positionne au plus près de ce que vous attendriez d'un registre de paquets traditionnel. Il dispose d'une interface web pour la navigation, mais l'accent est mis avant tout sur l'installabilité. Les serveurs présents sur Smithery sont censés fonctionner avec un flux d'installation cohérent, ce qui implique au moins une cohérence structurelle minimale d'un référencement à l'autre.

À la mi-2025, Smithery liste plusieurs milliers de serveurs MCP et est devenu l'une des sources les plus fréquemment citées dans la documentation d'intégration de Claude et d'autres agents. La procédure de soumission exige un serveur fonctionnel doté d'un schéma défini, ce qui filtre les projets les plus inachevés avant même qu'ils n'apparaissent dans les résultats de recherche.

Le seuil de qualité est réel, mais il n'est pas spécialement élevé. Smithery vérifie qu'un serveur est installable et possède un manifeste valide, mais ne pratique pas une revue de sécurité approfondie ni n'audite ce que le serveur fait effectivement avec les permissions qu'il demande. Un serveur qui demande un accès au système de fichiers puis en fait quelque chose d'inattendu passerait sans encombre les vérifications actuelles de Smithery.

Là où Smithery se distingue, c'est sur l'intégration outillée. Il dispose de connecteurs directs avec la configuration de Claude Desktop et publie des métadonnées structurées que d'autres outils peuvent consommer par programmation. Si vous construisez quelque chose qui doit énumérer les serveurs MCP disponibles ou automatiser une installation, l'API de Smithery est la plus accueillante pour les développeurs du lot.

Glama : la curation avec une lecture sécurité

Glama adopte une approche sensiblement différente. Plutôt que d'optimiser pour la couverture, il mise sur la curation et a investi plus explicitement dans la revue de sécurité dans le cadre du processus de référencement. Les serveurs de Glama passent par une revue qui inclut la recherche de risques évidents d'injection de prompt, l'évaluation des permissions demandées par rapport à ce que la finalité déclarée du serveur exige, et le signalement des outils qui présentent des chaînes de dépendances suspectes.

Cela rend le catalogue de Glama plus restreint que celui de Smithery, mais le rapport signal-bruit est meilleur. Si vous évaluez un serveur MCP en vue d'un usage en production ou en contexte d'entreprise, partir des référencements de Glama vous donne une liste plus courte de points à surveiller.

Glama publie également des métadonnées de sécurité aux côtés des référencements, ce qui est réellement utile. Vous pouvez voir d'un coup d'œil si un serveur présente des vulnérabilités connues dans ses dépendances, quelles permissions il déclare, et si la revue a signalé un point méritant enquête. Ce niveau de transparence n'est proposé par aucun autre registre majeur.

Le revers, c'est la couverture. Les serveurs récents, les outils expérimentaux et les projets communautaires apparaissent souvent sur Smithery ou dans les awesome lists des semaines ou des mois avant d'arriver sur Glama, voire ils n'y arrivent jamais. Si vous cherchez à rester à jour de ce qui se construit, Glama seul vous laissera des trous.

mcp-get : le registre orienté CLI

mcp-get est le plus orienté outils-de-développement des grands registres. Il est bâti autour d'une interface en ligne de commande, et l'expérience est délibérément proche de npm install ou brew install. Vous lancez npx mcp-get install <nom-du-serveur> et il se charge d'injecter automatiquement la configuration dans votre Claude Desktop ou dans la configuration de votre autre client.

Le registre qui sous-tend mcp-get est maintenu par la communauté via des pull requests vers un dépôt central. N'importe qui peut soumettre un serveur en ouvrant une PR contenant les métadonnées requises, et les mainteneurs revoient et fusionnent. Cela rend la procédure transparente et auditable, puisque vous pouvez consulter l'historique git pour voir précisément quand quelque chose a été ajouté et qui l'a approuvé.

La qualité des revues sur les PR de mcp-get est variable. Certaines reçoivent une revue approfondie de mainteneurs actifs ; d'autres sont rapidement examinées puis fusionnées. Il n'y a pas d'analyse de sécurité automatisée dans le pipeline, donc la sûreté d'un référencement donné dépend fortement du degré d'attention que le mainteneur de garde a porté ce jour-là.

Ce que mcp-get fait bien, c'est l'expérience d'installation. L'injection automatique de configuration est réellement pratique, et la CLI rend simple la gestion de plusieurs serveurs sur différents projets. Pour les développeurs qui vivent dans le terminal et veulent voir tourner quelque chose rapidement, c'est souvent le chemin le plus court entre rien et une intégration qui marche.

Les awesome-mcp lists : le Far West de GitHub

Il existe désormais au moins une douzaine de dépôts qui suivent la convention de nommage awesome-mcp-servers sur GitHub, dont quelques-uns ont accumulé plusieurs milliers d'étoiles. Les plus en vue, dont punkpeye/awesome-mcp-servers et appcypher/awesome-mcp-servers, sont devenus de fait des points d'agrégation pour la communauté.

Le format est familier si vous avez déjà utilisé une awesome list : des liens classés par catégories avec de courtes descriptions, maintenus via pull requests, sans outillage d'installation, sans métadonnées structurées. La valeur tient à la découvrabilité et au signal communautaire. Un serveur avec 500 étoiles sur GitHub qui apparaît sur trois awesome lists différentes mérite probablement un coup d'œil plus attentif, même en l'absence de revue formelle.

La qualité de la curation varie énormément d'une awesome list à l'autre. Certains mainteneurs suppriment activement les liens morts et retirent les serveurs abandonnés. D'autres fusionnent les PR de manière généreuse et laissent la liste grossir sans grand élagage. La liste de punkpeye a été plus activement maintenue que la plupart, avec des passes de nettoyage périodiques et quelques exigences de base sur ce qui est inclus.

Les awesome lists sont aussi le lieu où vous trouverez les serveurs les plus expérimentaux et les plus de niche. Si quelqu'un a construit un serveur MCP pour un outil interne précis ou pour un cas d'usage très étroit, il a probablement été référencé dans une awesome list avant d'aller où que ce soit d'autre. Cela les rend précieuses pour la veille et pour comprendre les marges de ce qui se construit, même si vous n'iriez pas y installer aveuglément des outils sans revue.

Comment le contrôle qualité diffère réellement

Si vous placez ces quatre sources sur un spectre allant du plus permissif au plus restrictif, l'ordre est globalement : awesome lists, mcp-get, Smithery, Glama. Mais cette mise en ordre simplifie à l'excès, car chacune est permissive ou restrictive selon des dimensions différentes.

Les awesome lists n'ont aucune exigence structurelle. Un lien vers un dépôt GitHub avec un README suffit. mcp-get exige un manifeste fonctionnel et passe par une revue humaine, mais cette revue est légère. Smithery exige l'installabilité et la conformité au schéma, ce qui détecte les problèmes structurels mais pas les problèmes comportementaux. Glama ajoute la revue de sécurité et l'audit de permissions, ce qui détecte une autre classe de problèmes que les autres laissent entièrement passer.

Aucun ne pratique aujourd'hui d'analyse à l'exécution. Tous évaluent les serveurs sur la base du code, des métadonnées et du comportement déclaré, et non sur la base de ce qu'ils font effectivement quand ils tournent dans le contexte d'un agent. C'est un manque significatif, en particulier au moment où les serveurs MCP commencent à demander des permissions plus larges et à opérer dans des environnements plus sensibles.

D'un point de vue pratique, la combinaison qui a le plus de sens pour la plupart des équipes est la suivante : utilisez Glama comme source principale pour tout ce qui part en production, utilisez Smithery pour la découverte plus large et pour les outils qui n'ont pas encore atteint Glama, et utilisez les awesome lists pour la veille et pour rester au courant de ce que la communauté construit. mcp-get mérite sa place dans votre boîte à outils spécifiquement pour son expérience d'installation, même si vous avez trouvé le serveur ailleurs.

Couverture inter-registres et ce qui passe à la trappe

Une chose qui apparaît clairement quand vous fréquentez les quatre sources, c'est que la couverture est inégale de manière prévisible. Les serveurs officiels et bien dotés en ressources, comme les implémentations de référence d'Anthropic, les intégrations SaaS majeures et les outils d'éditeurs d'outils de développement établis, tendent à apparaître partout rapidement. Les serveurs construits par la communauté pour des cas d'usage de niche ont plus de chances de n'apparaître que sur les awesome lists ou sur mcp-get, et risquent de ne jamais arriver sur Glama.

Cela crée un véritable problème de découverte. Les serveurs qui bénéficieraient le plus d'une revue de sécurité (construits par la communauté, moins scrutés, demandant souvent de larges permissions) sont précisément ceux qui ont le moins de chances d'en avoir reçu une. Les serveurs qui ont été revus en profondeur sont souvent ceux qui en avaient le moins besoin.

Des plateformes comme Skillful.sh qui agrègent l'ensemble de ces sources et appliquent une notation de sécurité cohérente comblent directement ce vide. Quand vous pouvez voir qu'un serveur apparaît sur trois awesome lists et sur Smithery mais pas sur Glama, et qu'il a une note de sécurité C basée sur l'analyse statique, c'est une information actionnable. Cela vous indique que le serveur a une adoption communautaire mais n'a pas été audité au standard que vous voudriez avant de le déployer.

Signaux d'adoption à suivre

Au-delà de la sécurité, l'autre chose que ces registres vous aident à évaluer, c'est de savoir si un serveur est réellement maintenu et utilisé. Les étoiles GitHub sont un proxy grossier mais pas excellent, puisqu'elles s'accumulent dans le temps et ne reflètent pas l'activité courante. Des signaux plus utiles incluent l'activité de commit récente, la rapidité avec laquelle les issues reçoivent une réponse, et le nombre de registres différents qui ont indépendamment listé le serveur.

Un serveur qui apparaît sur cinq awesome lists différentes, qui dispose de référencements actifs sur Smithery et mcp-get et qui montre des commits récents est probablement en bon état. Un serveur avec 800 étoiles mais sans commit depuis six mois et présent uniquement sur une awesome list mérite scepticisme, indépendamment de la qualité apparente de son README.

Les registres eux-mêmes ne font pas toujours bien remonter ces signaux. Smithery affiche quelques métadonnées, les awesome lists n'en affichent presque aucune, et la CLI de mcp-get n'expose pas grand-chose au-delà de la commande d'installation. Glama est le plus informatif au moment de la découverte, mais même lui ne vous donne pas une vision complète de la trajectoire d'adoption dans le temps.

Que faire concrètement de cette information

Lorsque vous évaluez un serveur MCP pour un usage réel, un flux de travail raisonnable ressemble à ceci : trouvez le serveur là où vous le rencontrez en premier, puis recoupez-le avec les autres registres pour comprendre son empreinte d'adoption. Vérifiez si Glama l'a revu et ce qu'a donné cette revue. Allez voir directement le dépôt GitHub pour l'activité récente et les issues ouvertes. Si vous comptez l'utiliser dans un contexte où il aura accès à des données ou systèmes sensibles, lisez le code source des gestionnaires de permissions concernés avant de l'installer.

Les registres sont des points de départ utiles, mais aucun ne se substitue à votre propre jugement sur ce que vous faites tourner réellement dans votre pile d'agent. L'écosystème évolue suffisamment vite pour que l'infrastructure de contrôle qualité ait encore du retard sur le volume de serveurs publiés. Traiter un seul registre comme un sceau d'approbation complet serait une erreur, mais les utiliser ensemble vous donne une bien meilleure vision que chacun pris isolément.

Lectures complémentaires

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