Le journal des changements de MCP 2026-07-28 confirme le mécanisme de notification concerné par cet article : voir la documentation officielle de la version 2026-07-28.

Symptôme : un serveur publie bien la modification, mais le Client qui écoute sur une autre instance ne reçoit rien.
Solution la plus rapide : gardez une notification en mémoire en mono-processus ; dès que le producteur et le flux vivent dans des processus différents, ajoutez une voie de notification interprocessus et prévoyez une relecture après reconnexion.

Cet article s’adresse aux développeurs de Server qui modifient dynamiquement des listes de tools, resources ou prompts, aux équipes plateforme qui distribuent des flux persistants entre plusieurs instances, ainsi qu’aux équipes Agent chargées de la reprise après coupure, de l’invalidation du cache et des tests de compatibilité.

Dernière mise à jour : 5 septembre 2026. Les éléments de protocole ont été vérifiés dans la spécification MCP 2026-07-28 et confrontés aux documentations officielles des SDK et du transport Streamable HTTP citées dans l’article.

Le choix dépend d’abord du lieu où vivent les deux extrémités

Le point déterminant n’est pas le nombre de Clients, ni le choix d’un produit de messagerie. Il faut localiser deux fonctions :

  • le composant qui détecte ou publie la modification ;
  • le processus qui garde ouvert le flux subscriptions/listen.

Si ces fonctions sont dans le même processus, une notification en mémoire suffit généralement pour transmettre un signal. Si elles sont séparées par un Worker, un processus enfant, un répartiteur ou une autre instance, cette mémoire locale ne peut pas franchir la frontière toute seule.

Organisation Où est publié le changement ? Où vit le flux du Client ? Décision initiale
Prototype local Même processus Même processus Notification en mémoire
Serveur mono-instance Même runtime ou Worker partagé Même runtime Médiateur interne, sans composant externe au départ
Plusieurs Workers Processus producteur variable Processus détenteur variable Bus interprocessus ou route déterministe
Plusieurs instances derrière répartiteur N’importe quelle instance Une autre instance possible Chemin partagé obligatoire
Client ancien ou partiellement compatible Serveur moderne Client sans écoute complète Relecture de compatibilité et vérification des capacités

Cette séparation évite une erreur fréquente : construire immédiatement un système distribué pour un prototype, ou conserver un événement local alors que le trafic est déjà réparti. Dans les deux cas, le problème n’est pas seulement technique. Vous augmentez soit la surface d’exploitation, soit le risque de vues obsolètes côté Client.

Mono-processus : la chaîne minimale reste la meilleure première étape

Pour un Server exécuté dans un seul processus, le modèle le plus lisible est court : une modification met à jour l’état canonique, publie un signal local, puis le gestionnaire du flux décide quels abonnés doivent le recevoir. La notification n’a pas besoin de contenir toute la liste modifiée si le Client peut la relire ensuite.

Votre validation doit alors porter sur le comportement observable :

  • l’abonnement est-il confirmé avant l’envoi d’un changement ?
  • un événement destiné aux outils n’est-il pas envoyé aux abonnés qui ne suivent que les ressources ?
  • la fermeture du flux retire-t-elle réellement l’abonné de la mémoire ?
  • une nouvelle écoute permet-elle de retrouver l’état courant ?
  • une modification sans abonné reste-t-elle sans fuite de tâche ou de file interne ?

Les exemples du SDK officiel côté Client pour les abonnements et du SDK officiel côté serveur doivent être lus comme des indications d’implémentation de ce SDK, non comme une promesse que chaque langage expose exactement les mêmes fonctions auxiliaires.

Rappel d’architecture : subscriptions/listen est un mécanisme de signalement. Il ne remplace ni votre source de vérité, ni votre stratégie de cache, ni un journal persistant des événements.

Dans cette configuration, le meilleur investissement consiste à ajouter des identifiants de connexion et des journaux structurés. Enregistrez le type de changement, l’abonné visé, l’instance d’exécution et le résultat de l’écriture dans le flux. Vous pourrez ainsi distinguer un événement jamais publié d’un événement publié mais filtré.

Plusieurs Workers : prouvez le passage de frontière avant de généraliser

