Anthropic, Simon Willison et le revirement du MCP sans état

Anthropic a introduit MCP en 2024, mais Simon Willison a ensuite jugé les outils en ligne de commande plus flexibles. La spécification du 28 juillet 2026 a désormais inversé une partie de ce constat. Elle supprime les sessions de protocole et transforme les appels MCP distants en requêtes autonomes.

Ce changement a ravivé l’intérêt de Willison et inspiré deux projets, mcp-explorer et datasette-mcp. Plus important encore, il s’attaque à la faiblesse architecturale qui rendait les serveurs MCP distants plus difficiles à déployer que des services HTTP ordinaires.

L’histoire entre Anthropic et Simon Willison n’est donc pas une simple mise à jour de protocole. Elle permet de déterminer si MCP peut cesser de concurrencer les outils en ligne de commande et trouver un rôle plus défendable. Les Skills restent attrayants pour apprendre aux agents à utiliser des logiciels existants, tandis que MCP sans état propose des outils distants structurés, la découverte, l’autorisation et une infrastructure partagée.

Le MCP sans état supprime la session de chaque chemin de requête

La nouvelle spécification transforme MCP : d’un protocole centré sur la connexion, il devient un protocole centré sur la requête.

Le Model Context Protocol définit une interface standard permettant aux agents IA de découvrir et d’appeler des outils externes. Anthropic l’a introduit en novembre 2024, et les développeurs ont rapidement créé des serveurs pour des bases de données, des navigateurs, des plateformes de communication et des applications métier.

Les versions antérieures imposaient un processus d’initialisation avant les appels d’outils habituels. Le client et le serveur échangeaient leurs versions de protocole, leurs capacités et leurs informations d’identification. Cette négociation établissait un contexte que les messages suivants devaient préserver.

Les serveurs HTTP pouvaient aussi émettre un Mcp-Session-Id. Les clients renvoyaient alors cet identifiant avec les requêtes ultérieures. Ce mécanisme faisait qu’une série d’appels se comportait comme une conversation continue entre un client précis et une instance de serveur donnée.

Cette conception entraînait des conséquences pour l’infrastructure. Un équilibreur de charge devait orienter les appels liés vers la bonne instance ou placer les données de session dans un stockage partagé. Les opérateurs devaient aussi définir des politiques d’expiration, de reconnexion, de récupération et de nettoyage.

La révision finale 2026-07-28 supprime l’échange obligatoire initialize. Elle supprime également la session au niveau du protocole et l’en-tête associé. Chaque requête inclut désormais les informations nécessaires à son interprétation indépendante.

La publication officielle de MCP décrit cette révision comme le plus grand changement depuis le lancement du protocole. Son cœur sans état s’accompagne d’extensions, d’une prise en charge révisée des Tasks, de modifications de l’autorisation et d’un cycle de vie formel des fonctionnalités.

Un client peut désormais envoyer directement un appel d’outil. La requête contient sa version de protocole, sa méthode, le nom de l’outil, les informations sur le client et les capacités pertinentes. Toute instance de serveur compatible peut la traiter sans dépendre d’un échange antérieur.

Le changement ajoute également server/discover, qui permet aux clients de demander les capacités du serveur lorsque nécessaire. La découverte n’oblige plus chaque appelant à créer et maintenir une session de protocole.

Cela ne signifie pas que chaque application doit abandonner tout état. Un service d’automatisation de navigateur, un panier d’achat, une transaction de base de données ou un workflow de recherche peuvent toujours conserver des informations entre les appels.

La différence tient à l’emplacement de ces informations et à la manière dont elles sont adressées. Au lieu de les masquer derrière une session, le serveur peut renvoyer un identifiant explicite. Le modèle fournit cet identifiant lors des appels ultérieurs.

Un serveur de navigateur peut renvoyer un browser_id après le démarrage d’une instance. Les outils ultérieurs peuvent accepter cette valeur pour naviguer, capturer une page ou fermer le navigateur. Un outil de base de données peut appliquer le même modèle à un identifiant de transaction.

La proposition sans session acceptée décrit ces valeurs comme des poignées d’état explicites. Il ne s’agit pas d’un nouveau type de données MCP. Ce sont des entrées et sorties d’outils ordinaires qui rendent l’état de l’application visible.

