L'inspecteur de serveur

Notre serveur MCP a des outils ; encore faut-il prouver qu’ils marchent. Quand vous construisez des serveurs MCP, vous avez besoin d’un moyen de tester vos fonctionnalités sans connecter une application complète — car si le test passe par le chatbot entier, chaque bug devient une enquête : serveur ? client ? conversation ? Le SDK Python MCP règle le problème avec un inspecteur dans le navigateur, qui se branche sur votre serveur et permet de le déboguer et le tester en temps réel, isolément.

Démarrer l’inspecteur

Une commande :

mcp dev mcp_server.py

Cela démarre un serveur de développement et fournit une URL locale — affichée dans le terminal — pour accéder à l’inspecteur dans votre navigateur. Sous le capot, l’inspecteur est lui-même un client MCP générique : il parlera à votre serveur avec les mêmes requêtes standardisées que n’importe quelle application. Ce qu’il voit est exactement ce que tout client verra.

Utiliser l’interface

Quand vous ouvrez l’inspecteur, cliquez sur « Connect » pour démarrer votre serveur MCP et charger vos outils — c’est la poignée de main du protocole, celle-là même que votre futur client Python effectuera. La barre de navigation contient des sections comme Resources, Prompts et Tools : une section par primitive MCP, ce qui n’est pas un hasard — l’inspecteur expose le protocole tel quel.

Tester les outils

Le parcours de test d’un outil :

1. Cliquez sur « List Tools » pour voir tous les outils disponibles
2. Sélectionnez un outil spécifique
3. Le panneau de droite affiche un formulaire pour tester cet outil
4. Remplissez les paramètres et cliquez sur « Run Tool »

Par exemple, pour tester l’outil de lecture de document :

• Sélectionnez read_doc_contents
• Entrez un ID de document (comme « deposition.md »)
• Cliquez sur « Run Tool »
• Les résultats s’affichent, incluant le statut et les données renvoyées

Profitez de l’étape « List Tools » pour relire vos descriptions avec l’œil de Claude : ce texte, généré depuis vos Field et docstrings, est tout ce que le modèle saura de vos outils. Et testez aussi le chemin d’erreur — un ID inexistant doit produire un message exploitable, pas un silence : c’est ce message que Claude recevra en production.

Tester l’édition

Pour les outils plus complexes comme l’édition de document, l’inspecteur permet de vérifier un scénario complet :

1. Basculez vers l’outil edit_document
2. Remplissez l’ID du document, le texte à remplacer, et le nouveau texte
3. Exécutez l’outil
4. Utilisez l’outil de lecture pour vérifier que les modifications ont été appliquées

Cette étape 4 est un réflexe à retenir : un outil d’écriture se valide toujours par une lecture — le statut « succès » dit que la fonction n’a pas planté, la relecture dit que l’effet attendu s’est réellement produit.

Workflow de développement

L’inspecteur affiche un historique de vos appels d’outils sur le côté gauche — précieux pour rejouer un cas ou comparer deux exécutions. Le cycle de développement devient court :

1. Modifier votre code serveur
2. Redémarrer l’inspecteur
3. Tester immédiatement vos outils
4. Vérifier les résultats

C’est aux serveurs MCP ce que Postman est aux API REST : un banc d’essai qui isole le composant. Cet inspecteur devient essentiel à mesure que vos serveurs se complexifient — il élimine le besoin de connecter une application complète juste pour tester les fonctionnalités de base, et chaque bug attrapé ici est un bug que vous ne chercherez pas, plus tard, au milieu d’une conversation avec Claude.

Points clés à retenir

• mcp dev mcp_server.py : serveur de développement + inspecteur navigateur, URL affichée dans le terminal
• L’inspecteur est un client MCP générique : ce qu’il voit, tout client le verra
• Testez les descriptions (lisibles pour Claude ?) et les chemins d’erreur (messages exploitables ?)
• Un outil d’écriture se valide par une relecture — le statut ne prouve pas l’effet
• Cycle court modifier→redémarrer→tester : chaque brique validée avant l’intégration