MCP Servers v2.0.0 ajoute la prise en charge du protocole moderne tout en conservant les clients existants

MCP Servers v2.0.0 refond les serveurs de référence du projet pour le protocole moderne tout en conservant la prise en charge des clients existants. Publiée le 19 octobre, la mise à jour fait le lien entre différentes générations de MCP, le Model Context Protocol qui connecte les applications d’IA aux outils et aux données. Sa promesse de compatibilité a une limite claire : les anciens clients restent pris en charge, mais les serveurs TypeScript exigent désormais Node.js 24.

Cette distinction met sous pression les développeurs qui maintiennent des intégrations existantes. Un client peut encore utiliser un protocole plus ancien alors que le logiciel derrière ses outils exige un environnement d’exécution plus récent. Les équipes applicatives doivent donc prendre des décisions distinctes concernant les paquets serveur, les environnements d’exécution et le comportement du protocole.

La tension centrale oppose modernisation et continuité. Les responsables du projet font évoluer leurs exemples vers une architecture plus récente sans obliger chaque application connectée à migrer simultanément. Pour les développeurs qui utilisent Claude Desktop, VS Code ou des applications d’IA personnalisées, la question immédiate porte sur les hypothèses qui restent valables durant cette transition. La configuration des connexions, les permissions de fichiers et la durée de vie de l’état de l’application méritent plus d’attention que le seul numéro de version.

Ce que MCP Servers v2.0.0 change réellement

Cette version met à jour un ensemble défini d’implémentations de référence, et non tous les serveurs de l’écosystème MCP au sens large.

La liste des paquets de la version recense quatre paquets TypeScript publiés en version 2.0.0. Ils couvrent Everything, Filesystem, Memory et Sequential Thinking. TypeScript est un langage de programmation qui ajoute la vérification des types à JavaScript.

La même version liste trois paquets Python : Fetch, Git et Time. Ils portent la version fondée sur la date 2026.10.19. Cette distinction est importante lorsque les équipes recensent leurs dépendances, car le tag de version du dépôt ne devient pas la version de chaque paquet.

Les responsables du projet décrivent cette mise à jour comme une refonte prenant en charge la spécification moderne tout en continuant de répondre aux anciens clients. Il s’agit d’une affirmation d’implémentation concernant les serveurs inclus. Elle n’établit pas la compatibilité d’intégrations communautaires non liées ni de chaque application qui se connecte via MCP.

Plusieurs systèmes de versionnage distincts sont également en jeu. La version du dépôt est v2.0.0, tandis que le protocole utilise des identifiants fondés sur la date. Une version de paquet identifie un logiciel livré ; un identifiant de protocole décrit les règles de communication que ce logiciel prend en charge.

Confondre ces identifiants peut créer des attentes trompeuses en matière de mise à niveau. Installer un paquet étiqueté 2.0.0 ne signifie pas qu’une application adopte automatiquement toutes les nouvelles fonctionnalités du protocole. Le client détermine toujours quel comportement de communication pris en charge il utilise.

La compatibilité d’un serveur MCP relève donc d’une relation entre composants. Un paquet serveur peut prendre en charge plusieurs révisions du protocole tandis qu’une application connectée continue d’utiliser une révision antérieure. À l’inverse, installer un logiciel serveur plus récent ne peut pas fournir des capacités absentes du client.

Pour les responsables de l’ingénierie, cette version établit une distinction utile entre disponibilité et préparation. Les paquets publiés démontrent que l’implémentation est disponible. La préparation dépend de la compatibilité de l’application environnante, de l’environnement de lancement, des permissions et du comportement attendu.

L’importance pratique dépasse les personnes qui exécutent directement ces paquets. Les implémentations de référence fournissent des exemples que d’autres développeurs étudient et adaptent. Leurs choix architecturaux peuvent influencer des intégrations personnalisées, même si le paquet de référence n’entre jamais dans une liste de dépendances de production.