Cette visibilité est importante pour les agents. Un orchestrateur peut partager une poignée avec un sous-agent tout en en isolant une autre. Il peut également enregistrer l’identifiant pour un travail ultérieur ou le transmettre à un autre processus autorisé.

Les opérations de liste bénéficient d’un avantage distinct. Lorsque les outils et les ressources ne peuvent plus changer selon une session ambiguë, les clients peuvent mettre en cache les résultats de découverte plus sûrement. Cela réduit les appels répétés entre des agents éphémères.

Le MCP sans état s’intègre aussi plus naturellement aux opérations HTTP courantes. Les serveurs distants peuvent utiliser un équilibrage round-robin standard, un routage de passerelle classique, une authentification par requête et des systèmes d’observabilité établis.

C’est cette combinaison qui a renouvelé l’attention de Willison. La mise à jour ne se contente pas de raccourcir l’échange initial. Elle supprime un engagement architectural qui se répercutait auparavant dans chaque déploiement et chaque implémentation cliente.

Pourquoi le revirement d’Anthropic et Simon Willison est important

L’intérêt renouvelé de Willison importe parce que sa critique précédente reflétait un véritable éloignement de MCP parmi les utilisateurs d’agents de programmation.

MCP a suscité une attention intense pendant une grande partie de 2025. Sa proposition de valeur était facile à comprendre : implémenter une interface de serveur unique, puis exposer les mêmes outils à plusieurs clients IA compatibles.

Pourtant, les agents de programmation progressaient au même moment. Ils ont acquis un accès fiable au terminal, une meilleure utilisation du shell et de plus solides capacités d’inspection de la documentation. Beaucoup pouvaient installer une bibliothèque ou appeler une API classique avec curl.

Cela a créé un défi direct. Un programme en ligne de commande bien documenté offre déjà une interface d’outils composable. L’agent peut combiner des commandes, rediriger la sortie, écrire de petits scripts et examiner les erreurs sans adaptateur de protocole.

Les Skills ont renforcé cette voie. Un skill est un ensemble d’instructions, de scripts et de références qui apprend à un agent à effectuer une tâche. Il peut expliquer une API existante sans exiger de son propriétaire qu’il exploite un serveur MCP.

Willison a résumé son scepticisme dans son bilan de 2025. Pour les agents de programmation, il préférait les utilitaires en ligne de commande et les bibliothèques à MCP. Ces options donnaient davantage de liberté au modèle tout en évitant une couche de service supplémentaire.

La critique n’a jamais été que les appels d’outils structurés n’avaient aucune valeur. La question plus difficile était de savoir si MCP apportait suffisamment de valeur supplémentaire pour justifier les sessions, la gestion des transports, le travail de compatibilité côté client et la surcharge de contexte.

Le MCP sans état réduit cet écart. Un petit outil distant peut désormais se comporter davantage comme un point de terminaison web conventionnel, tout en préservant un contrat lisible par machine pour les clients agents.

L’analyse de Willison sur le MCP sans état relie ce changement à deux expérimentations. La première est mcp-explorer, conçue pour faciliter l’inspection et la compréhension des serveurs MCP. La seconde est datasette-mcp, qui applique la nouvelle approche à Datasette.

Datasette est le système open source de Willison destiné à explorer et publier des données structurées. Il expose déjà les bases de données via des interfaces web et des API. MCP offre une autre surface, conçue spécifiquement pour les modèles de langage utilisant des outils.

Cette association est éclairante. Un déploiement Datasette est naturellement distant, structuré et partagé entre les utilisateurs. Il s’adapte moins facilement au modèle local en ligne de commande qu’un utilitaire de développement installé à côté d’un agent.

Un serveur MCP peut annoncer des outils de base de données à l’aide de schémas compris par les clients. Les agents peuvent examiner les opérations disponibles avant d’envoyer des requêtes. Les opérateurs de serveurs conservent le contrôle de l’authentification, des autorisations, des limites et des détails d’implémentation.

Cela rend la comparaison entre Anthropic et Simon plus nuancée que MCP contre Skills. Un skill peut apprendre à un agent à interroger une API. MCP peut fournir à de nombreux clients un contrat partagé pour découvrir et invoquer cette API.

