Microsoft a annoncé la version 2.0 du kit de développement logiciel officiel de MCP en C#, parallèlement à l’implémentation de la spécification 2026-07-28. Cette version modifie le fonctionnement des serveurs MCP via HTTP en les rendant sans état par défaut, ajoute des en-têtes HTTP uniformes et prend en charge les requêtes en plusieurs tours, permettant aux outils de demander des entrées à l’utilisateur ou au modèle de langage sans dépendre d’une session persistante.
Cette version s’adresse aux développeurs qui créent des serveurs et des clients MCP sur .NET, tout en préservant le fonctionnement des interfaces de programmation stables de la version 1.x et en prenant en charge les frameworks net8.0, net9.0 et net10.0, ainsi que netstandard2.0 pour une utilisation avec .NET Framework.
Des serveurs sans état par défaut
Dans les versions précédentes, l’utilisation de Streamable HTTP nécessitait d’achever la négociation d’initialisation et de créer une session, puis d’envoyer l’en-tête Mcp-Session-Id avec chaque requête ultérieure. Cela liait les requêtes à l’instance du serveur qui avait émis l’identifiant, ce qui nécessitait un routage persistant ou le transfert des sessions lors de l’exécution de plusieurs instances.
La spécification 2026-07-28 supprime la négociation initialize et initialized ainsi que l’en-tête Mcp-Session-Id, et transmet la version du protocole et les capacités dans chaque requête. Par conséquent, n’importe quelle instance du serveur peut traiter n’importe quelle requête, sans nécessiter de sessions persistantes ni de magasins de sessions partagés au niveau du protocole. Cela rend le déploiement de serveurs MCP dans des environnements serverless, à instances multiples ou en périphérie plus proche de l’exécution d’une application ASP.NET Core classique derrière un répartiteur de charge.
L’option HttpServerTransportOptions.Stateless est définie sur true par défaut dans la version 2.0, avec la possibilité d’activer le mode avec état lorsqu’il faut gérer des messages non sollicités du serveur vers le client ou un état de transport associé à la session. Les sessions restent disponibles, mais elles ne constituent plus le paramètre par défaut.
Des en-têtes HTTP pour le routage et la surveillance
Le mode sans état transforme une requête MCP en une requête HTTP POST autonome, permettant à l’infrastructure habituelle de la traiter comme n’importe quel autre trafic HTTP. La spécification autorise des en-têtes tels que Mcp-Method et Mcp-Name, ainsi que la possibilité de promouvoir certains paramètres de l’outil en en-têtes de type Mcp-Param-*.
Le répartiteur de charge, le proxy, la passerelle ou le pare-feu applicatif web peuvent utiliser ces en-têtes pour le routage et la surveillance sans analyser le corps de la requête JSON-RPC. Le corps de la requête reste la source de vérité ; si la valeur de l’en-tête diffère de celle présente dans le corps, le serveur rejette la requête avec une erreur HeaderMismatch. La conception prend également en charge l’encodage dans les en-têtes des valeurs qui ne sont pas prises en charge, telles que les valeurs non ASCII, au moyen d’un indicateur Base64.
Des requêtes en plusieurs tours pour les outils interactifs
La fonctionnalité Multi Round-Trip Requests, ou MRTR, ajoute une méthode pour gérer les outils qui ne peuvent pas achever leur travail en un seul appel. Au lieu que le serveur communique avec le client au moyen d’une session active pendant l’exécution de la requête, il renvoie un résultat de type InputRequiredResult contenant les demandes d’entrée et un état opaque appelé requestState.
Le client exécute l’action demandée, comme demander une confirmation à l’utilisateur, appeler un modèle de langage ou afficher les racines des espaces de travail, puis renvoie le même appel d’outil accompagné de inputResponses et de requestState. Le processus peut être répété sur plusieurs tours, tandis que les informations de continuité sont transmises dans la charge utile ; l’opération n’a donc pas besoin de session.
Le McpClient de haut niveau traite automatiquement les MRTR après l’enregistrement des gestionnaires appropriés. La version peut également utiliser un pont de compatibilité avec les clients plus anciens lorsqu’une session avec état existe. En revanche, un client plus ancien fonctionnant sans session ne peut pas exécuter l’interaction en plusieurs tours ; l’outil doit donc fournir une solution de remplacement, comme transmettre directement la valeur demandée dans un paramètre d’appel.
Compatibilité et packages disponibles
Les interfaces stables et non obsolètes de la version 1.x continuent d’être compilées et exécutées dans la version 2.0, tandis que les changements obsolètes apparaissent sous forme d’avertissements et non de suppressions. Un client 2.0 peut utiliser l’ancienne négociation d’initialisation lors de la connexion à un serveur plus ancien, et un serveur 2.0 accepte également cette négociation provenant d’un client ancien.
La seule exception à la compatibilité du protocole concerne l’extension Tasks ; sa conception remaniée dans la version 2.0 remplace la version expérimentale de Tasks présente dans la spécification 2025-11-25 et n’est pas compatible avec celle-ci au niveau de l’interface ou du protocole. Tasks est désormais disponible dans le package séparé ModelContextProtocol.Extensions.Tasks, tandis que les MCP Apps expérimentales sont incluses dans ModelContextProtocol.Extensions.Apps.
Les packages principaux comprennent ModelContextProtocol.Core pour le client et les composants de bas niveau, ModelContextProtocol pour la plupart des serveurs, et ModelContextProtocol.AspNetCore pour les serveurs Streamable HTTP. La publication indique que l’axe prioritaire suivant de la série 2.x sera l’authentification et l’autorisation généralisées, en s’appuyant sur une compatibilité plus étroite avec OAuth et OpenID Connect.