Accéder aux ressources MCP

Le serveur expose des ressources ; le client doit maintenant les consommer. Les ressources MCP permettent à votre serveur d’exposer des données directement incluses dans les prompts, sans nécessiter d’appels d’outils — et c’est le client, donc votre application, qui pilote ces accès : Claude n’est pas dans la boucle. Cette leçon implémente la méthode de lecture et la branche sur la fonctionnalité de mentions du chatbot.

Implémenter read_resource dans le client

Une seule méthode couvre le besoin :

async def read_resource(self, uri: str) -> Any:
    result = await self.session().read_resource(AnyUrl(uri))
    resource = result.contents[0]

    if isinstance(resource, types.TextResourceContents):
        if resource.mimeType == "application/json":
            return json.loads(resource.text)
        return resource.text

Trois gestes en quelques lignes. L’URI est enveloppée dans AnyUrl — le type pydantic qu’exige le SDK, validation de format comprise. Le résultat arrive en liste contents, dont on prend le premier élément. Puis le type MIME décide du traitement : les ressources annoncées application/json sont parsées en structures Python, le texte brut est renvoyé tel quel. L’appelant reçoit toujours une donnée prête à l’emploi — une liste pour l’autocomplétion, une chaîne pour le contexte — sans connaître les détails du transport.

Imports nécessaires

import json
from pydantic import AnyUrl

Test dans l’application CLI

Cette méthode alimente la mention @ du chatbot. Quand un utilisateur tape « Que contient le @rapport.md ? », le système :

1. Affiche les ressources disponibles en autocomplétion
2. Récupère automatiquement le contenu de la ressource
3. Inclut ce contenu dans le prompt envoyé à Claude

Les étapes 1 et 2 utilisent nos deux types de ressources : la ressource-liste (JSON) peuple le menu d’autocomplétion, la ressource-document (texte) fournit le contenu — deux appels à read_resource, deux formats, une seule méthode.

Avantage : Claude reçoit le contenu directement dans le prompt — pas besoin d’appel d’outil supplémentaire → interactions plus rapides. Comparez les deux chemins pour mesurer le gain : par outil, il faudrait un tour complet de conversation — Claude demande la lecture, votre code l’exécute, le résultat repart, Claude répond enfin. Par ressource, la donnée est déjà là quand le modèle commence à lire la question : un seul tour, moins de latence, moins de tokens.

La règle d’architecture que cette leçon illustre : quand l’application sait à l’avance quelle donnée il faut — l’utilisateur vient de mentionner un document —, une ressource la fournit directement ; l’outil reste pour les cas où c’est Claude qui doit décider d’aller chercher quelque chose en cours de raisonnement. Deux primitives, deux détenteurs du contrôle — le cœur de la grille de lecture MCP.

Points clés à retenir

• read_resource(uri) : l’application récupère la donnée, Claude n’est pas dans la boucle
• AnyUrl valide l’URI ; le type MIME pilote le traitement (JSON parsé, texte brut tel quel)
• La mention @ enchaîne deux lectures : la liste pour l’autocomplétion, le document pour le contexte
• Ressource = un tour de conversation au lieu de deux : la donnée précède la question dans le prompt
• Application sait quoi charger → ressource ; Claude doit décider en raisonnant → outil