Maintenant que notre serveur MCP fonctionne, il est temps de construire le côté client. Le client est ce qui permet à notre code applicatif de communiquer avec le serveur MCP et d'accéder à ses fonctionnalités.
Comprendre l'architecture du client
Dans la plupart des projets réels, vous implémenterez soit un client MCP, soit un serveur MCP, mais pas les deux. Dans ce projet, nous construisons les deux simplement pour que vous puissiez voir comment ils fonctionnent ensemble.

Le client MCP se compose de deux composants principaux :
- MCP Client - Une classe personnalisée que nous créons pour faciliter l'utilisation de la session
- Client Session - La connexion réelle au serveur (fait partie du SDK Python MCP)

La session client nécessite une gestion attentive des ressources - nous devons nettoyer correctement les connexions une fois que nous avons terminé. C'est pourquoi nous l'encapsulons dans notre propre classe qui gère automatiquement tout le nettoyage.
Comment le client s'intègre dans notre application
Vous vous souvenez de notre diagramme de flux applicatif ? Le client est ce qui permet à notre code d'interagir avec le serveur MCP à deux moments clés :

Notre code CLI utilise le client pour :
- Obtenir une liste des outils disponibles à envoyer à Claude
- Exécuter des outils lorsque Claude les demande
Implémenter les fonctions principales du client
Nous devons implémenter deux fonctions essentielles : list_tools() et call_tool().
Fonction List Tools
Cette fonction récupère tous les outils disponibles depuis le serveur MCP :
async def list_tools(self) -> list[types.Tool]:
result = await self.session().list_tools()
return result.toolsC'est simple - nous accédons à notre session (la connexion au serveur), appelons la méthode intégrée list_tools(), et renvoyons les outils à partir du résultat.
Fonction Call Tool
Cette fonction exécute un outil spécifique sur le serveur :
async def call_tool(
self, tool_name: str, tool_input: dict
) -> types.CallToolResult | None:
return await self.session().call_tool(tool_name, tool_input)Nous transmettons le nom de l'outil et les paramètres d'entrée (fournis par Claude) au serveur et renvoyons le résultat.
Tester le client
Le fichier client inclut un simple harnais de test en bas de page. Faites-lui appeler l'une de vos nouvelles méthodes et afficher le résultat :
async with MCPClient(
command="uv", args=["run", "mcp_server.py"]
) as client:
result = await client.list_tools()
print(result)Exécutez ensuite le fichier directement pour vérifier que tout fonctionne :
uv run mcp_client.pyCela se connectera à votre serveur MCP et affichera les outils disponibles. Vous devriez voir une sortie montrant vos définitions d'outils, y compris les descriptions et les schémas d'entrée.
Assembler le tout
Une fois les fonctions du client implémentées, vous pouvez tester le flux complet en exécutant votre application principale :
uv run main.pyEssayez de demander :
Voici ce qui se passe en coulisses :
- Votre application utilise le client pour obtenir les outils disponibles
- Ces outils sont envoyés à Claude avec votre question
- Claude décide d'utiliser l'outil read_doc_contents
- Votre application utilise le client pour exécuter cet outil
- Le résultat est renvoyé à Claude, qui vous répond ensuite
Le client agit comme le pont entre la logique de votre application et les fonctionnalités du serveur MCP, facilitant l'intégration d'outils puissants dans vos flux de travail d'IA.