Les deux approches peuvent aussi fonctionner ensemble. Un skill peut décrire quand utiliser un serveur MCP, expliquer ses concepts métier ou fournir un workflow couvrant plusieurs outils. MCP peut gérer la frontière d’exécution distante.

Cette répartition réduit la pression sur MCP pour qu’il devienne la réponse universelle à chaque action d’agent. Les commandes locales peuvent rester locales. Les bibliothèques peuvent servir les tâches de programmation flexibles. Les Skills peuvent regrouper le savoir-faire opérationnel.

MCP acquiert un rôle plus clair lorsque le serveur contrôle l’exécution et que plusieurs clients ont besoin de la même interface découvrable. Les données d’entreprise, la recherche hébergée, les services partagés et les systèmes métier authentifiés correspondent à ce modèle.

La simplicité du protocole modifie donc la question concurrentielle. Les développeurs n’ont plus besoin de se demander si chaque outil mérite un wrapper MCP. Ils peuvent se demander si une capacité distante bénéficie d’une découverte et d’une invocation standardisées.

C’est une promesse plus modeste que les interprétations initiales les plus ambitieuses de MCP. Elle est aussi plus crédible. Les standards deviennent souvent utiles une fois leurs limites mieux définies.

Les requêtes sans état permettent à MCP de s’adapter aux infrastructures cloud ordinaires

MCP 2.0 est important parce qu’il supprime la coordination spécialisée du chemin de déploiement courant.

La proposition sans état acceptée identifie trois problèmes du précédent modèle d’initialisation. Les sessions compliquaient la montée en charge, fragilisaient la récupération après incident et augmentaient le travail d’implémentation des deux côtés.

Prenons un outil de recherche distant exécuté sur trois instances de serveur. Dans une conception orientée session, les appels ultérieurs pouvaient nécessiter la même instance que celle ayant traité l’initialisation. Un équilibreur de charge round-robin élémentaire ne peut pas garantir ce résultat.

Les opérateurs peuvent résoudre ce problème avec un routage persistant. Ils peuvent aussi stocker les données de session dans un service partagé. Ces deux approches introduisent un état opérationnel, des modes de défaillance supplémentaires et de nouvelles exigences de supervision.

Les sessions persistantes peuvent répartir le travail de manière inégale. Les stockages partagés créent une dépendance supplémentaire. Les redémarrages de serveurs peuvent invalider l’état local, tandis que les clients doivent détecter les défaillances et répéter l’initialisation.

Avec le nouveau modèle de requête, toute instance saine peut traiter un appel d’outil compatible. La passerelle peut router selon la méthode et les métadonnées de l’outil plutôt que selon l’historique de connexion.

Ce changement rend également le déploiement serverless plus plausible. Les plateformes qui démarrent et arrêtent des instances selon la demande fonctionnent mieux lorsque les requêtes ne dépendent pas de la mémoire laissée par une requête antérieure.

Le serveur a toujours besoin d’un stockage durable pour un état applicatif réellement durable. Le MCP sans état n’élimine ni les bases de données, ni les stockages d’objets, ni les workers de navigateur, ni les files de tâches. Il supprime l’hypothèse selon laquelle l’état du protocole doit les accompagner.

Les opérations de longue durée s’inscrivent désormais dans un modèle fondé sur les extensions. Un serveur peut renvoyer une poignée de tâche, que le client consulte, met à jour ou annule ensuite au moyen d’opérations explicites.

La distinction est importante. Un état de session masqué couple un workflow à une relation de transport. Une poignée de tâche transforme le workflow en ressource adressable que d’autres composants autorisés peuvent gérer.

Les requêtes à plusieurs aller-retours répondent à un autre cas difficile. Certains outils nécessitent davantage d’informations d’un utilisateur ou d’un client avant de terminer. Les implémentations précédentes associaient cet échange à une session établie.

La nouvelle conception autorise une requête initiée par le serveur uniquement pendant le traitement d’une requête client. Les données de corrélation circulent au cours du cycle de requête et de réponse, évitant ainsi une session de protocole permanente.

Cela restreint certains comportements. Un serveur ne peut pas contacter un client de façon inattendue longtemps après l’appel initial. Cette limite réduit la flexibilité, mais elle donne aux invites utilisateur une origine et un cycle de vie plus clairs.

