Implémenter un client

Maintenant que le serveur MCP fonctionne — validé sous toutes ses coutures par l’inspecteur —, il est temps de construire le côté client. Le client permet à votre application de communiquer avec le serveur MCP et d’accéder à ses fonctionnalités ; c’est lui qui prendra, dans notre chatbot, la place qu’occupait la fonction locale d’exécution d’outils.

Architecture du client

Le client MCP se compose de deux éléments superposés :

• Client MCP : une classe personnalisée pour simplifier l’utilisation de la session
• Session client : la connexion réelle au serveur (partie du SDK Python MCP)

Pourquoi cette couche d’enveloppe ? Parce que la session est une ressource exigeante : elle gère la communication bas niveau — connexion au sous-processus serveur, initialisation du protocole — mais nécessite un nettoyage soigneux des ressources, y compris quand le programme s’interrompt sur une exception. En l’encapsulant dans une classe propre, on garantit ce cycle de vie une fois pour toutes, et le reste de l’application manipule un objet simple sans se préoccuper d’ouverture ni de fermeture.

Deux fonctions essentielles

list_tools : lister les outils disponibles

async def list_tools(self) -> list[types.Tool]:
    result = await self.session().list_tools()
    return result.tools

call_tool : exécuter un outil

async def call_tool(
    self, tool_name: str, tool_input: dict
) -> types.CallToolResult | None:
    return await self.session().call_tool(tool_name, tool_input)

Le contraste entre l’importance de ces méthodes et leur taille dit tout du SDK : la session gère tous les détails complexes de communication — sérialisation des messages, transport, corrélation des réponses — et nos méthodes se contentent de déballer les résultats. Vous reconnaissez au passage le duo du protocole : découverte (list_tools) et exécution (call_tool), les deux mêmes opérations que nous assurions localement avec une liste de schémas et un run_tool.

Tester le client

Comme pour le serveur, on teste la pièce isolément avant l’assemblage :

uv run mcp_client.py

Cela se connecte au serveur MCP et affiche les outils disponibles avec leurs noms, descriptions et schémas d’entrée. Si cette étape échoue, le problème est circonscrit — connexion ou serveur — et se corrige maintenant, pas au milieu d’une conversation complète.

Différences de schémas

Point important, spécifique à notre plateforme : les définitions d’outils MCP ne correspondent pas exactement à ce que Claude attend sur Bedrock. Le format MCP est légèrement différent de celui requis par l’API Converse — noms de champs, structure du schéma JSON. Une fonction to_bedrock_tools dans le projet gère cette conversion automatiquement : elle prend les outils renvoyés par list_tools et produit la structure toolSpec que Bedrock consomme. C’est un adaptateur d’une trentaine de lignes, mais retenez l’idée générale : MCP est un standard indépendant du fournisseur, et chaque plateforme d’inférence a son dialecte d’outils — la traduction entre les deux est un maillon normal de l’architecture.

Test avec Claude

Reste le test de bout en bout, chaîne complète :

uv run main.py

Demandez : « Quel est le contenu du document report.pdf ? »

Claude va :

1. Recevoir la liste des outils disponibles depuis votre client
2. Décider d’utiliser l’outil read_doc_contents
3. Votre client exécutera cet outil sur le serveur MCP
4. Claude recevra le contenu du document et répondra

Chaque maillon de cette séquence a été construit et testé séparément — serveur, inspecteur, client — et c’est leur assemblage qui fonctionne ici du premier coup. Le client agit comme le pont entre votre code applicatif et le serveur MCP : côté serveur il parle le protocole, côté application il offre exactement ce que la boucle de conversation attendait — des outils à lister, des outils à exécuter. La logique de conversation avec Bedrock, elle, n’a pas changé d’une ligne.

Points clés à retenir

• Le client encapsule la session MCP dans une classe qui garantit son cycle de vie (ouverture, nettoyage)
• Deux méthodes portent l’essentiel : list_tools (découverte) et call_tool (exécution)
• Testez le client seul avant le test de bout en bout — un problème circonscrit se corrige vite
• Les schémas MCP ≠ format Bedrock : to_bedrock_tools fait la traduction vers toolSpec
• La boucle de conversation est inchangée : seule la provenance des outils a migré vers le serveur