Un serveur qui semble « mono-instance » peut déjà être multi-processus. Un serveur Web lancé avec plusieurs Workers, un pool de requêtes ou un runtime qui recrée des processus sépare parfois le producteur de l’événement du détenteur du flux. Une variable globale ou une file en mémoire ne traverse alors pas cette frontière.

La méthode de diagnostic doit rester expérimentale :

  • donnez à chaque processus une identité visible dans les journaux ;
  • ouvrez le flux depuis un Client et notez l’identité du processus qui le conserve ;
  • déclenchez une modification depuis un autre processus ;
  • vérifiez la réception au niveau du bus applicatif ;
  • vérifiez ensuite l’écriture dans la réponse HTTP ;
  • enfin, observez ce que le Client reçoit réellement.

Cette séquence localise la perte au lieu d’accuser immédiatement le protocole. Si le producteur voit l’événement mais que le processus détenteur du flux ne le voit pas, votre bus local est insuffisant. Si les deux processus le voient mais que le Client ne reçoit rien, examinez le proxy, le tamponnement ou le filtrage du flux.

Le guide de configuration du serveur d’exécution rappelle notamment que le mode de lancement et la gestion des processus influencent directement le comportement d’un service long. Ne déduisez donc pas le comportement d’un test local lancé avec une seule instance à partir d’une production où les requêtes sont réparties.

Test ciblé Résultat attendu Interprétation en cas d’échec
Publication et écoute dans le même processus Le flux reçoit le signal Le gestionnaire de souscription ou le filtre est incorrect
Publication dans un autre processus Le détenteur du flux reçoit le signal Le bus local ne traverse pas la frontière
Événement visible par le serveur, absent du Client Le proxy transmet le flux Tampon, délai d’inactivité ou encodage à examiner
Reconnexion après fermeture Le Client recrée l’écoute et relit l’état La reprise n’est pas implémentée ou reste dépendante d’un événement perdu

Il est souvent raisonnable de réduire le nombre de Workers pendant la phase de développement, puis de réintroduire la concurrence uniquement après avoir ajouté ce test interprocessus. Cette démarche ne signifie pas que le mono-processus est une architecture de production universelle ; elle évite simplement de confondre une optimisation de capacité avec une exigence du protocole.

Multi-instances : partagez le signal, pas une fausse promesse de relecture

Derrière un répartiteur, l’instance qui reçoit la modification d’un catalogue d’outils peut être différente de celle qui conserve le flux du Client. Une notification en mémoire sur l’instance A ne touche pas automatiquement le flux ouvert sur l’instance B.

Il faut alors une voie partagée qui transporte le changement vers les instances intéressées. Sa responsabilité doit être définie avec précision :

  • diffuser qu’une ressource, un outil ou une invite a changé ;
  • permettre à l’instance qui détient le flux de notifier son Client ;
  • fournir, si votre architecture le prévoit, une indication de version ou de génération ;
  • ne pas être présenté comme un journal durable si aucune conservation ni relecture n’est garantie.

Cette distinction est essentielle. Un bus de notification réduit la probabilité de manquer un signal entre instances, mais il ne transforme pas subscriptions/listen en système d’événements rejouables. Si le flux tombe avant la livraison, si l’instance redémarre ou si le Client ne comprend pas la notification, la cohérence doit être restaurée par une nouvelle lecture de la donnée actuelle.

Le transport Streamable HTTP dans une implémentation officielle montre pourquoi il faut séparer le transport de la logique de diffusion. Le transport garde et écrit une communication HTTP ; il ne décide pas, à votre place, comment toutes les instances connaissent une modification produite ailleurs.

Responsabilité Mono-instance Multi-instance
Détecter la modification État local ou service applicatif Service applicatif avec identité d’instance
Diffuser le signal Médiateur en mémoire Bus partagé entre processus ou instances
Servir la donnée exacte Lecture du magasin canonique Lecture du magasin canonique, jamais du seul signal
Reprendre après coupure Recréer l’écoute et relire Recréer l’écoute, relire et contrôler la version
Prouver la livraison Journal local Corrélation producteur, bus, proxy et Client

