Accéder aux ressources

Le serveur expose désormais ses ressources ; il faut maintenant que le client sache les lire. Les ressources MCP permettent à votre serveur d’exposer des informations qui peuvent être directement incluses dans les prompts, plutôt que de nécessiter des appels d’outils pour accéder aux données. Le gain n’est pas seulement esthétique : c’est un moyen plus efficace de fournir du contexte aux modèles de langage, et vous allez le mesurer dès le premier test.

Écrire la fonction de lecture

Pour activer l’accès aux ressources dans votre client MCP, une seule fonction est nécessaire : read_resource. Elle demande deux imports supplémentaires, l’un pour interpréter le JSON, l’autre pour construire un URI validé.

import json
from pydantic import AnyUrl

La fonction elle-même fait la requête au serveur MCP puis traite la réponse selon son type MIME :

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 choses se passent ici. L’URI reçu sous forme de chaîne est d’abord converti en AnyUrl, le type attendu par la session. La réponse du serveur arrive ensuite sous forme d’un résultat contenant une liste contents ; on accède au premier élément parce qu’on n’a généralement besoin que d’une ressource à la fois. Chaque élément de cette liste transporte le contenu réel, texte ou données, un type MIME qui indique comment le parser, et d’autres métadonnées décrivant la ressource.

C’est ce type MIME qui pilote la fin de la fonction. Si le serveur annonce application/json, le texte est parsé et l’objet Python correspondant est retourné ; dans tous les autres cas, le contenu textuel brut est renvoyé tel quel. Concrètement, un appel sur docs://documents vous rendra une vraie liste d’identifiants exploitable par votre code d’autocomplétion, tandis qu’un appel sur docs://documents/plan.md vous rendra le texte du document. La même fonction gère ainsi de façon transparente les données structurées et les documents texte, sans que l’appelant ait à se poser la question.

Voir le résultat dans la CLI

Une fois la fonction en place, testez la fonctionnalité depuis votre application. Tapez @ suivi d’un nom de ressource, et observez l’enchaînement :

1. Afficher les ressources disponibles dans une liste d'autocomplétion
2. Vous permettre de sélectionner une ressource avec les touches fléchées
3. Inclure le contenu de la ressource directement dans votre prompt
4. Envoyer tout à Claude sans appels d'outils supplémentaires

Les deux premières étapes reposent sur la ressource directe docs://documents, la troisième sur la ressource avec template. Vous venez donc de faire travailler ensemble les deux formes écrites à la leçon précédente.

Pourquoi ce chemin est plus court

Comparé au passage par un outil, ce mécanisme change le moment et l’acteur de la décision, comme le résume le tableau ci-dessous.

Aucune de ces deux colonnes n’est meilleure dans l’absolu. Quand l’utilisateur a lui-même désigné le document qu’il veut discuter, l’application sait déjà quoi charger : faire faire un aller-retour à Claude pour redemander ce que l’on connaît déjà n’ajoute que de la latence. À l’inverse, quand la donnée utile dépend du raisonnement en cours, seul le modèle peut décider, et l’outil reprend l’avantage.

Où les ressources font la différence

Quatre familles d’usage reviennent constamment. Les documents de référence d’abord : on charge le texte avant de poser des questions dessus, ce qui est exactement le scénario de notre CLI. Les données de configuration ensuite, lorsqu’il s’agit d’injecter des paramètres système dans le contexte au démarrage d’une conversation. L’autocomplétion également, pour lister dans une interface les éléments réellement disponibles côté serveur. Le contexte enrichi enfin, qui consiste à fournir des données de fond sans que Claude ait à les demander.

Le bénéfice se ressent surtout du côté de l’utilisateur : l’expérience est nettement plus fluide que si Claude devait multiplier les appels d’outils pour accéder au contenu des documents. Le contenu de la ressource fait partie du contexte initial, ce qui permet des réponses immédiates sur les données.