Un agent qui « se souvient » de votre projet d'une session à l'autre ne se souvient de rien. Quelque chose lui a tendu un fichier, et il a lu le fichier. La question intéressante n'est pas comment le modèle stocke la connaissance, c'est qui décide de ce qui est transmis, et le Model Context Protocol répond à cette question dans une phrase que presque tout le monde saute.
La phrase qui tranche
La spécification MCP décrit les ressources, le mécanisme par lequel un serveur expose des données à un modèle, et elle énonce clairement leur intention de conception :
Les ressources dans MCP sont conçues pour être pilotées par l'application, les applications hôtes déterminant comment incorporer le contexte selon leurs besoins.
Lisez ce que cela attribue, et à qui. Le serveur propose. L'application hôte décide. Le modèle reçoit ce qui a survécu à cette décision.
La spécification refuse ensuite de normaliser la décision elle-même : les implémentations sont libres d'exposer les ressources via n'importe quel motif d'interface qui leur convient, et le protocole lui-même n'impose aucun modèle d'interaction utilisateur spécifique. Il suggère des possibilités, un sélecteur en arborescence ou en liste, un champ de recherche, ou une inclusion automatique fondée sur des heuristiques ou sur la sélection du modèle lui-même, sans en exiger aucune.
Ainsi, deux agents parlant le même protocole, connectés au même serveur, peuvent se retrouver avec des contextes complètement différents. Ce n'est pas un défaut. C'est le protocole qui refuse de prendre une décision produit à votre place.
Ce qu'est une ressource, concrètement
Une ressource est une donnée identifiée par une URI : un fichier, un schéma de base de données, une information propre à l'application. Les serveurs qui les prennent en charge doivent déclarer une capacité resources, et peuvent annoncer deux fonctionnalités optionnelles :
listChanged, si le serveur émet une notification quand la liste des ressources disponibles change.subscribe, s'il prend en charge les notifications de mise à jour pour des ressources précises qu'un client a demandé à surveiller.
Un serveur peut annoncer l'une, les deux, ou aucune. Les clients découvrent ce qui existe avec resources/list et lisent le contenu avec resources/read.
Une contrainte de la spécification mérite qu'on s'y arrête, car elle exclut toute une catégorie de conceptions astucieuses. L'ensemble des ressources qu'un serveur renvoie ne doit pas varier selon la connexion ni comme effet de bord d'autres requêtes sur la connexion. Il peut changer avec le temps, et il peut varier selon l'autorisation présentée dans la requête, puisque les identifiants sont une entrée par requête plutôt qu'un état de connexion.
Autrement dit : un serveur ne peut pas discrètement vous montrer un catalogue différent à cause de ce que vous avez demandé plus tôt dans la session. Ce qui varie, c'est ce que vos identifiants permettent, pas ce que votre historique suggère.
Les annotations sont la véritable politique de mémoire
S'il existe un endroit où la « mémoire » se décide, c'est bien ici. Les ressources portent des annotations optionnelles qui indiquent aux clients comment les utiliser :
audience: à qui le contenu est destiné,"user","assistant", ou les deux.priority: un nombre de 0.0 à 1.0. La spécification est inhabituellement directe sur les extrémités de cette échelle : 1 signifie le plus important, effectivement requis, tandis que 0 signifie le moins important, entièrement optionnel.lastModified: un horodatage ISO 8601.
Les clients s'en servent pour filtrer par audience, pour prioriser les ressources à inclure dans le contexte, et pour trier par fraîcheur.
C'est tout le mécanisme. Ce dont un agent « se souvient », c'est ce qui a obtenu un score assez élevé dans le champ de priorité de quelqu'un d'autre pour survivre au budget de contexte. Il n'y a pas de rappel, pas d'oubli, pas de consolidation. Il y a une liste classée et une limite.
Deux règles d'erreur qui révèlent la philosophie de conception
La gestion des erreurs de la spécification en dit long sur le sérieux avec lequel elle traite l'ambiguïté.
Une ressource manquante doit renvoyer une erreur JSON-RPC, code -32602. Et puis ceci : les serveurs ne doivent pas renvoyer un tableau contents vide pour une ressource inexistante, car un tableau vide est ambigu, il pourrait signifier que la ressource existe mais n'a pas de contenu, ou qu'elle n'existe pas du tout.
Un protocole qui prend la peine d'expliquer pourquoi un tableau vide est inacceptable est un protocole conçu par des gens qui ont débogué des agents. Le vide silencieux, c'est ainsi qu'un agent finit par raisonner avec assurance sur un fichier qu'il n'a jamais lu.
Les règles de sécurité dont vous héritez en l'utilisant
Parce que les ressources sont adressées par URI et correspondent souvent à des fichiers, la spécification impose des obligations explicites. Les serveurs doivent valider toutes les URI de ressources. Ils doivent assainir les chemins de fichiers pour empêcher les attaques par traversée de répertoires lorsqu'ils servent des ressources file://. Des contrôles d'accès devraient être mis en place pour les ressources sensibles, et les permissions devraient être vérifiées avant les opérations.
Ce ne sont pas des exigences exotiques, et c'est précisément le point. Exposer votre système de fichiers à un modèle via un protocole ne change rien à ce qu'est une traversée de chemin. Cela augmente seulement le nombre de mains sur la corde.
Ce que cela change dans votre façon de penser les agents
Cessez de demander ce dont le modèle se souvient. Demandez quelles ressources l'application hôte a décidé d'inclure, à quelle priorité, et sous quels identifiants. C'est toute la réponse, et elle réside dans l'application, pas dans le modèle.
La persistance est un fichier, pas une faculté. Un agent qui se rappelle vos conventions d'une session à l'autre lit un document que quelque chose a choisi d'exposer à nouveau. Changez l'exposition et la mémoire change, instantanément et totalement.
La priorité, c'est là que se fait la vraie conception. Un champ de 0.0 à 1.0 décide de ce qui survit à un contexte limité. Ce nombre, fixé par celui qui a écrit le serveur, façonne davantage le comportement de l'agent que la plupart des travaux de prompt engineering.
Le mot « mémoire » importe des attentes issues de la cognition humaine que le mécanisme ne soutient pas. Ce que MCP spécifie réellement, c'est un catalogue, une politique d'accès et un classement. Le savoir, c'est la différence entre concevoir délibérément le contexte d'un agent et se laisser surprendre par lui.
La description des ressources MCP présentée ici, y compris l'intention de conception pilotée par l'application, l'affirmation que le protocole n'impose pas de modèle d'interaction utilisateur, la capacité resources avec listChanged et subscribe, la contrainte selon laquelle l'ensemble des ressources ne doit pas varier selon la connexion alors qu'il peut varier selon l'autorisation, les annotations audience, priority et lastModified, le code d'erreur -32602, l'interdiction de renvoyer un tableau contents vide, ainsi que les exigences de validation des URI et d'assainissement des chemins, est tirée de la spécification du Model Context Protocol, vérifiée au moment de la rédaction. La spécification évolue ; vérifiez par rapport à la révision actuelle avant de vous fier à un détail précis.
