Implementer un client

Maintenant que le serveur MCP fonctionne, il est temps de construire le cote client. Le client permet a votre application de communiquer avec le serveur MCP et d’acceder a ses fonctionnalites.

Architecture du client

Le client MCP se compose de deux elements :

• Client MCP : une classe personnalisee pour simplifier l’utilisation de la session
• Session client : la connexion reelle au serveur (partie du SDK Python MCP)

La session gere la communication bas niveau mais necessite un nettoyage soigneux des ressources. C’est pourquoi on l’encapsule dans une classe propre.

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 : executer 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)

La session gere tous les details complexes de communication.

Tester le client

uv run mcp_client.py

Cela se connecte au serveur MCP et affiche les outils disponibles avec leurs noms, descriptions et schemas d’entree.

Differences de schemas

Point important : les definitions d’outils MCP ne correspondent pas exactement a ce que Claude attend. Le format MCP est legerement different de celui requis par Bedrock. Une fonction to_bedrock_tools dans le projet gere cette conversion automatiquement.

Test avec Claude

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. Decider d’utiliser l’outil read_doc_contents
3. Votre client executera cet outil sur le serveur MCP
4. Claude recevra le contenu du document et repondra

Le client agit comme le pont entre votre code applicatif et le serveur MCP, rendant facile l’exposition des fonctionnalites du serveur a Claude.