Cette influence mérite une formulation prudente. Un exemple peut établir un modèle sans prouver que ce modèle convient à chaque déploiement. La version fournit des éléments concrets d’implémentation, tandis que les propriétaires d’applications restent responsables de déterminer quelles parties correspondent à leurs systèmes.

L’actualité est donc plus précise qu’une annonce générale affirmant que MCP a changé. Les responsables du projet ont livré des exemples mis à jour, reliant un comportement de protocole plus récent à une base installée de clients plus anciens. La question suivante concerne l’infrastructure nécessaire pour exécuter ces exemples.

Les anciens clients restent pris en charge, mais pas les anciens environnements d’exécution

La compatibilité du protocole ne préserve pas l’environnement d’exécution précédent.

L’exigence Node.js de la version relève la version minimale de Node.js des serveurs TypeScript à 24. Node.js est l’environnement d’exécution qui lance JavaScript en dehors d’un navigateur. Cette modification s’applique à Everything, Filesystem, Memory et Sequential Thinking.

Le dossier de maintenance associé explique pourquoi cette exigence mérite de l’attention. Les déclarations de paquets, la documentation et les contrôles automatisés décrivaient auparavant des attentes de prise en charge différentes. La correction aligne le minimum déclaré, la documentation et la configuration de validation autour du nouvel environnement d’exécution.

Cela crée un enjeu concret de migration pour les applications d’IA locales. Un utilisateur peut mettre à jour un paquet serveur tout en laissant l’environnement de lancement de l’application inchangé. Le protocole du client reste acceptable, mais le serveur dépend tout de même de l’environnement d’exécution accessible à ce processus.

Prenons le cas illustratif d’un poste d’ingénierie disposant d’environnements distincts pour le développement et les applications de bureau. Un terminal peut indiquer l’environnement d’exécution attendu alors qu’une application lancée ailleurs hérite d’une configuration différente. Une exécution réussie dans le terminal ne permettrait pas de déterminer si l’application de bureau peut lancer le même serveur.

Cet exemple illustre un raisonnement de déploiement, plutôt qu’un défaut signalé dans cette version. L’implication plus large découle directement du nouveau minimum : les équipes ont besoin de preuves sur l’environnement qui démarre réellement le paquet.

La pression s’exerce surtout sur les développeurs qui distribuent des configurations, les administrateurs qui maintiennent des postes de travail gérés et les équipes qui empaquettent des assistants internes. Leur responsabilité inclut le logiciel qui lance un outil, et pas seulement l’interface déclarée de cet outil.

Pour ces équipes, la rétrocompatibilité peut réduire le travail de coordination sans l’éliminer. Elles n’ont pas nécessairement besoin de réécrire immédiatement les anciens clients. Elles doivent néanmoins tenir compte des exigences du serveur plus récent.

Cette distinction change également la manière dont les échecs doivent être interprétés. Un processus qui ne peut pas démarrer pose un problème différent d’un serveur en cours d’exécution qui rejette une requête. Traiter les deux cas comme une incompatibilité de protocole oriente l’enquête vers le mauvais composant.

Le même raisonnement s’applique à la documentation d’assistance. Une instruction indiquant que les anciens clients restent pris en charge doit s’accompagner d’un contexte sur les exigences de l’environnement d’exécution. Sans cela, les lecteurs peuvent raisonnablement déduire une promesse plus large que celle réellement faite par les responsables du projet.

L’épinglage de paquet, qui fixe une dépendance à une version choisie, devient un choix opérationnel aux conséquences visibles. Les équipes peuvent évaluer délibérément la nouvelle version plutôt que de combiner un changement inattendu de paquet avec une modification d’environnement.

Cela n’établit pas un argument universel en faveur du report des mises à jour. Cela établit la nécessité de distinguer les raisons d’une mise à jour. Une équipe qui recherche un comportement de protocole moderne a un objectif immédiat différent de celui d’une équipe qui maintient un flux de travail existant.

