Claude Academy
Chargement

Implémentation d'un client

Leçon 5310 min

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

Avant de plonger dans le code, clarifions un point important concernant les projets MCP. Normalement, vous implémenteriez 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 travaillant ensemble :

  • 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 gère la communication de bas niveau mais nécessite un nettoyage minutieux des ressources lorsque votre programme s'arrête. C'est pourquoi nous l'enveloppons dans notre propre classe - pour gérer ce nettoyage automatiquement.

Comment le client s'intègre dans notre application

Vous souvenez-vous de notre diagramme de flux d'application ? Le client joue un rôle crucial à deux moments clés :

Notre code CLI utilise le client pour :

  • Obtenir une liste des outils disponibles à envoyer à Claude
  • Exécuter les outils lorsque Claude les demande

Implémentation des fonctions principales du client

Implémentons les deux fonctions essentielles : list_tools et call_tool.

Pour list_tools, nous devons nous connecter à notre session et demander les outils disponibles :

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

Pour call_tool, nous transmettons le nom de l'outil et les paramètres d'entrée au 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)

C'est tout ! La session gère pour nous tous les détails complexes de communication.

Tester le client

Le fichier client inclut un simple harnais de test en bas. Vous pouvez l'exécuter directement pour vérifier que tout fonctionne :

bash
uv run mcp_client.py

Cela se connectera à votre serveur MCP et affichera les outils disponibles. Vous devriez voir une sortie montrant vos définitions d'outils, y compris les noms, descriptions et schémas d'entrée.

Différences importantes de schéma

Voici un piège que vous devez connaître : les définitions d'outils MCP ne correspondent pas exactement à ce que Claude attend. La spécification MCP a son propre format pour les schémas d'outils, qui est légèrement différent de ce que Bedrock requiert.

Ne vous inquiétez pas - il y a déjà du code dans le projet qui gère cette conversion automatiquement. La fonction to_bedrock_tools dans core/bedrock.py traduit les définitions d'outils MCP dans le format que Claude comprend.

Tester avec Claude

Maintenant que le serveur et le client fonctionnent tous les deux, vous pouvez tester le flux complet. Essayez d'exécuter votre application principale et demandez à Claude de lire un document :

bash
uv run main.py

Puis 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

Le client agit comme le pont entre le code de votre application et le serveur MCP, facilitant l'exposition des fonctionnalités du serveur à Claude et aux autres parties de votre système.