Accéder aux ressources

Les outils MCP répondent à une logique de demande : Claude décide qu’il lui manque une information, l’appel part, le résultat revient. Les ressources fonctionnent à l’inverse — ce sont des données que le client choisit d’injecter directement dans le contexte du prompt, avant même que la conversation ne commence. Un document de référence, la liste des fichiers disponibles, une configuration : autant de contenus que Claude n’a pas besoin de « demander », puisqu’ils sont déjà sous ses yeux. Cette leçon implémente la lecture de ressources côté client.

Implémentation de la lecture de ressources

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]

La lecture s’articule autour de l’URI de la ressource — l’identifiant du type docs://documents/report.pdf que le serveur a déclaré. Le passage par AnyUrl n’est pas une coquetterie : Pydantic valide la forme de l’URI avant l’envoi, ce qui intercepte à la source les identifiants malformés au lieu de laisser le serveur échouer avec une erreur moins lisible. La réponse arrive sous forme d’une liste contents ; nous prenons le premier élément, cas de loin le plus courant pour une ressource unique.

Gérer les différents types de contenu

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

Le tri se fait en deux temps. Le isinstance distingue d’abord les contenus textuels des autres types possibles. Puis, au sein du texte, le type MIME déclaré par le serveur guide le traitement : une ressource application/json est parsée en structure Python exploitable — dictionnaire ou liste — tandis qu’un texte brut est retourné tel quel. C’est le serveur qui annonce le type, le client qui en tire les conséquences : cette répartition des rôles évite au client de deviner le format en inspectant le contenu, pratique fragile par excellence.

Ressources vs outils

Savoir lire les ressources amène naturellement la question d’architecture : quand exposer une donnée en ressource plutôt qu’en outil ? Le critère central est qui décide de l’accès. La ressource se prête aux contenus statiques ou semi-statiques fréquemment référencés — la liste des documents, un glossaire, une charte : le client les injecte d’office, le contenu est immédiatement disponible dans le contexte sans coûter un aller-retour d’appel d’outil. C’est aussi un gain économique direct : chaque appel d’outil évité, c’est un tour de conversation en moins.

L’outil reprend l’avantage dès que l’accès devient une décision : opérations dynamiques, recherches paramétrées, données volumineuses dont seule une fraction sera utile. Là, c’est à Claude de juger, selon le fil de la conversation, s’il a besoin de l’information — l’injecter d’office gonflerait le contexte pour rien. En pratique, les bons serveurs MCP combinent les deux : les ressources posent le décor, les outils permettent d’agir dedans.

Points clés à retenir

• Les ressources injectent des données dans le contexte à l’initiative du client ; les outils répondent aux demandes de Claude
• read_resource lit par URI, validé par AnyUrl avant envoi
• Le type MIME déclaré par le serveur guide le traitement : JSON parsé, texte brut tel quel
• Ressource pour le statique fréquemment référencé, outil pour le dynamique et le volumineux
• Chaque ressource injectée d’office économise un aller-retour d’appel d’outil