La version offre aux deux équipes une voie à suivre, mais leur validation doit refléter ces objectifs distincts. Maintenir un ancien client implique de vérifier la continuité du comportement. Adopter un client plus récent implique aussi d’examiner l’architecture qui traite ses requêtes.

Le pont de compatibilité change la manière dont les requêtes transportent le contexte

La nouvelle architecture modifie l’emplacement du contexte de communication, même lorsque l’outil visible reste familier.

Selon les règles actuelles de versionnage du protocole, la révision du protocole est 2026-07-28. Les requêtes déclarent leur version de protocole dans des métadonnées, c’est-à-dire des informations descriptives qui accompagnent la requête. Les serveurs acceptent ou rejettent les requêtes individuellement en fonction des versions prises en charge.

Les clients peuvent utiliser server/discover, une requête de découverte qui renvoie l’identité du serveur, les versions prises en charge et les capacités. Les anciennes révisions du protocole utilisent à la place une négociation d’initialisation, un échange d’ouverture qui établit le contexte de fonctionnement de la connexion.

L’implémentation du protocole moderne intègre les deux approches aux serveurs de référence TypeScript. Pour les connexions locales, le premier message sélectionne l’ère du protocole. Un ancien client commence par initialize ; un client moderne utilise la découverte ou les métadonnées de requête plus récentes.

L’implémentation s’éloigne également d’un état serveur indexé par des identifiants de session. L’état propre à une connexion réside dans des instances de serveur. Les informations qui doivent survivre à une requête moderne utilisent des handles, des identifiants émis par le serveur pour référencer ces informations.

Ces détails sont importants, car le terme « sans état » peut être mal compris. Abandonner la dépendance aux sessions de protocole ne signifie pas qu’une application oublie tout après chaque requête. Cela signifie que les développeurs doivent identifier explicitement où résident les informations et comment les travaux ultérieurs y font référence.

Pour une intégration personnalisée, cette distinction affecte la revue architecturale. Un développeur doit séparer les informations appartenant à une requête de celles appartenant à une connexion ou à des données applicatives stockées. Ces durées de vie ne correspondent pas nécessairement.

Un assistant qui conserve un fait relatif à un projet répond à une exigence différente d’un outil qui conserve une progression temporaire. Les informations persistantes doivent survivre conformément aux règles de stockage du produit. Les informations temporaires ne doivent rester disponibles que pour l’opération ou l’interaction prévue.

Le serveur Memory illustre cette différence. Son graphe de connaissances, une structure qui relie des entités par des relations, fournit des informations persistantes. Sa documentation décrit différents mécanismes d’abonnement pour les clients modernes et existants, tout en conservant les mêmes outils et ressources sous-jacents.

Un abonnement est une requête visant à recevoir des mises à jour lorsque les informations changent. La question importante pour le produit est de savoir si l’application continue de recevoir ces mises à jour. Une première lecture réussie ne permet pas d’établir que les changements ultérieurs apparaîtront comme prévu.

Sequential Thinking présente une autre distinction de durée de vie. Sa documentation décrit un historique de réflexion qui dure pendant toute la connexion, quelle que soit l’ère du protocole. Ce comportement concerne le contexte de travail de l’outil, plutôt qu’une promesse générale de mémoire permanente.

Everything remplit encore un autre rôle. Il teste les capacités du protocole pour les créateurs de clients, y compris le comportement des requêtes et notifications modernes. Sa valeur vient de l’exposition de comportements d’intégration qu’un simple appel d’outil réussi laisserait sans examen.

Pris ensemble, ces exemples montrent pourquoi la migration d’un serveur MCP va au-delà du changement d’importations ou de noms de paquets. La fonction visible peut rester reconnaissable tandis que le modèle de communication environnant évolue. Les développeurs qui adaptent du code de référence doivent comprendre les deux couches.

C’est également là que l’approche de compatibilité prend toute son importance. Prendre en charge les anciens clients donne du temps aux équipes applicatives. Cela ne supprime pas la nécessité de comprendre la nouvelle architecture avant d’adopter son comportement.

L’accès au système de fichiers rend la différence de comportement concrète

