La spécification MCP 2026-07-28 supprime les sessions au niveau du protocole, déplace Tasks et MCP Apps dans un cadre d'extensions formel, durcit les règles OAuth et déprécie l'enregistrement dynamique de client au profit des Client ID Metadata Documents. PaidSync exploite en production un serveur MCP distant avec plus de 630 outils publicitaires sur 14 plateformes pour les clients Claude et ChatGPT, et voici nos notes de travail sur ce que chaque changement signifie depuis ce poste. Rien ne casse dès le premier jour ; les fonctionnalités dépréciées bénéficient d'une fenêtre minimale de douze mois.
Chaque affirmation sur le protocole ci-dessous provient de l'article de publication officiel et du changelog 2026-07-28, tous deux consultés au moment de la rédaction le 1er août 2026. Les opinions sont les nôtres. L'article de publication chiffre pourquoi cette révision compte : près d'un demi-milliard de téléchargements de SDK par mois sur les principaux SDK, les SDK TypeScript et Python dépassant chacun un milliard de téléchargements au total, et Honeycomb indiquant que près de 20 pour cent de ses requêtes interactives mensuelles proviennent désormais d'agents. L’article de The Register rapporte que les mainteneurs y voient la version la plus importante depuis le lancement de MCP distant. De là où nous sommes, c'est à peu près juste, et l'essentiel de l'importance est opérationnel plutôt que spectaculaire.
Ce qui a changé le 28 juillet
| Changement | De quoi il s'agit | Du point de vue de l'opérateur |
|---|---|---|
| Cœur sans état | Négociation initialize et Mcp-Session-Id supprimés ; _meta par requête porte la version et les capacités | Répartition de charge simple, sans sessions persistantes |
| Reprise supprimée | Les flux interrompus perdent la requête en cours ; les clients la renvoient | Les outils de modification exigent des clés d'idempotence |
| Extension Tasks | io.modelcontextprotocol/tasks officiel, par interrogation, saisie en cours d'exécution | Les longues opérations publicitaires cessent de se battre avec les délais d'attente des passerelles |
| MRTR | Les serveurs renvoient input_required au lieu d'appeler le client | Les questions en cours d'appel deviennent un état reprenable |
| Renforcement de l'authentification | Validation de iss selon la RFC 9207, identifiants liés à l'émetteur | Les attaques de confusion sur les flux de jetons sont fermées |
| DCR dépréciée | Les Client ID Metadata Documents remplacent l'enregistrement RFC 7591 | L'identité du client devient adossée à un domaine |
| MCP Apps | Extension officielle pour l'interface interactive intégrée | Graphiques et formulaires d'approbation dans l'interface de chat |
| En-têtes et mise en cache | Mcp-Method/Mcp-Name requis ; ttlMs sur les résultats de liste | Politique en périphérie par outil sans analyse du corps |
| Dépréciations | Roots, Sampling, Logging, HTTP+SSE, fenêtre minimale de douze mois | Un nettoyage avec un calendrier prévisible |
Le cœur sans état et le problème de la relance
Le changement phare : la négociation initialize/notifications/initialized disparaît, tout comme l'en-tête Mcp-Session-Id. Chaque requête porte désormais sa version de protocole, les capacités du client et l'identité du client dans _meta, et un nouveau RPC server/discover obligatoire permet aux clients de sonder les capacités dès le départ. Les notifications de changement du serveur vers le client sont regroupées dans un seul flux subscriptions/listen activable. L'effet pratique visé par les mainteneurs, et que The Register souligne, est que toute requête peut atteindre n'importe quelle instance du serveur derrière un répartiteur de charge ordinaire, avec des outils Kubernetes ordinaires, sans magasin de sessions partagé.
Voici le constat honnête d'un opérateur : la session de protocole n'a jamais été l'endroit où vivait notre état critique. Pour un serveur publicitaire, l'état qui compte, ce sont les autorisations OAuth, la sélection du compte publicitaire actif, les garde-fous de dépenses et les budgets de limites de débit par plateforme. Cet état se trouve dans une base de données indexée sur l'utilisateur authentifié, car il doit survivre à une connexion interrompue. Ce qu'ajoutait l'ancienne négociation, c'était une seconde session fragile qui pouvait mourir indépendamment de la vraie, et un déploiement ou un redémarrage du répartiteur coupait les sessions de protocole alors que les sessions d'authentification allaient bien. Supprimer cette couche élimine toute une classe de pannes déroutantes. Le remplacement prévu par la spec pour l'état légitime entre appels, ce sont des handles émis par le serveur et passés comme arguments d'outil ordinaires, ce qui correspond de toute façon à la lecture des flux publicitaires : sélectionner un compte, obtenir un handle, le transmettre. Signez-les et faites-les expirer, puisque n'importe quelle instance peut désormais les recevoir à froid.
Le hic, c'est le retry
Sous l’histoire du mode sans état se cache le changement le plus susceptible de provoquer des incidents avec de l’argent réel : la reprise des flux SSE et la redélivrance des messages sont supprimées. Avec 2026-07-28, un flux de réponse interrompu fait perdre la requête en cours, et le client doit la renvoyer comme une nouvelle requête avec un nouvel ID de requête. Pour get_campaign_performance, une nouvelle tentative ne coûte rien. Pour une création de campagne ou une mise à jour de budget, une nouvelle tentative à l’aveugle est exactement ce qui fait dépenser deux fois un agent. Si votre serveur modifie de l’argent, vos contrats d’outils ont besoin de clés d’idempotence et votre backend a besoin de déduplication, car le transport ne promet plus de redélivrer le résultat d’origine. Nos écritures déjà en production sont protégées par les indicateurs dry_run et confirm_destructive, ce qui limite l’impact, mais un garde-fou n’est pas une déduplication. Traitez-les comme deux contrôles distincts et mettez en place les deux.
Les tâches collent enfin à la pub
Tasks quitte le noyau expérimental et devient une extension officielle, io.modelcontextprotocol/tasks. La refonte remplace l’appel bloquant tasks/result par une interrogation régulière via tasks/get, ajoute tasks/update pour envoyer des données du client au serveur en cours de tâche, et permet aux serveurs de renvoyer des identifiants de tâche sans demande préalable, sans activation requête par requête. L’article de The Register met en avant la durabilité : les tâches sont adressées par des identifiants stables, si bien qu’un client peut conserver un ID de tâche et reprendre l’interrogation après un plantage ou un redémarrage.
Le travail publicitaire est long par nature. Un audit sur un MCC de 200 campagnes. Une mise en pause en masse sur les groupes d’annonces de toute une saison, le type de tâche pour lequel existe notre documentation sur les opérations en masse Meta. Une extraction de rapports multiplateformes sur 90 jours. Aujourd’hui, tout cela doit se terminer dans le délai imposé par le proxy placé devant votre serveur, et chaque déploiement en production en a un. Les tâches par interrogation s’accordent avec une infrastructure HTTP banale : pas de flux maintenu à surveiller, rien qu’un délai d’expiration en périphérie puisse couper en cours de route.
tasks/update est la partie discrètement importante pour la publicité en particulier. Une tâche qui accepte des données en cours d’exécution est une tâche qui peut s’arrêter avant sa partie destructive et poser la question. Aujourd’hui, une validation prend deux tâches : un essai à blanc, puis une confirmation explicite. Avec Tasks, le même schéma de sécurité peut tenir en une seule opération durable avec une pause humaine à l’intérieur, ce qui convient mieux aux agents qui planifient un travail en plusieurs étapes. La réserve est structurelle : les extensions sont désactivées par défaut et exigent une activation explicite des deux côtés, donc l’avantage ne viendra que lorsque Claude et ChatGPT proposeront la prise en charge côté client, pas avant.
MRTR remplace les requêtes serveur
Les requêtes initiées par le serveur (roots/list, sampling/createMessage, elicitation/create) sont remplacées par le modèle Multi Round-Trip Requests. Un serveur qui a besoin de plus d’informations renvoie un résultat avec resultType: "input_required" contenant ses questions ; le client relance la requête d’origine avec les réponses jointes dans inputResponses. Chaque résultat porte désormais un resultType obligatoire, et les résultats des serveurs de protocole antérieur qui l’omettent doivent être considérés comme complets, ce qui garde la cohérence des parcs en versions mixtes.
L’élicitation permettait à un serveur de demander « lequel de vos 14 comptes publicitaires voulez-vous dire ? » au milieu d’un appel. MRTR garde la question et inverse la mécanique. Le serveur ne peut plus garder une question en attente dans la mémoire du processus, car la nouvelle tentative peut arriver sur une autre instance ; tout le contexte dont la question a besoin va dans requestState. C’est pénible à intégrer après coup et juste par conception. Cela officialise aussi une leçon que tout serveur publicitaire distant apprend tôt : les clients de chat disparaissent sans cesse en pleine conversation, donc toute question en cours d’opération qui n’est pas reprenable finira par laisser une opération en suspens. Nous avons vu assez de parcours inachevés pour considérer que la spécification rattrape la réalité.
PaidSync est un serveur MCP distant pour le travail publicitaire. Plus de 630 outils sur 14 plateformes, un seul point d’accès, depuis Claude ou ChatGPT.
Voir le serveur MCP Essai gratuitL'autorisation, plus dure à rater
Trois durcissements, tous issus du journal des modifications. Les serveurs d’autorisation doivent inclure le paramètre iss dans les réponses d’autorisation selon la RFC 9207, et les clients doivent le valider par rapport à l’émetteur enregistré avant d’échanger un code. Les identifiants clients sont désormais explicitement liés au serveur d’autorisation qui les a émis : indexés par émetteur, jamais réutilisés d’un émetteur à l’autre, réenregistrés quand l’émetteur change. Et les clients doivent déclarer un application_type lors de l’enregistrement, ce qui corrige une catégorie ancienne de rejets de redirection localhost pour les agents CLI et de bureau. L’autorisation gérée par l’entreprise arrive aussi comme extension officielle, donnant aux organisations un contrôle centralisé sur les serveurs MCP que leurs agents peuvent utiliser.
Pourquoi c’est plus important pour les serveurs publicitaires que pour la plupart : un seul jeton d’accès à un serveur MCP publicitaire distant ouvre l’accès à de vrais comptes publicitaires sur Google, Meta et LinkedIn, avec de vrais budgets derrière. C’est exactement le genre de cible pour laquelle les attaques par confusion OAuth ont été inventées, et la validation de iss est la parade standard. La plupart des nouvelles obligations relèvent du code client, mais elles ne fonctionnent que si les serveurs publient des métadonnées d’autorisation exactes à valider. Pour mémoire, la base PaidSync livrée aujourd’hui comprend les métadonnées de serveur d’autorisation RFC 8414 et les métadonnées de ressource protégée RFC 9728 aux chemins well-known, un security.txt publié, une carte de serveur MCP et un manifeste d’authentification d’agent, ainsi que la révocation de session pour qu’un utilisateur puisse couper l’accès d’un client connecté à tout moment. C’est la révision stable actuelle, soigneusement mise en œuvre, et non une implémentation de 2026-07-28 ; nous le disons clairement, car lire une spécification n’est pas la livrer.
DCR sort, CIMD entre
L’enregistrement dynamique de clients (RFC 7591) est officiellement déprécié comme mécanisme d’enregistrement des clients MCP, au profit des Client ID Metadata Documents. Il reste disponible pour la rétrocompatibilité avec les serveurs d’autorisation qui n’ont pas encore migré. Avec le CIMD, le client_id est une URL HTTPS que l’opérateur du client contrôle, et le serveur d’autorisation récupère les métadonnées du client à cette URL.
Celui-là, nous l’aurions voté deux fois. Avec le DCR, chaque agent inconnu s’enregistrait seul dans votre serveur d’autorisation : des lignes anonymes, des noms auto-déclarés, aucune réputation, et une tâche de nettoyage périodique pour les enregistrements que personne n’a jamais utilisés. Le CIMD change la question à l’entrée : au lieu de « cet outil s’est-il enregistré ? », on demande « à qui appartient ce domaine ? ». Pour un serveur qui donne accès à des dépenses publicitaires, cette différence relève de la politique de sécurité. Elle rend possibles des listes d’autorisation de plateformes d’agents connues, et elle rend l’écran de consentement honnête : le nom de client qu’un utilisateur approuve s’appuie sur un domaine, au lieu d’être saisi par le client lui-même. Le conseil de migration va de soi : gardez le DCR fonctionnel pendant la période de dépréciation, privilégiez le CIMD pour chaque client qui en présente un, et commencez dès maintenant à rédiger la politique de confiance, car la politique est la partie difficile, pas l’analyse technique.
MCP Apps et les changements de plomberie
MCP Apps
MCP Apps arrive comme extension officielle dans le nouveau cadre d’extensions. La documentation des extensions la décrit comme un moyen pour les serveurs d’afficher des éléments d’interface interactifs, graphiques, formulaires, lecteurs vidéo, directement dans les conversations. Pour le travail publicitaire, les candidats sont évidents : une tendance des dépenses sous forme de vrai graphique plutôt que de tableau ASCII, un aperçu de campagne avant lancement, un formulaire de validation pour une modification en masse avec une case par campagne. Un formulaire de validation affiché est une surface de sécurité nettement meilleure qu’un « oui, je confirme » en texte libre. Même réserve que pour Tasks : activation des deux côtés, donc l’adoption par les clients donne le tempo.
En-têtes et mise en cache
Les requêtes POST Streamable HTTP doivent désormais porter les en-têtes Mcp-Method et Mcp-Name, afin que les passerelles puissent router et limiter le débit sans analyser le corps JSON. Avec 438 outils actifs sur notre serveur, une politique par outil en périphérie, des limites plus strictes sur les outils de modification, des règles WAF qui ne touchent jamais un corps de requête, est une capacité peu coûteuse que nous adopterons. Les résultats de liste (tools/list et consorts) doivent désormais porter ttlMs et cacheScope, ce qui signifie que les clients peuvent enfin cesser de recharger un gros catalogue d’outils à chaque tour. La spécification encourage aussi les serveurs à renvoyer les outils dans un ordre déterministe pour améliorer les succès du cache de prompts des LLM ; pour des catalogues de notre taille, c’est un levier direct sur le coût en jetons. Nous avons écrit sur le compromis de la taille du catalogue dans pourquoi le nombre d’outils est un atout.
Dépréciations avec échéance
Roots, Sampling et Logging sont dépréciés, tout comme l’ancien transport HTTP+SSE, dans le cadre d’un nouveau cycle de vie des fonctionnalités qui garantit une période de transition d’au moins douze mois. Rien de tout cela ne nous gêne. L’échantillonnage côté serveur a toujours été mal placé à une frontière de facturation, puisqu’il revient à faire dépenser par un serveur d’outils les jetons de modèle de quelqu’un d’autre ; la journalisation passe par stderr ou OpenTelemetry, ce que font déjà les serveurs de production. La politique de cycle de vie est elle-même un progrès : les retraits s’accompagnent désormais d’un calendrier sur lequel s’appuyer, au lieu d’une surprise.
Ce que cela ne change pas
En clair, pour ne pas trop interpréter
PaidSync n’a pas livré la révision 2026-07-28. Notre serveur de production parle le protocole stable actuel que parlent aujourd’hui les clients Claude et ChatGPT, et notre adoption suivra la leur, car une spécification que seul un côté parle n’est une spécification pour personne. Les calendriers de prise en charge côté client appartiennent aux éditeurs de ces clients, et nous ne les devinerons pas publiquement. Les extensions, dont Tasks et MCP Apps, sont désactivées par défaut et exigent une activation aux deux extrémités. Rien n’est supprimé dès le premier jour : les fonctionnalités dépréciées bénéficient d’une période minimale de douze mois et le DCR continue de fonctionner par rétrocompatibilité. Et la spécification corrige l’état du protocole, pas le jugement publicitaire. Les dépenses gaspillées, le suivi des conversions défaillant et les mauvais choix d’audience survivent à toute révision du protocole sans y changer rien ; cette couche est traitée dans repérer les dépenses publicitaires gaspillées avec l’IA.
Checklist de première semaine, agents
Si vous exploitez ou développez un serveur MCP distant, voici l’ordre dans lequel nous travaillerions, d’après notre expérience d’exploitation en production.
1. Auditez chaque outil de modification pour la sûreté des nouvelles tentatives. La reprise a disparu ; les clients renverront les requêtes perdues. Ajoutez des clés d’idempotence à tout outil qui crée ou modifie quelque chose ayant un coût financier.
2. Déplacez l’état inter-appels derrière des identifiants émis par le serveur. Tout ce qui vit en mémoire de processus, lié à une session de protocole, disparaît avec cette révision. Des identifiants passés en arguments d’outil, signés et à durée limitée.
3. Vérifiez vos métadonnées OAuth. La nouvelle validation de iss côté client et la liaison à l’émetteur ne fonctionnent qu’avec des documents well-known RFC 8414 et RFC 9728 exacts. Publiez-les, gardez-les justes.
4. Rédigez une politique de confiance CIMD. Décidez quels domaines de clients vous autoriserez et à quoi ressemble le repli DCR anonyme pendant la période de transition. La politique d’abord, le code ensuite.
5. Associez les outils longs à Tasks. Listez chaque outil qui peut dépasser le délai de votre passerelle, puis repérez ceux qui ont besoin de données en cours d’exécution, car ils deviendront des pauses de validation avec tasks/update.
6. Rendez tools/list déterministe et fixez des TTL honnêtes. Un ordre stable plus ttlMs représentent des économies de jetons gratuites pour chaque client doté d’un cache de prompts.
Gérez vos publicités depuis Claude ou ChatGPT via un seul point d’accès MCP. L’offre gratuite inclut 100 tâches par mois, d’une valeur de $50, sans carte bancaire.
Essai gratuit Voir les tarifsAjouter à ChatGPT : ouvrez PaidSync.ai dans l'annuaire des plugins de ChatGPT, installez-le, puis connectez-vous.
Ajouter à Claude : ouvrez PaidSync.ai dans l'annuaire des connecteurs de Claude, cliquez sur Connecter, puis connectez-vous.
Questions fréquentes
Qu'est-ce qui a changé dans la spécification MCP 2026-07-28 ?
La révision rend MCP sans état : la poignée de main initialize et l’en-tête Mcp-Session-Id sont supprimés, chaque requête porte sa version de protocole et les capacités du client dans _meta, et un nouvel appel RPC server/discover annonce les capacités du serveur. La reprise des flux SSE est supprimée, donc un flux interrompu implique de renvoyer les requêtes. Tasks passe du noyau expérimental à une extension officielle avec tasks/get par interrogation et saisie en cours d’exécution via tasks/update. Les Multi Round-Trip Requests remplacent les appels d’élicitation, d’échantillonnage et de roots initiés par le serveur. L’autorisation est renforcée par la validation de iss selon la RFC 9207 et des identifiants liés à l’émetteur. L’enregistrement dynamique de clients est déprécié au profit des Client ID Metadata Documents. Roots, Sampling, Logging et HTTP+SSE sont dépréciés avec une période minimale de douze mois. Source : le journal des modifications officiel, consulté le 1 août 2026.
La spec 2026-07-28 casse-t-elle les serveurs MCP existants ?
Pas dès le premier jour. La version adopte un cycle de vie formel des fonctionnalités avec une période de dépréciation d’au moins douze mois, le DCR reste fonctionnel par rétrocompatibilité, et les clients doivent considérer comme complets les résultats des serveurs de protocole antérieur qui omettent le nouveau champ resultType. Le changement qui mérite une attention immédiate concerne les nouvelles tentatives : la reprise et la redélivrance des messages sont supprimées, donc un client qui perd un flux de réponse renvoie la requête. Les serveurs qui exposent des outils de modification, comme la création de campagne ou les changements de budget, doivent ajouter des clés d’idempotence pour qu’une écriture renvoyée ne s’applique pas deux fois.
Qu'est-ce qui remplace l'enregistrement dynamique de client dans MCP ?
Client ID Metadata Documents (CIMD). Au lieu de s’enregistrer seul auprès de chaque serveur d’autorisation selon la RFC 7591, un client utilise comme client_id une URL HTTPS qu’il contrôle, et le serveur d’autorisation récupère les métadonnées du client à cette URL. L’identité devient vérifiable et adossée à un domaine, ce qui permet aux opérateurs de serveurs de définir des listes d’autorisation pour les plateformes d’agents connues et d’afficher des écrans de consentement adossés à un domaine plutôt qu’à un nom auto-déclaré. Le DCR est déprécié mais reste disponible pour les serveurs d’autorisation qui ne prennent pas encore en charge le CIMD.
PaidSync implémente-t-il déjà la spec MCP 2026-07-28 ?
Non. Le serveur MCP de production de PaidSync fonctionne avec le protocole stable actuel que parlent aujourd’hui les clients Claude et ChatGPT. La base livrée comprend les métadonnées de serveur d’autorisation RFC 8414 et les métadonnées de ressource protégée RFC 9728 à des points d’accès well-known, un security.txt et une carte de serveur MCP publiés, la révocation de session, et des écritures protégées par les indicateurs dry_run et confirm_destructive. L’adoption de la nouvelle révision suivra la prise en charge côté client dans Claude et ChatGPT.