Pour une plateforme qui propose du contenu créatif, cette règle concerne aussi les usages audio, vidéo et design : une liste d’outils qui change peut modifier les capacités disponibles pour une session de montage, de génération ou de contrôle de fichiers. Une interface qui affiche un outil disparu n’est pas seulement moins agréable ; elle peut provoquer un appel refusé ou une opération effectuée avec un mauvais paramètre.

Le Client doit traiter la reconnexion comme une nouvelle synchronisation

Il est risqué de penser qu’une coupure sera réparée par le seul transport. Après une fermeture du flux, un redémarrage d’instance ou un remplacement lors d’une mise à jour, le Client doit :

  • détecter la fin du flux et supprimer l’état de connexion devenu invalide ;
  • recréer la session ou le canal requis par son implémentation ;
  • renouveler l’abonnement ;
  • relire les outils, ressources ou invites concernés ;
  • remplacer son cache avec la réponse complète ;
  • reprendre les appels uniquement après validation de la nouvelle vue.

Cette séquence est préférable à une logique qui attendrait « l’événement manquant ». La notification indique qu’il faut vérifier l’état ; elle ne constitue pas nécessairement le contenu de la modification. Si le Client conserve une ancienne liste et reçoit seulement un signal partiel, il peut croire à tort qu’il est synchronisé.

Les capacités doivent aussi être vérifiées côté compatibilité. Le journal de migration du SDK officiel montre que les API auxiliaires peuvent évoluer indépendamment de la formulation générale du protocole. Un Client ancien peut donc comprendre une partie de la session sans savoir écouter une liste dynamique. Dans ce cas, prévoyez une lecture à la demande, une actualisation périodique ou une désactivation explicite de la fonction dynamique.

FAQ : les points qui bloquent en exploitation

Pourquoi les notifications subscriptions/listen n’arrivent-elles pas sur toutes les instances ?

Parce que l’instance qui publie la modification n’est pas nécessairement celle qui conserve le flux du Client. Une notification gardée en mémoire reste locale au processus. En environnement distribué, il faut donc une voie interprocessus, puis vérifier que le répartiteur, le proxy et le Client ne filtrent pas ou ne perdent pas le message.

Faut-il obligatoirement une file de messages pour un flux de notifications MCP ?

Non. Un serveur mono-processus peut utiliser une structure en mémoire si le producteur et le flux subscriptions/listen vivent dans le même contexte d’exécution. Un composant partagé devient nécessaire lorsque plusieurs processus ou instances doivent recevoir le même signal. Ce composant distribue une évolution ; il ne devient pas automatiquement un journal durable.

Les événements sont-ils rejoués après une coupure subscriptions/listen ?

Vous ne devez pas le supposer. La notification signale un changement, mais elle ne garantit pas une relecture complète des événements manqués. Après une perte de connexion, le Client doit recréer l’écoute puis relire la liste d’outils, l’état des ressources ou les invites concernées afin de reconstruire une vue cohérente.

Comment un ancien Client MCP peut-il recevoir les changements de liste ?

Commencez par vérifier les capacités réellement annoncées et les fonctions disponibles dans son SDK. Si subscriptions/listen n’est pas pris en charge, conservez une voie de compatibilité fondée sur une relecture périodique ou à la demande. Le serveur ne doit pas considérer une notification non comprise comme une preuve que le cache du Client est à jour.

Un proxy inverse peut-il interrompre un flux de notifications MCP ?

Oui. Le tampon de réponse, le délai d’inactivité, l’arrêt gracieux et le remplacement d’une instance peuvent couper un flux long ou retarder la livraison. Testez le chemin complet avec le même proxy que la production, envoyez une modification après l’établissement du flux, puis vérifiez la reconnexion et la relecture côté Client.

Le proxy et le runtime doivent être testés comme des composants du protocole

Un flux HTTP long peut fonctionner parfaitement en accès direct et échouer une fois placé derrière un proxy inverse. Les règles de flux SSE documentées par MDN donnent le cadre général du transport événementiel, mais elles ne configurent pas votre chaîne de production.

