Registre officiel MCP : un annuaire de métadonnées, pas un label de confiance

Où trouver un serveur MCP, et comment savoir qui l'a publié ? Le registre officiel, à l'adresse registry.modelcontextprotocol.io, répond à la seconde question mieux qu'à la première. La documentation le présente comme le dépôt centralisé de métadonnées des serveurs MCP accessibles publiquement, soutenu notamment par Anthropic, GitHub, PulseMCP et Microsoft.

Ce que c'est, et ce que ce n'est pas

Le registre n'héberge ni code ni exécutable. Il stocke une fiche par serveur, au format server.json : son nom unique, l'endroit où le trouver (paquet npm, PyPI, image Docker ou adresse d'un serveur distant), la façon de le lancer et une description.

Il n'est pas non plus conçu pour être interrogé directement par votre assistant. Ses destinataires sont les agrégateurs : places de marché et annuaires, qui récupèrent les fiches par l'API et y ajoutent tri, notes ou contrôles. Le projet publie une spécification OpenAPI pour que ces annuaires, publics ou privés, exposent la même interface.

Enfin, il ne prend pas en charge les serveurs privés. Une entreprise qui veut cataloguer ses serveurs internes doit tenir son propre registre.

Un statut toujours provisoire

D'après le dépôt, le registre a été lancé en préversion le 8 septembre 2025 et son API est gelée en version v0.1 depuis le 24 octobre 2025. Une version v1 accompagnera la disponibilité générale, sans date annoncée. La documentation prévient encore que des changements incompatibles ou des remises à zéro des données restent possibles.

Ce que le registre garantit : l'identité de l'éditeur

Les noms suivent un format de domaine inversé, lié à une preuve de propriété :

• io.github.utilisateur/serveur exige de se connecter avec le compte GitHub correspondant, ou de publier depuis une GitHub Action de ce compte ;
• com.exemple/serveur exige de prouver la maîtrise du domaine, par un enregistrement DNS ou un fichier servi en HTTP.

Pour un paquet npm, le registre vérifie en plus que le champ mcpName du package.json correspond au nom déclaré.

Ce qu'il ne garantit pas : la qualité et la sécurité

Sur ce point, la politique de modération est sans ambiguïté. Les mainteneurs retirent le contenu illégal, les logiciels malveillants, le spam et les serveurs qui ne fonctionnent pas. Ils ne retirent pas les serveurs de mauvaise qualité, ni ceux qui comportent des failles de sécurité. Le texte demande même aux utilisateurs de partir du principe que la modération est minimale, voire inexistante.

L'analyse du code est déléguée : en amont aux registres de paquets comme npm ou PyPI, en aval aux agrégateurs. Un serveur retiré passe au statut deleted, mais sa fiche reste consultable par l'API.

Publier un serveur

La publication ne passe pas par une demande de fusion sur le dépôt. Elle se fait avec l'outil mcp-publisher, depuis le projet du serveur. Pour un serveur TypeScript distribué sur npm, le guide décrit ces étapes :

1. ajouter mcpName au package.json, puis publier le paquet sur npm ;
2. installer l'outil, par exemple avec brew install mcp-publisher ;
3. générer la fiche avec mcp-publisher init et la corriger ;
4. s'authentifier avec mcp-publisher login github ;
5. publier avec mcp-publisher publish.

Un guide distinct couvre l'automatisation par GitHub Actions.

Notre lecture

Pour une petite entreprise qui installe des serveurs MCP, le registre apporte une information utile et une seule : le nom d'un serveur prouve qui l'a publié. Un serveur nommé d'après le domaine de son éditeur est bien le sien. Cela ne dit rien de la qualité du code, qui reste à vérifier avant d'installer.

Pour un éditeur de logiciel français qui propose son propre serveur MCP, s'y inscrire coûte peu et rend le serveur visible des annuaires qui s'alimentent au registre. Préférez la vérification par votre nom de domaine à un compte GitHub personnel : le nom du serveur portera votre marque et ne dépendra pas d'un salarié. Gardez en tête le statut de préversion : une republication pourrait être nécessaire.