La découverte des outils devient également plus facile à acheminer et à mettre en cache. La spécification ajoute des métadonnées de méthode et d’outil aux en-têtes HTTP. Les passerelles peuvent inspecter ces métadonnées sans analyser chaque corps de requête.

Les serveurs peuvent associer une valeur de durée de vie aux réponses de liste. Les clients peuvent alors réutiliser les informations sur les outils pendant la période autorisée, au lieu de demander la même liste pour chaque sous-agent de courte durée de vie.

La proposition sans session avertit que le comportement antérieur pouvait générer un trafic de découverte répété, proportionnel au nombre de sous-agents multiplié par le nombre de serveurs. Les listes sans état offrent aux orchestrateurs une meilleure base pour éviter ce coût.

Cela devient important à mesure que les systèmes d’agents se distribuent davantage. Une demande utilisateur peut déclencher un planificateur, plusieurs workers spécialisés et un vérificateur. Répéter l’initialisation et la découverte pour chaque branche ajoute de la latence et du trafic.

Le protocole révisé adopte également JSON Schema 2020-12 dans son intégralité pour les définitions d’outils. JSON Schema est un vocabulaire standard permettant de décrire des données structurées, y compris les champs obligatoires, les types et les règles de validation.

Des schémas plus riches peuvent décrire des entrées et sorties plus précises. Les clients disposent ainsi de meilleures informations pour valider les appels et construire des interfaces. Cela réduit également la dépendance à des descriptions d’outils rédigées de manière imprécise.

Les extensions constituent une autre forme de séparation architecturale. MCP Apps peut fournir des interfaces rendues côté serveur, tandis que Tasks gère les opérations plus longues. Ces fonctionnalités peuvent évoluer sans imposer chaque capacité au cœur du protocole.

Un cycle de vie formel instaure au moins 12 mois entre la dépréciation d’une fonctionnalité et son retrait le plus précoce. Cela n’élimine pas le travail de migration, mais offre aux implémenteurs une fenêtre de planification plus claire après cette rupture nette.

Les recommandations officielles pour TypeScript montrent que la migration exige encore un travail délibéré. Le guide de migration du SDK indique que le nouveau format sur le réseau requiert une adoption explicite, plutôt que de modifier silencieusement chaque application existante.

Cette prudence est justifiée. Une nouvelle spécification ne peut pas créer l’interopérabilité par sa seule publication. Les clients, serveurs, passerelles et SDK doivent implémenter les mêmes détails et les tester sur des charges de travail réelles.

Malgré tout, le mécanisme répond à une faiblesse concrète. Il remplace la gestion de session propre à MCP par des modèles que les équipes cloud utilisent déjà pour des services HTTP ordinaires.

Un état explicite crée de nouvelles questions de sécurité et de fiabilité

MCP sans état supprime des frictions d’infrastructure, mais transfère davantage de responsabilité vers la conception des outils, l’autorisation et la mémoire des agents.

Les handles explicites rendent l’état visible et portable. Ces avantages élargissent aussi les endroits où des identifiants sensibles peuvent apparaître. Un handle peut se retrouver dans des historiques de discussion, des prompts, des journaux, des traces, le presse-papiers ou des messages de sous-agents.

Un serveur ne doit pas considérer la connaissance d’un identifiant comme une autorisation suffisante. Il doit valider le handle et l’identité authentifiée à chaque appel.

Cela ressemble à la conception utilisée par de nombreux services de documents et de projets. Un ID de ressource identifie un objet, tandis que le contexte d’autorisation actuel détermine si un appelant peut le lire ou le modifier.

Les services non authentifiés font face à un problème plus difficile. Dans ce contexte, un handle imprévisible peut agir comme un jeton au porteur. Toute personne qui l’obtient peut accéder à l’état sous-jacent jusqu’à l’expiration du handle.

La spécification sans session recommande des identifiants à forte entropie et des durées de vie limitées dans ces cas. Cette recommandation reste une indication d’implémentation, car MCP ne définit pas de type de handle au niveau du protocole.

Cela crée une lacune d’application des règles. Les clients ne peuvent pas reconnaître automatiquement quelles chaînes renvoyées représentent un état actif. Un browser_id ressemble à n’importe quelle autre valeur, à moins que les noms et descriptions des outils ne communiquent son rôle.

