L'inspecteur de serveur MCP

Notre serveur MCP existe, mais comment vérifier qu’il fonctionne ? Le brancher directement sur le chatbot complet serait la pire méthode : si quelque chose casse, impossible de savoir si la faute vient du serveur, du client ou de la conversation avec Claude. Le SDK Python MCP fournit la bonne réponse : un inspecteur dans le navigateur, qui se connecte à votre serveur et permet de tester chaque fonctionnalité en temps réel — sans client, sans Claude, sans application.

Démarrer l’inspecteur

Une seule commande suffit :

mcp dev mcp_server.py

Elle démarre votre serveur en mode développement et l’inspecteur qui va avec, accessible via une URL locale affichée dans le terminal. Ouvrez-la dans votre navigateur, cliquez sur « Connect », et l’inspecteur établit la connexion avec le serveur — la même poignée de main qu’effectuera plus tard votre client Python.

Interface de l’inspecteur

Une fois connecté, l’interface s’organise en sections qui recouvrent exactement les trois primitives du protocole :

• Resources : les ressources exposées
• Prompts : les prompts pré-définis
• Tools : les outils disponibles

Cette correspondance n’est pas un hasard : l’inspecteur est un client MCP générique, qui interroge votre serveur par les mêmes requêtes standardisées que n’importe quel autre client. Ce qu’il affiche, c’est ce que tout client verra — si un outil manque ici, il manquera partout.

Tester vos outils

La section Tools permet de vérifier nos deux outils de documents. Le parcours de test :

1. Cliquez « List Tools » pour voir tous les outils
2. Sélectionnez un outil
3. Remplissez les champs de test (ex : doc_id = "deposition.md")
4. Cliquez « Run Tool »
5. Vérifiez les résultats

Deux vérifications valent le détour à cette étape. D’abord, la liste des outils affiche les descriptions et schémas générés depuis vos signatures de fonctions et docstrings — relisez-les avec l’œil de Claude : est-ce assez clair pour décider quand appeler l’outil ? Ensuite, testez aussi les cas d’erreur : un doc_id inexistant doit produire un message d’erreur compréhensible, pas un silence ni une trace de pile brute — c’est ce message que Claude recevra et devra interpréter.

Workflow de développement

L’inspecteur installe une boucle de développement courte :

1. Modifier le code du serveur MCP
2. Tester chaque outil avec différentes entrées
3. Vérifier les interactions entre outils
4. Déboguer sans avoir besoin d’une application complète

C’est l’équivalent MCP de ce que Postman ou curl sont aux API REST : un banc d’essai qui isole le composant testé. Chaque problème détecté ici est un problème que vous n’aurez pas à chercher plus tard au milieu d’une conversation complète — quand le serveur rejoindra le client puis Claude, vous saurez que cette brique-là est solide.

Points clés à retenir

• mcp dev mcp_server.py lance le serveur et son inspecteur navigateur — test sans client ni Claude
• L’inspecteur est un client MCP générique : ce qu’il voit est exactement ce que tout client verra
• Sections Resources / Prompts / Tools = les trois primitives du protocole
• Testez les descriptions (assez claires pour Claude ?) et les cas d’erreur (messages exploitables ?)
• Boucle courte : modifier → tester → déboguer, chaque brique validée avant l’intégration