Accéder aux ressources

Le serveur expose des ressources depuis la leçon précédente ; côté client, il faut maintenant les consommer. Les ressources MCP permettent à votre serveur d’exposer des données qui peuvent être directement incluses dans les prompts, sans nécessiter d’appels d’outils — et cette nuance, « sans appels d’outils », est exactement ce que l’implémentation du client va matérialiser : c’est l’application qui récupère, pas Claude.

Implémentation de la lecture de ressources

La méthode read_resource du client prend un paramètre URI identifiant quelle ressource récupérer :

import json
from pydantic import AnyUrl

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

Deux détails de lecture : l’URI est enveloppée dans AnyUrl, le type pydantic qu’exige le SDK — une validation gratuite du format avant l’envoi. Et le résultat arrive sous forme de liste contents, dont nous prenons le premier élément : le protocole autorise une réponse multi-contenus, mais nos ressources documentaires n’en renvoient qu’un.

Gérer les différents types de contenu

Nos ressources ne parlent pas toutes le même format : la liste des documents est du JSON, le contenu d’un document est du texte brut. Le serveur l’annonce via le type MIME déclaré sur chaque ressource — le client n’a qu’à le lire pour traiter correctement la réponse :

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

return resource.text

Les ressources JSON sont parsées en structures Python exploitables, tandis que les ressources en texte brut sont renvoyées telles quelles. 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 jamais connaître les détails de transport.

Tester l’implémentation

Cette méthode alimente la fonctionnalité de mentions du chatbot. Quand vous tapez @ suivi d’un nom de ressource dans le CLI, le système :

1. Affiche les ressources disponibles dans une liste d’auto-complétion
2. Permet de sélectionner une ressource avec les flèches et la touche espace
3. Inclut le contenu de la ressource directement dans le prompt envoyé à Claude

L’étape 1 appelle la ressource-liste (JSON), l’étape 3 la ressource-document (texte) — nos deux types en action. Résultat : Claude reçoit le contenu du document immédiatement, dans le même prompt que la question, sans avoir besoin d’appels d’outils supplémentaires. Aucun aller-retour tool_use/tool_result : la donnée était là avant même que le modèle ne commence à répondre.

Avantages par rapport aux outils

Ce chemin direct a des bénéfices mesurables : le contenu inclus directement dans les prompts réduit la latence — un tour de conversation au lieu de deux —, aucun appel API supplémentaire ne survient pendant la conversation, et l’expérience utilisateur y gagne l’auto-complétion, impossible à offrir avec un outil que Claude appelle à sa discrétion. S’y ajoute un bénéfice d’architecture : une séparation plus nette entre données statiques (servies par les ressources, pilotées par l’application) et opérations dynamiques (les outils, pilotés par le modèle).

La règle d’usage en découle : les ressources fonctionnent le mieux pour les informations relativement statiques que vous voulez rendre facilement accessibles — listes, documents, configurations. Dès que l’accès exige une décision du modèle ou produit un effet de bord, on retombe côté outils.

Points clés à retenir

• read_resource(uri) : le client récupère la donnée — Claude n’est pas dans la boucle
• Le type MIME annoncé par le serveur pilote le traitement : JSON parsé, texte brut tel quel
• La mention @ combine les deux ressources : liste pour l’autocomplétion, template pour le contenu
• Contenu injecté directement dans le prompt : moins de latence, pas d’aller-retour d’outil
• Ressources pour les données statiques à exposer ; outils pour les décisions et les effets de bord