Chargement

Maintenant que notre serveur MCP fonctionne, il est temps de construire le côté client. Le client est ce qui permet à notre application 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 - pas les deux. Nous construisons les deux dans ce projet 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 un nettoyage approprié des ressources lorsque nous en avons terminé avec elle. C'est pourquoi nous l'enveloppons dans notre classe MCP Client personnalisée - pour gérer automatiquement tout ce nettoyage.

Comment le client s'intègre dans notre application

Vous vous souvenez du flux de notre application ? Notre code CLI doit faire deux choses principales avec le serveur MCP :

  1. Obtenir une liste des outils disponibles à envoyer à Claude
  2. Exécuter les outils lorsque Claude les demande

Le client MCP fournit ces capacités via de simples appels de méthode que notre code d'application peut utiliser.

Implémenter les méthodes principales

Nous devons implémenter deux méthodes clés dans notre client : list_tools() et call_tool().

Méthode List Tools

Cette méthode récupère tous les outils disponibles depuis le serveur :

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

C'est simple - nous accédons à notre session (la connexion au serveur), appelons la fonction intégrée list_tools(), et retournons les outils à partir du résultat.

Méthode Call Tool

Cette méthode exécute un outil spécifique sur le serveur :

python
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 retournons le résultat.

Tester le client

Pour tester notre implémentation, nous pouvons exécuter le client directement. Le fichier inclut un harnais de test qui se connecte à notre serveur MCP et appelle nos méthodes :

python
async with MCPClient(
    command="uv", args=["run", "mcp_server.py"]
) as client:
    result = await client.list_tools()
    print(result)

Lorsque nous exécutons ce test, nous devrions voir nos définitions d'outils s'afficher, y compris les outils read_doc_contents et edit_document que nous avons créés précédemment.

Assembler le tout

Maintenant que notre client peut lister les outils et les appeler, nous pouvons tester le flux complet. Lorsque nous exécutons notre application principale et interrogeons Claude à propos d'un document :

  1. Notre code utilise le client pour obtenir les outils disponibles
  2. Ces outils sont envoyés à Claude avec la question de l'utilisateur
  3. Claude décide d'utiliser l'outil read_doc_contents
  4. Notre code utilise le client pour exécuter cet outil
  5. Le résultat est renvoyé à Claude, qui répond ensuite à l'utilisateur

Par exemple, demander « Quel est le contenu du document report.pdf ? » déclenchera l'utilisation par Claude de notre outil de lecture de document, et nous obtiendrons en retour des informations sur le document de la tour de condensation de 20 m que nous avons configuré dans notre serveur.

Le client agit comme le pont entre la logique de notre application et le serveur MCP, facilitant l'accès aux fonctionnalités du serveur sans se préoccuper des détails de connexion sous-jacents.