Vérifiez que votre serveur MCP fonctionne vraiment. Collez l'URL et obtenez un rapport réussite/échec sur la connexion, le handshake, le transport et les outils annoncés.
Une liste toute verte prouve que votre serveur fonctionne. Elle ne montre pas à un client ce qu'il fait. Pointez MCP Showcase sur la même URL et obtenez un playground en direct qu'il pourra essayer dans son navigateur.
Un endpoint déployé, pas un processus local. Ajoutez un jeton bearer si le serveur en a besoin : il sert une seule fois et n'est jamais conservé.
Un véritable handshake MCP, d'abord en HTTP streaming puis en SSE en repli, exactement comme le feront Claude, Cursor ou VS Code.
Un rapport vérification par vérification, plus le journal complet des requêtes et des réponses : un échec désigne l'étape en cause plutôt qu'une erreur générique.
Collez ci-dessus une URL Model Context Protocol : ce testeur exécute un vrai client contre elle —
la même séquence que Claude Desktop, Cursor ou VS Code lorsqu'ils se connectent. Il ouvre la
connexion, effectue le handshake initialize, négocie une version du protocole et
appelle tools/list, puis rend compte de chaque étape séparément, en réussite ou en
échec.
Cette séparation est tout l'intérêt. Un client qui ne voit pas votre serveur vous donne une seule erreur inutile ; ici vous obtenez sept réponses et vous savez si l'endpoint est injoignable, si le handshake échoue, si le transport ne correspond pas, ou si la liste d'outils est simplement vide.
initialize aboutit et une version du protocole
est négociée. Un serveur qui accepte le TCP mais échoue ici tourne, mais ne parle pas MCP.
C'est la raison la plus courante de recourir à un testeur hébergé, et c'est presque toujours l'une
de ces trois causes. L'endpoint n'est pas accessible publiquement : il écoute sur localhost, il
est derrière un pare-feu, ou le déploiement n'est pas terminé. Le chemin déployé diffère du chemin
local : les serveurs MCP sont montés tantôt sur /mcp, tantôt sur /sse,
tantôt à la racine, et celui qui marchait avec mcp dev n'est pas toujours celui que
votre hébergeur expose. Ou la build déployée est simplement plus ancienne que la vôtre.
Le journal des requêtes et des réponses sous le résultat distingue les trois cas. Une connexion refusée ne ressemble en rien à un 404, et un 401 vous dit que le serveur va bien et attend un jeton.
Aucun outil n'est jamais appelé. Ce qui est vérifié, c'est la couche en dessous — connexion, handshake, annonce — qui doit fonctionner avant qu'un agent puisse appeler quoi que ce soit. Cela ne dira pas si un outil valide ses entrées ni s'il renvoie la bonne réponse. Pour voir les schémas eux-mêmes, utilisez l'MCP Inspector ; pour savoir s'il est prudent d'y pointer un agent, lancez le scanner de sécurité.
Une liste toute verte vous dit que la plomberie fonctionne. Elle ne dit rien à un client potentiel : il ne sait pas lire un handshake, et une liste de noms d'outils n'est pas une démonstration. C'est précisément le rôle de MCP Showcase : pointez-le sur la même URL et obtenez une page de playground partageable où n'importe qui peut essayer les outils dans son navigateur, avec une documentation générée pour chacun et la configuration prête à copier.