Le même package serveur peut nécessiter une configuration d’autorisations différente selon l’ère protocolaire du client.

Le serveur Filesystem offre l’exemple le plus clair, car son comportement détermine les répertoires locaux auxquels un outil peut accéder. Une liste d’autorisation est un ensemble explicite d’emplacements permis. La connexion moderne du serveur utilise les répertoires fournis au démarrage du processus.

La documentation balisée sur les contrôles d’accès aux répertoires recommande ces arguments de démarrage pour toutes les versions du protocole. Les anciens clients peuvent également utiliser Roots, un mécanisme fourni par le client qui décrit des emplacements du système de fichiers. La connexion moderne ne demande pas ces informations héritées.

Un serveur démarré sans répertoires autorisés se comporte donc différemment selon son chemin de connexion. Pour les appels d’outils modernes, la documentation décrit une erreur signalant l’absence de configuration des répertoires. La seule connexion d’un processus n’établit pas un accès utilisable aux fichiers.

Pour les clients hérités, la documentation décrit également les mises à jour d’accès et les révocations. Les appels d’outils attendent lorsqu’une actualisation de Roots est en cours. Une fois les racines fournies par le client appliquées, une mise à jour ne contenant aucune racine valide retire l’accès jusqu’au retour de racines valides.

L’implication produit est simple : la réussite de la connexion et celle des autorisations sont deux résultats distincts. Un client peut trouver le serveur et reconnaître ses outils sans disposer d’un chemin valide vers les fichiers visés.

Prenons l’exemple d’un assistant aidant un ingénieur à comparer des documents de conception locaux. La demande de l’utilisateur semble identique avant et après une mise à niveau du client. Pourtant, l’application peut emprunter un chemin protocolaire différent et se heurter à d’autres exigences de configuration.

Si l’ancienne configuration dépendait de Roots fournies par le client, l’adoption du chemin moderne exige de prêter attention aux répertoires de démarrage. La formulation de l’utilisateur ne révèle pas cette dépendance. Une liste d’outils indiquant l’existence d’opérations sur les fichiers ne la révèle pas davantage.

C’est pourquoi les autorisations doivent faire partie de l’analyse de migration plutôt que d’apparaître en note de bas de page. L’accès aux fichiers relie directement le comportement du protocole aux attentes des utilisateurs. Une erreur de configuration peut sembler à l’utilisateur relever d’un manque de connaissances ou de l’incapacité d’un assistant à comprendre une demande.

Cela peut aussi compliquer le dépannage. Une équipe peut examiner la qualité de la recherche, c’est-à-dire l’efficacité avec laquelle un logiciel trouve les informations pertinentes, alors que l’outil sous-jacent ne peut pas accéder à l’emplacement prévu. La documentation de la version aide à distinguer ces possibilités.

Pour les flux de travail liés à la connaissance, les équipes doivent distinguer la limite d’accès d’un connecteur de la qualité du système d’information qui en résulte. Une base de connaissances interrogeable dépend de la disponibilité, de l’organisation et de la récupérabilité des documents pertinents. La prise en charge du protocole ne couvre qu’une partie de cette chaîne.

Cet exemple limite également ce que les développeurs devraient déduire de la rétrocompatibilité. La persistance d’un comportement hérité n’implique pas une configuration d’autorisations identique pour un client moderne. Les deux chemins peuvent être pris en charge tout en reposant sur des mécanismes différents.

Pour les organisations qui évaluent des assistants, cette différence soulève une question d’achat concrète. Quel composant définit les emplacements accessibles, et comment l’application communique-t-elle l’absence ou le retrait d’accès ? La réponse devrait décrire le comportement réel plutôt que de simplement énumérer les normes prises en charge.

Cette version facilite l’étude de cette question, car l’implémentation de référence documente ses limites. Les autres intégrations nécessitent encore leurs propres éléments de preuve. Copier l’étiquette du protocole ne démontre pas qu’elles appliquent des règles d’accès équivalentes.