Se faire accepter dans l'annuaire des connecteurs Claude : le dossier complet
Ce que contient un dossier de soumission à l'annuaire des connecteurs Claude, dans quel ordre le monter, et les points qui font refuser un serveur.
Un serveur MCP qui n'est listé nulle part est un serveur que personne n'installe. C'est la partie que les équipes techniques sous-estiment le plus : le travail de distribution est distinct du travail de construction, et il a ses propres exigences.
L'annuaire des connecteurs Claude est le plus visible des canaux, et le plus exigeant. Voici ce que contient un dossier qui passe, dans l'ordre où il faut le monter.
Une précaution : les critères exacts évoluent. Ce qui suit décrit la structure d'un dossier, pas une liste officielle. Vérifie toujours la documentation à jour d'Anthropic avant de soumettre.
1. Le serveur doit être à jour avant tout le reste
Ne soumets pas un serveur que tu vas réécrire trois semaines plus tard.
L'ordre logique est : migration vers la révision courante, durcissement, puis dossier. Un serveur en retard de deux révisions se voit immédiatement, et le délai de correction retarde toute la distribution.
Concrètement, avant d'ouvrir le dossier : transport conforme, en-têtes obligatoires, code d'erreur corrigé, chaîne OAuth vérifiée.
2. La chaîne d'authentification
C'est le point de rejet le plus fréquent, et le plus coûteux à corriger dans l'urgence.
Ce qui doit être en place :
- Un flux OAuth complet et propre, avec la validation du paramètre
iss - Des scopes qui veulent dire quelque chose, pas un token unique qui ouvre tous les outils
- Une révocation par client, visible par l'utilisateur, pas seulement un bouton « tout déconnecter »
- Une gestion des erreurs d'authentification qui dit clairement à l'utilisateur ce qui se passe
Le test simple : connecte ton serveur depuis un compte neuf, sans rien préparer, et regarde combien d'étapes obscures tu traverses. C'est ce parcours qui est évalué.
3. La politique de confidentialité
Elle doit être exacte, pas générique. Un modèle téléchargé et adapté se repère en trois lignes.
Ce qu'elle doit dire précisément :
- Quelles données ton serveur reçoit via les appels d'outils
- Ce que tu en fais et combien de temps tu les gardes
- À qui elles sont transmises, y compris les fournisseurs de modèle si tu appelles une inférence toi-même
- Où elles sont hébergées
- Comment un utilisateur demande leur suppression
Le point sur les fournisseurs de modèle est nouveau pour beaucoup d'équipes. Depuis que le sampling est déprécié, un serveur qui a besoin d'un modèle appelle un fournisseur lui-même, ce qui crée un flux sortant de données utilisateur qui doit être documenté.
4. La description des outils
Les descriptions ne sont pas de la documentation interne. Elles sont lues par le modèle, elles sont souvent visibles de l'utilisateur, et elles font partie de l'évaluation.
Ce qu'on regarde :
- Chaque outil fait une chose et son nom le dit
- La description explique quand utiliser l'outil, pas seulement ce qu'il fait
- Les outils destructeurs sont annotés comme tels, les outils en lecture seule aussi
- Aucune fuite d'infrastructure dans les descriptions ou les messages d'erreur
Un serveur avec quarante outils mal nommés passe moins bien qu'un serveur avec douze outils clairs, même s'il en fait plus.
5. La présentation visuelle
Une fiche d'annuaire est une page produit. Il faut un nom, une phrase qui dit ce que ça fait pour l'utilisateur, une icône propre, et de quoi montrer le produit en action.
Si ton serveur expose une interface via MCP Apps, montre-la. Un aperçu rendu dans le chat vaut mieux que trois paragraphes.
La phrase de description est à travailler sérieusement. C'est elle qui décide de l'installation, pas ta liste d'outils.
6. Le durcissement de l'infrastructure
Avant de soumettre, passe la liste :
- Limite de taille de payload
- Rate limit par outil, maintenant possible au niveau HTTP
- Journal des appels d'écriture, consultable par l'utilisateur
- Comportement propre en cas de dépassement de quota, avec une erreur non retryable
- Surveillance et alerte sur les rejets d'authentification
Ce bloc n'est pas seulement défensif. C'est ce que tu montres quand on te demande pourquoi te faire confiance.
L'ordre qui fait gagner du temps
- Migration et conformité protocole
- Chaîne OAuth et révocation
- Durcissement infrastructure
- Nettoyage des outils et des descriptions
- Politique de confidentialité réécrite à partir de ce qui précède
- Présentation visuelle
- Soumission
La politique de confidentialité arrive en cinquième position pour une raison : elle doit décrire ce que ton serveur fait vraiment. L'écrire avant le durcissement, c'est la réécrire deux fois.
FAQ
Combien de temps prend un dossier ?
Le dossier lui-même, quelques jours. Ce qui prend du temps, ce sont les corrections que la préparation révèle. Compte deux à quatre semaines pour un serveur qui n'a jamais été préparé.
Est-ce que ça vaut le coup pour un petit produit ?
La visibilité est réelle. Mais le vrai bénéfice, c'est que la préparation force un niveau de qualité que tu aurais repoussé indéfiniment. Même refusé, tu ressors avec un meilleur serveur.
Faut-il un domaine et une entité juridique ?
Oui à minima une présence publique crédible : domaine, page produit, contact, mentions légales. Un serveur sans identité vérifiable ne passe pas.
Le dossier complet, monté pour toi
Dossier annuaire Claude : 1 200 €. Je monte le dossier complet, je liste ce qui bloque avant soumission, et je te rends le serveur prêt. J'ai fait l'exercice sur mes propres produits.
Intéressé ? Parler du dossier annuaire →
Lectures liées
Un serveur MCP à faire auditer ?
Cinq minutes pour le décrire. Je réponds sous 24 heures ouvrées avec un premier diagnostic écrit et gratuit.
Faire auditer mon serveur MCP