Un orchestrateur ne peut donc pas toujours savoir quels identifiants doivent survivre à la compression du contexte. Il peut également avoir du mal à déterminer quelles valeurs nécessitent un nettoyage ou ne devraient jamais être transmises à un autre sous-agent.

Les modèles transportent régulièrement des chemins de fichiers, des hashes de commit, des URL et des identifiants de transaction. Ils peuvent néanmoins copier un handle de manière incorrecte, l’omettre ou le perdre lorsqu’une longue conversation est résumée.

L’état de session présentait des faiblesses similaires. Les clients utilisaient des durées de vie incohérentes, et beaucoup ne rétablissaient pas les sessions après une déconnexion. La suppression des sessions rend ces problèmes explicites, mais ne rend pas la gestion de l’état automatique.

Le nettoyage présente un autre détail non résolu. La fin d’une session offrait autrefois un signal théorique pour libérer des ressources. En pratique, les clients terminaient souvent les sessions trop fréquemment, trop rarement, ou après un rechargement de page sans rapport.

Les workflows explicites ont besoin de leurs propres politiques d’expiration et de destruction. Un service de navigateur peut proposer close_browser, tout en imposant également un délai d’inactivité. Un service de tâches peut conserver les résultats terminés pendant une période définie.

La rétrocompatibilité ajoute de la complexité opérationnelle lors de l’adoption. Les serveurs existants qui dépendent des ID de session ne peuvent pas simplement accepter la nouvelle révision du protocole sans modifier leur modèle d’état.

Les clients et SDK peuvent négocier une révision antérieure lorsque cela est nécessaire. Cela permet une migration progressive, mais crée aussi deux chemins de comportement que les développeurs doivent tester.

Certaines capacités deviennent moins directes avec HTTP sans état. Les notifications non sollicitées et les interactions durables, pilotées par le serveur, ne s’intègrent pas aussi naturellement à des requêtes indépendantes. Les extensions et mécanismes d’écoute doivent prendre en charge ce travail.

Rien ne garantit non plus que chaque intégration MCP devienne efficace simplement parce que les sessions disparaissent. Des schémas mal conçus peuvent consommer du contexte. De grands catalogues d’outils peuvent dérouter les modèles. Des descriptions ambiguës peuvent toujours déclencher des appels incorrects.

Les Skills et les outils en ligne de commande conservent ici leurs avantages. Un agent de programmation peut souvent examiner l’aide d’un programme et écrire un court script sans charger un vaste catalogue d’outils distants.

Les outils locaux peuvent également garder les données sensibles sur la machine de l’utilisateur. Un déploiement MCP distant introduit des enjeux d’authentification, d’exposition réseau, de journalisation et de disponibilité du service que l’exécution locale évite.

MCP ne résout pas non plus l’injection de prompts. Un agent doté d’outils peut combiner des informations privées, des entrées non fiables et une communication externe, que le transport soit avec ou sans état.

Les opérateurs de serveurs doivent restreindre les permissions et les sorties. Les concepteurs d’agents doivent contrôler quels outils apparaissent ensemble. Les utilisateurs ont besoin de limites d’approbation claires pour les actions conséquentes.

Ces contraintes remettent en cause l’interprétation la plus forte du revirement d’Anthropic et Simon Willison. L’intérêt renouvelé de Willison valide le changement d’architecture, pas chaque implémentation MCP ni chaque serveur proposé.

mcp-explorer et datasette-mcp constituent de premières expériences utiles, car ils mettent en lumière des questions pratiques. Les clients peuvent-ils découvrir les outils de façon cohérente ? Les schémas sont-ils compréhensibles ? L’authentification et les handles d’état résistent-ils aux workflows réels ?

L’argument le plus solide en faveur de MCP sans état viendra de preuves d’interopérabilité. Des clients indépendants devraient se connecter à des serveurs indépendants sans correctifs personnalisés, tandis que les opérateurs devraient pouvoir les déployer avec une infrastructure ordinaire.

Jusqu’à ce que ces preuves se développent, MCP 2.0 reste une meilleure fondation plutôt qu’une victoire achevée. Le protocole a supprimé une source majeure de friction. Les implémenteurs déterminent encore si les systèmes qui en résultent restent sécurisés et compréhensibles.