Votre protocole de test doit couvrir les cas suivants :

  • réponse conservée ouverte après l’établissement du flux ;
  • événement réellement transmis, et non simplement écrit dans un tampon serveur ;
  • délai d’inactivité suffisamment contrôlé pour distinguer silence normal et coupure ;
  • arrêt gracieux pendant qu’un Client écoute ;
  • remplacement d’une instance par déploiement progressif ;
  • reconnexion sur une instance différente ;
  • relecture complète avant la reprise des appels dépendants.

Ajoutez un identifiant de corrélation à la session, au message publié et à la réponse observée par le Client. Sans cette corrélation, vous ne saurez pas si le problème vient du bus, du runtime, du répartiteur ou du cache local.

Expérience à retenir : un test « le serveur a écrit l’événement » ne prouve pas que le Client l’a reçu. La preuve utile se situe au dernier maillon, après le proxy et après le décodage côté Client.

Matrice de décision pour choisir votre architecture

Utilisez cette matrice avant d’introduire une dépendance externe. Elle sépare la forme de déploiement, la responsabilité de reprise et le chemin compatible avec un Client ancien.

Équipe ou environnement Architecture recommandée Bus de notification Test à imposer Chemin de compatibilité
Prototype local Un processus, état canonique local Non, médiateur en mémoire Confirmation, filtrage, fermeture, relecture Lecture manuelle
Production sur une machine Un runtime stable, flux et publication rapprochés Pas nécessaire si aucune frontière de processus Redémarrage et reconnexion Actualisation à la demande
Plusieurs Workers Producteur et flux identifiés par processus Oui si les processus peuvent diverger Publication croisée entre Workers Relecture après reconnexion
Plusieurs nœuds Instances interchangeables derrière répartiteur Oui, voie partagée Coupure, bascule, déploiement progressif Relecture complète et contrôle de version
Client hétérogène Serveur moderne avec négociation de capacités Selon le nombre d’instances Test par version de Client Polling ou lecture à la demande

La note à retenir est simple : ne choisissez pas un bus parce que subscriptions/listen l’imposerait. Choisissez-le parce que votre topologie crée une frontière que la mémoire locale ne peut pas franchir. À l’inverse, ne supprimez pas la relecture parce qu’un bus partagé existe ; le bus transporte un signal, tandis que la source canonique restitue la vérité.

Pour préparer ce type d’essai sans mobiliser immédiatement votre infrastructure principale, vous pouvez utiliser une location de Mac mini pour environnement de test, puis documenter la topologie exacte dans votre procédure. Si l’observation visuelle du flux est nécessaire, l’accès VNC à distance peut compléter les journaux, mais il ne remplace pas les assertions automatisées du Client.

Le bon compromis dépend de votre phase de déploiement

En phase de conception, commencez par une implémentation mono-processus instrumentée. Elle permet de vérifier le contrat fonctionnel sans introduire la complexité d’un système de diffusion. Lorsque vous activez plusieurs Workers, reproduisez le scénario avec des identifiants de processus différents. Lorsque vous passez à plusieurs instances, ajoutez le bus puis testez séparément la livraison et la relecture.

Pour un service qui publie fréquemment des outils ou des ressources, stockez la version courante dans la source de vérité et faites de la notification une demande de rafraîchissement. Cette approche facilite aussi la gestion du cache : l’invalidation peut être déclenchée par le signal, mais le contenu du cache doit être remplacé par une lecture validée.

Si votre solution actuelle repose sur une seule machine sans chemin partagé, elle devient fragile dès qu’un répartiteur peut envoyer le flux et la modification à deux processus distincts. Si elle dépend uniquement d’un événement en mémoire, elle ne résiste pas à un redémarrage. Si elle attend du proxy qu’il conserve indéfiniment la connexion, elle confond transport et garantie métier. Pour une phase de test, une démonstration audio ou vidéo, ou la validation d’un Client MCP multi-instance, louer un environnement Mac avec SSHMac peut offrir un cadre plus contrôlable que l’achat immédiat d’une machine dédiée : vous testez la topologie nécessaire, observez les coupures réelles et ne financez pas une capacité permanente avant de savoir si votre architecture exige réellement plusieurs nœuds.