À propos

Comment cet annuaire est vérifié

Chaque service répertorié ici est vérifié à partir de ses propres fichiers publics : son llms.txt, son manifeste MCP, sa description d’API publiée ou sa propre annonce. Nous nous connectons aussi une fois à chaque serveur MCP distant, pour voir s’il répond à la poignée de main (handshake) MCP et quels outils il liste. Une fiche indique ce qui a été trouvé, quand et où.

Vérification en direct des serveurs MCP distants

Résultats (5 octobre 2026) : sur 16 682 serveurs MCP distants vérifiés, 9 860 ont répondu à la poignée de main MCP et listé à eux tous 154 231 outils ; 4 996 exigeaient une connexion (dont 3 930 renvoyant vers des métadonnées OAuth), 52 anciens points de terminaison SSE ont ouvert leur flux et 1 774 n’ont pas répondu comme des serveurs MCP. 194 autres n’ont pas été interrogés : leur URL dans le registre contient un espace réservé à remplir, ou n’est pas une adresse https publique.

Ce qui est vérifié. Pour chaque point de terminaison distant figurant dans l’entrée d’un serveur, cet annuaire envoie une requête MCP initialize (version du protocole 2025-06-18) en Streamable HTTP. Si le serveur répond, il envoie la notification initialized, demande tools/list (jusqu’à cinq pages) et enregistre le nom et la version du serveur, la version du protocole indiquée dans sa réponse, le nombre d’outils et jusqu’à 50 noms d’outils ; il met ensuite fin à la session. Les points de terminaison sur l’ancien transport SSE sont seulement ouverts, avec une attente de dix secondes au plus pour l’événement qui indique leur point de terminaison de messages.

Ce qui n’est pas vérifié. Aucun outil n’est appelé, aucune ressource ni aucun prompt n’est lu et aucune connexion à un compte n’a lieu : un point de terminaison qui répond HTTP 401 ou 403 est enregistré comme exigeant une connexion, en notant s’il renvoie vers des métadonnées d’autorisation OAuth. La vérification ne dit rien de ce que font les outils, ni avec quelle qualité ou quelle sécurité, et ce n’est qu’un instantané : un serveur qui a répondu peut être hors service plus tard, et un serveur en échec n’était peut-être que brièvement indisponible.

Comment elle interroge. Les requêtes s’identifient comme AgentReadyDirectoryCheck/1.0, avec un lien vers cette page, ne transmettent ni identifiants ni cookies, attendent 15 secondes au plus, ne sont relancées qu’une seule fois après une connexion interrompue et ne visent qu’un hôte à la fois. Les URL contenant des espaces réservés, les URL en HTTP simple, localhost et les adresses privées ne sont pas interrogées.

À quoi servent les noms d’outils. En plus d’être affichés sur la page de chaque serveur, les noms d’outils permettent de classer un serveur dans une catégorie lorsque son propre nom et son résumé ne correspondent à aucune : si au moins trois de ses noms d’outils désignent un même sujet (voyage, restauration et livraison, immobilier, santé, cartes et transports, finance, shopping ou médias), soit deux fois plus que pour tout autre sujet et au moins un quart de l’ensemble de ses outils, le serveur y est classé, et sa page précise que la catégorie vient des noms de ses outils. Les ensembles d’outils que 20 serveurs ou plus listent à l’identique (outils de passerelle et de modèle) et les mots génériques comme search, get et list sont d’abord écartés. Comment les catégories sont attribuées.

Pourquoi des vérifications ont échoué. erreur HTTP 4xx : 786, connexion impossible : 491, erreur HTTP 5xx : 243, pas de réponse dans les 15 secondes : 181, a répondu, mais pas comme un serveur MCP : 41, limite de requêtes atteinte (HTTP 429) : 20 et a refusé la poignée de main : 12.

Qui a publié un serveur. Le MCP Registry n’accepte les noms sous io.github.<compte> que de la part d’une personne connectée avec GitHub en tant que cet utilisateur, ou pour cette organisation, et les noms sous un domaine inversé comme com.example que de la part d’une personne ayant prouvé qu’elle contrôle example.com - par un enregistrement DNS, qui couvre aussi ses sous-domaines, ou par un fichier à l’adresse /.well-known/mcp-registry-auth (documentation du registre). La page de chaque serveur indique de quelle manière son espace de noms a été vérifié. Cela montre qui a publié l’entrée, pas que le produit qu’elle nomme la cautionne.

Sources et licences

SourceUtilisé pourLicence
MCP Registry officielServeurs MCP : noms, points de terminaison, paquets et le résumé de l’éditeur lui-mêmePublié à l’intention des agrégateurs ; faits uniquement, résumés réécrits
La documentation propre à chaque serviceLes intégrations IA qu’un service propose, avec un lien vers la page qui l’indiqueFaits uniquement ; aucun texte copié
Le point de terminaison de chaque serveur MCP distantLa vérification en direct : si le point de terminaison a répondu à la poignée de main (handshake) d’initialisation MCP, le nom du serveur, sa version et la version du protocole, ainsi que les noms et le nombre de ses outils (tools/list) ; aucun outil n’est appelé et aucune connexion à un compte n’a lieuFaits uniquement (statut, noms et nombres), enregistrés avec la date
Documentation du MCP Registry : authentificationCe que prouve un espace de noms du registre : une connexion GitHub pour les noms io.github.*, une preuve DNS ou HTTP d’un domaine pour les noms en domaine inverséFaits uniquement
Le site web de chaque service/llms.txt, /.well-known/mcp.json, /.well-known/ai-plugin.json et /agents.json, demandés et enregistrés avec leur statut et la dateFaits uniquement (statut et présence de chaque fichier)

Qui gère ce site

Agent-Ready est exploité par Nexa AI. Aucun service, hôtel ou lieu ne paie pour être répertorié, décrit ou classé.

Charte éditoriale : comment les entrées sont choisies, ce que signifie une fiche, comment demander une correction ou une suppression, et la fraîcheur des données.