Ce que les développeurs devraient surveiller après MCP 2.0

Le prochain test est l’adoption dans les SDK, les serveurs réels et les clients, et non une nouvelle flambée du nombre de dépôts.

Le premier signal est la couverture d’implémentation de la révision 2026-07-28. Les SDK officiels doivent offrir une prise en charge cohérente de la découverte, des métadonnées par requête, des capacités explicites, de Tasks et du comportement d’autorisation.

Les seules étiquettes de version ne suffiront pas. Les développeurs devraient surveiller les résultats de conformité et les tests interlangages. Un serveur Python, un client TypeScript et une passerelle gérée devraient s’accorder sur les mêmes requêtes et erreurs.

Une solide compatibilité entre SDK renforcerait l’idée que MCP offre désormais une frontière stable pour les outils distants. Des divergences persistantes l’affaibliraient en ramenant les développeurs vers des adaptateurs spécifiques à chaque client.

Le deuxième signal concerne la manière dont les serveurs de production migrent les workflows avec état. L’automatisation de navigateur, les transactions, les paniers d’achat et les tâches de recherche de longue durée constituent des tests exigeants pour les handles explicites.

Les migrations réussies devraient démontrer un nettoyage fiable, une autorisation par requête, le transfert des handles et la compression du contexte. Elles devraient également documenter ce qui se produit lorsqu’un agent perd ou répète un identifiant.

Si ces modèles deviennent réutilisables, l’état explicite apparaîtra comme une meilleure abstraction que des sessions ambiguës. Si chaque serveur invente des règles de cycle de vie incompatibles, le protocole aura déplacé la complexité plutôt que de la réduire.

Le troisième signal est la relation entre MCP et Skills. Les plateformes d’agents devraient démontrer dans quels cas elles choisissent une commande locale, un appel API guidé par une skill ou un serveur MCP distant.

Des règles de sélection claires renforceraient la thèse plus limitée. MCP servirait les capacités distantes partagées, tandis que Skills regrouperait des instructions et des workflows locaux.

Un chevauchement persistant pourrait créer une maintenance dupliquée. Les propriétaires d’outils pourraient avoir besoin d’une API, d’une CLI, d’un package de skill, d’un serveur MCP et d’une intégration spécifique au client pour une même capacité.

Les développeurs devraient résister à l’idée que cette duplication est inévitable. Une skill peut référencer un serveur MCP, et un serveur MCP peut envelopper une API existante. La question utile est de savoir quelle interface possède le contrat durable.

Pour les outils de données, les expériences de Willison offrent un cas concret à surveiller. Datasette sert déjà des informations structurées via des API web. datasette-mcp peut tester si un contrat centré sur les agents améliore la découverte et les requêtes sûres.

Les équipes qui construisent des workflows de connaissance font face à un choix similaire. Les documents et notes locaux ont souvent leur place dans une base de connaissances d’ingénierie privée et interrogeable. Les systèmes métier partagés peuvent mieux convenir à des outils distants authentifiés.

L’essentiel est d’éviter d’accorder à un agent une collection illimitée d’outils simplement parce qu’un protocole commun facilite la connexion. La standardisation réduit le travail d’intégration, mais ne remplace pas la conception des permissions.

Le revirement d’Anthropic et Simon Willison est précieux parce qu’il fait suite à une période de scepticisme réel. MCP n’a pas regagné l’attention grâce au branding. Ses mainteneurs ont supprimé une contrainte structurelle que les critiques pouvaient pointer dans les systèmes déployés.

C’est ainsi qu’un protocole devrait évoluer. Il devrait intégrer les enseignements tirés d’hypothèses erronées, réduire ses responsabilités et rendre les opérations courantes plus faciles à appréhender.

Au cours des trois prochains mois, examinez les clients et serveurs que vous utilisez réellement. Vérifiez s’ils prennent en charge la révision finale, comment ils représentent l’état de l’application et si leur autorisation suit chaque handle.

Comparez ensuite le résultat avec l’alternative la plus simple. Si une commande locale reste plus claire, conservez-la. Si de nombreux agents ont besoin d’une capacité distante unique et gouvernée, testez MCP sans état et consignez les endroits où l’interopérabilité échoue encore.