Analyse MCP 2026-07-28 : serveurs sans état, applications MCP, tâches, authentification d'entreprise et nouvelle infrastructure d'agents

引言

模型上下文协议（Model Context Protocol）迎来了自发布以来最大规模的一次架构修订。

MCP最初被引入时，是作为一种让AI应用将模型与工具、API、数据源、文件及外部系统连接起来的通用方式。在不到两年的时间里，它已从一个由Anthropic主导的集成项目，发展成为一个更广泛的开源协议，拥有自己的治理流程、SDK生态系统、工作组、扩展以及横跨众多AI产品的实现。

2026-07-28修订版聚焦于MCP离开开发者笔记本电脑、进入大型生产环境时出现的问题。

最主要的变更可以概括为：

MCP正在协议层转变为无状态。

这一变更从新的线上格式中移除了协议级的会话和初始化握手，使远程MCP服务器能够更轻松地部署在普通负载均衡器、无服务器基础设施、边缘计算节点和水平扩展架构之后。

但无状态传输只是本次更新的一部分。

该修订版还正式确立了一个扩展框架，重塑了长时间运行的任务，引入了多轮往返请求，增加了可路由的HTTP头和缓存提示，强化了授权机制，扩展了JSON Schema支持，并制定了一项正式的功能弃用策略。

在协议本身之外，MCP生态系统还在增加交互式应用、企业级托管授权、私有网络隧道以及更强大的开发者工具。

正是在这一点上，MCP开始不再像一个便捷的智能体连接器，而更像生产级基础设施。

MCP采用速度迅猛增长

源报告强调了MCP使用量的增长速度。

根据源文章引用的Claude开发者发布公告：

• MCP SDK月下载量已超过4亿次。
• 年度内SDK月使用量大约增长了四倍。
• TypeScript和Python SDK的累计下载量均跨越了非常大的里程碑。
• 已有数百个MCP集成通过Claude的连接器生态可用。

这些7月底的具体数据属于发布公告中的指标，而非核心规范中发布的数字。

Anthropic早前的一份官方公告提供了一个有用的参照点：2026年1月，Anthropic表示MCP已达到每月1亿次下载。

这意味着在7月协议重新设计之前，生态系统已经相当庞大。

因此，本次更新的意义不在于MCP试图在未来某天变得有用，而在于维护者正在围绕已在生产规模上显现的问题重新设计协议。

这些问题包括：

• 粘性会话。
• 共享会话存储。
• 水平扩展。
• 无服务器部署。
• 网关路由。
• 认证复杂性。
• 长时间运行的智能体操作。
• 交互式界面。
• 向后兼容性。
• 协议演进。

为什么之前的有状态设计成为扩展难题

早期的远程MCP部署可以维持协议级别的会话状态。

客户端通常会初始化一个

建立连接并获得了一个会话标识符。后续请求随后需要保持与该会话的关联。

一个简化的 2025-11-25 流程如下所示：

POST /mcp HTTP/1.1
Content-Type: application/json

{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-11-25",
"capabilities": {},
"clientInfo": {
"name": "my-app",
"version": "1.0"
}
}
}

初始化之后，后续的调用可以携带：

Mcp-Session-Id: 1868a90c-3a3f-4f5b

这种方法对许多应用来说是可行的，但它带来了一些基础设施层面的要求。

生产环境部署可能需要：

• 粘性负载均衡器路由。
• 共享会话存储。
• 会话复制。
• 会话过期逻辑。
• 故障转移处理。
• 感知连接的可观测性。
• 对服务器重启的特殊处理。

MCP 维护者得出的结论是，这些要求与协议本身的耦合过于紧密。

新修订版本移除了这一假设。

MCP 现已在协议层面实现无状态

在 2026-07-28 协议设计中，每个请求都携带服务器解析请求所需的信息。

官方示例如下：

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search",
"arguments": {
"q": "otters"
},
"_meta": {
"io.modelcontextprotocol/clientInfo": {
"name": "my-app",
"version": "1.0"
}
}
}
}

不再有协议级的 Mcp-Session-Id。

不再有强制性的连接会话将请求绑定到单个服务器实例。

任何兼容的服务器实例都可以处理该请求。

这对于云部署来说是一个重大的改进。

远程 MCP 服务器现在可以适配传统的架构：

客户端
↓
API 网关 / 负载均衡器
↓
MCP 服务器实例 A
MCP 服务器实例 B
MCP 服务器实例 C

请求不再因为之前某个请求落在某个实例上，就必须回到该实例。

新线上格式中移除了 initialize 握手

无状态重新设计还从 2026-07-28 线上格式中移除了旧的 initialize / initialized 生命周期。

之前初始化期间只传输一次的信息，现在通过元数据随请求一同传输。

当客户端希望提前发现服务器能力时，可以使用新方法 server/discover。

这并不意味着旧客户端会立即停止工作。

当前的 SDK 文档包含对早期协议版本的兼容性行为说明。例如，C# SDK 可以支持新的无状态

在继续与使用 2025-11-25 协议的客户端协商旧版基于会话的行为的同时，路径向前推进。

重要的迁移区别在于：

2026-07-28 :
Modèle de requête sans état, aucune session au niveau du protocole.

Anciennes versions :
La poignée de main d'initialisation et le comportement sensible à la session peuvent encore être pris en charge
via la négociation de version et les chemins de compatibilité SDK.

Les développeurs doivent tester les deux extrémités de l'intégration, plutôt que de simplement mettre à niveau le serveur et de supposer que tous les clients comprennent la nouvelle version.

## Un protocole sans état ne signifie pas une application sans état

L'une des erreurs les plus faciles à commettre est de comprendre ce changement comme suit :

> Les applications MCP ne sont plus autorisées à conserver un état.

Ce n'est pas ce que signifie la spécification.

**La couche protocole** est sans état.

Les applications peuvent toujours maintenir un état là où il est utile.

Supposons qu'un outil de shopping crée un panier.

Le serveur peut renvoyer :

```JSON
{
"basket_id": "basket_8472"
}

Le modèle peut transmettre cette valeur lors des appels suivants :

{
"basket_id": "basket_8472",
"item_id": "item_123"
}

Cela rend l'état applicatif visible comme des données d'outil ordinaires, au lieu de le cacher dans les métadonnées de transport.

Le même schéma peut être utilisé pour les sessions de navigateur, les tâches de rapport, les paniers d'achat, les identifiants de workflow, les identifiants de déploiement, l'état d'édition de documents et les tâches d'analyse de longue durée.

Pourquoi les handles explicites peuvent être meilleurs

Les handles visibles présentent plusieurs avantages.

Le modèle peut :

• Les transmettre entre les outils concernés.
• Raisonner sur quel handle appartient à quelle tâche.
• Les inclure dans les journaux.
• Les récupérer après une nouvelle tentative.
• Les confier à une autre étape de workflow.

Le serveur peut :

• Valider les handles.
• Les faire expirer.
• Les lier à un utilisateur ou à un locataire.
• Rejeter les états obsolètes.
• Stocker l'état réel dans une base de données.

Ainsi, MCP sans état déplace la gestion de l'état de la couche de transport vers une conception applicative explicite.

Le sans-serveur et la mise à l'échelle horizontale deviennent beaucoup plus faciles

L'article source met en avant le déploiement sans serveur, l'un des résultats les plus pratiques du nouveau protocole.

Lorsque les requêtes sont autonomes, les serveurs MCP peuvent plus facilement fonctionner dans des environnements tels que :

• AWS Lambda.
• Cloudflare Workers.
• Vercel.
• Autres fonctions sans serveur.
• Plateformes d'auto-scaling de conteneurs.
• Déploiements Kubernetes sans état ordinaires.
• Environnements périphériques.

Cela ne signifie pas que chaque charge de travail MCP fonctionnera automatiquement sur chaque plateforme sans serveur.

Les développeurs doivent toujours prendre en compte la durée d'exécution, le support du streaming, les démarrages à froid, l'état applicatif persistant, les clés, le réseau sortant, les tâches de longue durée, les besoins en système de fichiers et les connexions à la base de données.

Le protocole n'impose plus d'architecture de session, ce qui élimine un obstacle majeur.

L'équilibrage de charge par rotation devient le choix naturel par défaut

Les serveurs mis à l'échelle horizontalement n'ont plus besoin de lier un client unique à une instance unique au niveau du protocole.

Cela signifie qu'un simple équilibreur de charge par rotation peut répartir les requêtes entre plusieurs instances.

Cela améliore :

• L'auto-scaling.
• Le remplacement d'instances.
• La récupération après panne.
• Les déploiements progressifs.
• Le routage multi-régions.
• La simplicité de l'infrastructure.

Cela change également la façon dont les auteurs de serveurs réfléchissent aux états en mémoire cachés.

Si un outil fonctionne uniquement parce qu'une requête précédente a rempli un dictionnaire dans un processus, l'implémentation peut échouer lorsque la requête suivante arrive sur une autre instance.

Un bon test de migration est le suivant :

Si chaque appel d'outil tombait sur un processus serveur différent, le même workflow pourrait-il continuer ?

Si la réponse est non, cela signifie que le serveur contient une dépendance à un état applicatif qui doit devenir explicite, ou être migrée vers un stockage partagé persistant.

Les requêtes multi-allers-retours remplacent les connexions durables en cours

La conception sans état doit toujours offrir un moyen au serveur de demander plus d'informations au client.

Les exemples incluent la confirmation de l'utilisateur, les paramètres supplémentaires, les questions guidées, les réponses générées par le modèle ou les valeurs liées à l'espace de travail.

Le nouveau mécanisme est la requête multi-allers-retours (Multi Round-Trip Requests, MRTR).

Un outil peut renvoyer un résultat incomplet :

{
"resultType": "input_required",
"inputRequests": {
"confirm": {
"type": "elicitation",
"message": "Supprimer 3 fichiers ?",
"schema": {
"type": "boolean"
}
}
},
"requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}

Le client collecte les réponses nécessaires.

Ensuite, il répète l'appel d'origine en utilisant inputResponses et le requestState renvoyé.

Comme l'état est transporté dans le flux de requête, une autre instance de serveur peut traiter le tour suivant.

Cela est plus conforme à une architecture sans état qu'une connexion serveur-client durable.

Le routage basé sur les en-têtes rend MCP plus adapté aux passerelles

Le nouveau format Streamable HTTP place directement les métadonnées d'opération dans les en-têtes HTTP.

Les en-têtes importants incluent :

Mcp-Method: tools/call
Mcp-Name: search

C'est important pour l'infrastructure de production.

Les passerelles API, les pare-feu d'applications web, les limiteurs de débit ou les couches d'observabilité peuvent identifier l'opération sans analyser le corps JSON.

Les utilisations possibles incluent :

• Router tous les outils de recherche vers le même pool.
• Appliquer des limites plus strictes aux opérations destructrices.
• Journaliser la latence par nom d'outil.
• Mesurer l'utilisation par méthode.
• Bloquer les outils non autorisés au niveau de la passerelle.
• Créer des politiques de fiabilité indépendantes.

La spécification exige également une cohérence entre les en-têtes et le corps JSON-RPC.

Le serveur doit rejeter les requêtes où les deux sont incohérents.

Les résultats de listing et de lecture prennent en charge la mise en cache

Les clients MCP demandent souvent des métadonnées relativement stables, telles que les listes d'outils, les ressources, les listes de prompts et les lectures de ressources.

Récupérer les mêmes informations de manière répétée gaspille le trafic réseau et la capacité du serveur.

La nouvelle révision introduit des métadonnées de mise en cache, telles que :

ttlMs
cacheScope

Ces valeurs permettent au serveur d'indiquer la durée pendant laquelle un résultat doit rester frais, et si le résultat peut être partagé entre utilisateurs ou contextes.

Cela fonctionne de manière similaire au cache HTTP ordinaire.

Pour les agents à forte intensité d'outils, cela peut réduire le chargement répété des métadonnées.

La trace distribuée est standardisée

La révision documente également la propagation du contexte de trace W3C.

Des clés telles que :

• traceparent
• tracestate
• baggage

peuvent être propagées via les métadonnées MCP.

Cela permet à une trace distribuée unique de suivre le travail à travers la chaîne suivante :

Application hôte
→ Client MCP
→ Passerelle MCP
→ Serveur MCP
→ API en aval
→ Base de données

C'est important pour les déploiements d'entreprise, car les appels d'outils lents sont plus faciles à déboguer lorsque les équipes peuvent voir où se produit réellement la latence.

Les extensions deviennent une fonctionnalité de premier plan du protocole

Le protocole évolue également dans la manière dont les fonctionnalités optionnelles progressent.

Le cadre actuel donne aux extensions :

• Des identifiants DNS inversés.
• Une négociation des capacités.
• Un versionnage indépendant.
• Des dépôts dédiés.
• Des mainteneurs délégués.
• Une piste d'extension formelle dans le processus SEP.

C'est important car le protocole central n'a pas besoin d'absorber chaque nouvelle idée.

Une fonctionnalité peut d'abord mûrir comme extension, et les capacités validées peuvent ensuite se rapprocher du cœur.

MCP Apps : UI interactive dans la conversation

L'une des extensions MCP les plus visibles est MCP Apps.

Les outils MCP renvoient traditionnellement du texte, du JSON structuré ou des ressources.

Certaines tâches nécessitent des interfaces.

Les exemples incluent les tableaux de bord, les graphiques, les cartes, les formulaires, les tableaux de tâches, les panneaux de configuration, les toiles de conception et les lecteurs vidéo.

MCP Apps permet au serveur de déclarer une ressource UI, rendue dans un iframe sandboxé.

![L'image montre le flux interactif de MCP Apps. L'utilisateur envoie la commande « show me analytics » à l'agent, et l'agent rend une application interactive dans le chat. L'application interagit avec le serveur MCP via des appels d'outils. Le serveur renvoie des entrées/résultats d'outils, et les résultats sont poussés vers l'application.]

L'utilisateur interagit avec l'application, l'application demande un appel d'outil, le serveur renvoie des données fraîches, l'application se met à jour avec les nouvelles données. Ce schéma est étroitement lié au contexte et illustre directement le processus d'interaction complet des applications MCP, de l'instruction utilisateur à la mise à jour de l'application.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/c7e4e5a5-3b69-4999-be13-41aa3f213186-be0c3bc3-5210-4e7e-971e-c9b0e2d35daf.png)

Le processus simplifié est le suivant :

1. L'outil déclare une ressource d'interface utilisateur.
2. Le modèle appelle cet outil.
3. L'hôte charge l'interface utilisateur dans le sandbox.
4. Les données de l'outil sont transmises à l'interface.
5. L'utilisateur interagit avec l'application.
6. L'application peut demander des appels d'outil supplémentaires via l'hôte.
7. L'hôte maintient un contrôle des autorisations et d'audit sur ces opérations.

Les applications MCP sont prises en charge par plusieurs hôtes compatibles, notamment Claude et d'autres produits de développement prenant en charge MCP.

Installation de base des applications MCP

Le pack d'extension officiel peut être installé avec la commande suivante :

npm install -S @modelcontextprotocol/ext-apps

Le dépôt de code d'exemple officiel peut être exécuté localement :

git clone https://github.com/modelcontextprotocol/ext-apps.git
cd ext-apps
npm install
npm start

Ces commandes proviennent de la documentation officielle des applications MCP et peuvent évoluer avec les versions de l'extension.

Tasks : travaux de longue durée sans blocage de connexion

Les outils d'agent lancent de plus en plus de travaux qui ne peuvent pas être terminés pendant une simple requête HTTP.

Cela inclut les pipelines CI, les tâches de traitement de données volumineuses, les déploiements cloud, les tâches de recherche longues, le rendu vidéo et les processus d'approbation humaine.

L'extension MCP Tasks permet au serveur de renvoyer un identifiant de tâche persistant au lieu de bloquer en attendant la fin de l'opération.

Les méthodes définies par l'extension officielle incluent :

tasks/get
tasks/update
tasks/cancel

Les tâches peuvent passer entre les états suivants :

working
input_required
completed
cancelled
failed

Le client peut interroger en boucle tasks/get.

Si le serveur a besoin d'une saisie utilisateur, la tâche peut passer à l'état input_required.

Le client peut soumettre l'entrée via tasks/update.

Cette conception fonctionne également en cas de déconnexion et ne nécessite pas de connexion longue durée.

Remarque importante sur la compatibilité

La fonctionnalité de tâches existait à titre expérimental dans la spécification de base 2025-11-25.

La nouvelle extension Tasks n'est pas une simple copie renommée de l'ancienne API.

La documentation officielle du SDK avertit que la nouvelle extension Tasks est incompatible au niveau du protocole fil avec les implémentations expérimentales antérieures.

Les applications utilisant l'ancienne fonctionnalité Tasks doivent migrer et ne peuvent pas compter sur une compatibilité automatique.

Autorisation gérée en entreprise

Les déploiements en entreprise rencontrent des problèmes d'autorisation différents de ceux des intégrations grand public.

Une entreprise peut avoir des milliers d'employés et des dizaines de serveurs MCP approuvés.

Elle ne souhaite pas que chaque employé autorise indépendamment chaque connecteur.

L'extension Autorisation gérée en entreprise permet aux organisations de centraliser la gestion des contrôles d'accès via un fournisseur d'identité.

Les modes IdP d'entreprise pris en charge peuvent impliquer des produits comme Microsoft Entra ID, Okta ainsi que les systèmes SSO d'entreprise.

Les organisations peuvent décider quels employés peuvent accéder à quels serveurs MCP et quand révoquer les accès.

Les employés s'authentifient avec leur identité d'entreprise, sans avoir à effectuer une approbation OAuth distincte pour chaque serveur MCP.

La documentation officielle de MCP décrit l'autorisation gérée en entreprise comme une extension, et non comme une fonctionnalité activée par défaut sur chaque client.

L'infrastructure d'identité du client et de l'organisation doit prendre en charge cette extension.

Les mécanismes d'autorisation sont renforcés plus largement

Le travail d'autorisation central a également bénéficié de plusieurs améliorations de sécurité.

Vérification de l'émetteur RFC 9207

Les réponses d'autorisation peuvent inclure le paramètre d'émetteur iss.

Le client vérifie l'émetteur avant d'échanger le code d'autorisation.

Cela aide à prévenir les attaques de confusion de serveur d'autorisation.

Les informations d'identification du client restent liées à leur émetteur

Les informations d'identification de client enregistrées ne doivent pas être réutilisées entre des serveurs d'autorisation sans rapport.

Lorsque les ressources sont transférées vers d'autres émetteurs, le client doit être enregistré de manière appropriée auprès de cet émetteur.

Enregistrement amélioré pour le bureau et la CLI

Cette révision clarifie le comportement de application_type lors de l'enregistrement dynamique de clients.

Cela aide à éviter que les serveurs d'autorisation traitent les applications CLI natives ou de bureau comme des clients web et rejettent les URI de redirection locales.

CIMD, la nouvelle orientation pour l'enregistrement des clients

Le projet d'autorisation MCP a avancé vers les documents de métadonnées d'identifiant client (Client ID Metadata Documents, ou CIMD) pour les nouvelles implémentations, tout en conservant la compatibilité DCR là où elle est nécessaire.

La recommandation pratique est de suivre la documentation d'autorisation actuelle, plutôt que de mettre en œuvre l'enregistrement de client sur la base d'anciens tutoriels MCP.

JSON Schema 2020-12 complet pour les outils

Les schémas d'outils sont également devenus plus expressifs.

inputSchema et outputSchema prennent en charge l'ensemble des fonctionnalités de JSON Schema 2020-12.

Les schémas d'entrée peuvent utiliser :

oneOf
anyOf
allOf
$ref
$defs
déclarations conditionnelles

Les schémas de sortie ne sont plus limités à une seule forme d'objet étroite.

structuredContent peut représenter n'importe quelle valeur JSON prise en charge par le schéma.

Cela permet aux outils MCP de décrire plus précisément les API lorsqu'elles présentent des types d'union, des champs conditionnels, des définitions réutilisables imbriquées, des formes de sortie multiples, ou des résultats sous forme de tableaux ou de scalaires.

Roots, Sampling et Logging sont dépréciés

Trois capacités centrales plus anciennes ont été officiellement dépréciées :

La dépréciation ne signifie pas une suppression immédiate.

La nouvelle politique de cycle de vie précise qu'une fonctionnalité dépréciée doit bénéficier d'une période de transition d'au moins douze mois avant de pouvoir être supprimée.

Les SDK actuels peuvent continuer à prendre en charge ces capacités pour préserver la compatibilité.

La politique de dépréciation officielle change le risque de mise à niveau de MCP

La refonte sans état inclut des changements cassants.

Les mainteneurs indiquent qu'ils ne souhaitent pas que ce niveau de rupture devienne la norme.

Le nouveau cycle de vie fonctionnel définit les phases suivantes :

Actif
Déprécié
Supprimé

Les fonctionnalités dépréciées bénéficient d'une période minimale de support avant leur suppression.

Les extensions peuvent également évoluer indépendamment du cœur de protocole.

Cela offre aux équipes une planification de migration plus prévisible.

Les tunnels MCP répondent à un problème d'entreprise différent

La révision du protocole facilite la mise à l'échelle des serveurs MCP distants publics.

Les entreprises sont souvent confrontées au problème inverse : elles ne veulent tout simplement pas exposer leurs serveurs publiquement.

La fonctionnalité Tunnels MCP d'Anthropic répond à ce cas d'usage pour les agents hébergés par Claude et les workflows de la plateforme Claude prise en charge.

Une passerelle légère s'exécute au sein du réseau d'entreprise et établit des connexions sortantes.

Anthropic décrit ce modèle ainsi :

• Aucun point de terminaison MCP public.
• Aucune règle de pare-feu entrante.
• Aucune adresse IP publique requise.
• Trafic chiffré de bout en bout.

Les bases de données internes, les systèmes ERP, les API privées, les bases de connaissances et les systèmes de tickets peuvent rester derrière la frontière du réseau d'entreprise.

Les tunnels MCP restent une fonctionnalité produit de Claude, et non une exigence du protocole MCP central.

Anthropic les décrit actuellement comme un aperçu de recherche.

Applications MCP et tunnels : ne pas confondre

Ces deux fonctionnalités améliorent MCP en environnement de production, mais elles résolvent des problèmes différents.

Les serveurs peuvent utiliser une, plusieurs ou la totalité de ces fonctionnalités.

Que doivent changer les développeurs de serveurs MCP existants ?

Si un serveur fonctionne déjà avec d'anciens clients MCP, les développeurs ne sont pas obligés de tout réécrire immédiatement.

Ils doivent effectuer une migration structurée.

Étape 1 : Inventorier les dépendances cachées de session

Recherchez le code qui s'appuie sur :

• Mcp-Session-Id
• Dictionnaires en mémoire par session
• Routage persistant (sticky routing)
• État client local à la connexion
• Stockage de capacités uniquement à l'initialisation
• Affinité d'instance de serveur

Déterminez si chaque dépendance relève de l'état de protocole, de l'état applicatif, de l'état d'authentification ou d'un état d'exécution temporaire.

Déplacez l'état applicatif vers des gestionnaires explicites ou un stockage persistant approprié.

Étape 2 : Tester le traitement des requêtes sans état

Utilisez une version du SDK prenant en charge la révision 2026-07-28.

Ensuite, testez avec plusieurs instances de serveur.

Une configuration de test utile est la suivante :

Client
↓
Équilibreur de charge par sondage (round-robin)
↓
Serveur A / Serveur B / Serveur C

Envoyez un workflow en plusieurs étapes et confirmez que les requêtes successives peuvent atteindre des instances différentes sans interrompre la tâche.

Étape 3 : Ajouter des gestionnaires d'état explicites

Pour les workflows nécessitant un état, renvoyez un identifiant stable :

{
"job_id": "job_7f18c9"
}

Exigez que les appels suivants incluent cet identifiant :

{
"job_id": "job_7f18c9",
"action": "continue"
}

Validez chaque gestionnaire côté serveur.

Un bon gestionnaire doit avoir une entropie élevée, une liaison au locataire, des contrôles d'autorisation, une expiration, un mécanisme de révocation et une gestion claire des erreurs.

Étape 4 : Mettre à jour les règles de passerelle

Si vous utilisez Streamable HTTP, exploitez les en-têtes suivants :

Mcp-Method
Mcp-Name

Ajoutez le routage, les limites de débit, les métriques, les politiques WAF et les journaux d'accès.

Étape 5 : Ajouter la prise en charge du cache

Pour les réponses de liste et de lecture appropriées, respectez ou générez :

ttlMs
cacheScope

Ne partagez pas entre utilisateurs le contenu sensible du cache spécifique aux données utilisateur.

Étape 6 : Migrer les anciennes tâches

Si l'application utilisait l'API expérimentale 2025-11-25 Tasks, mettez-la à jour vers le cycle de vie étendu.

Testez :

tasks/get
tasks/update
tasks/cancel

ainsi que l'état input_required.

Étape 7 : Examiner les fonctionnalités dépréciées

Recherchez Roots, Sampling et MCP Logging.

Planifiez la migration vers des paramètres d'outil explicites ou des URI de ressources, des appels directs au fournisseur de modèles, et stderr ou OpenTelemetry.

Étape 8 : Retester l'autorisation

Vérifiez la validation de l'émetteur, les URI de redirection, l'enregistrement des clients, les jetons d'actualisation, la gestion des portées et la compatibilité avec le fournisseur d'identité.

Les déploiements d'entreprise doivent évaluer si l'EMA est applicable.

Étape 9 : Tester les anciens clients

La rétrocompatibilité est un problème d'écosystème, pas seulement de serveur.

Maintenez une matrice de tests :

Ne supposez pas silencieusement que chaque client effectue la mise à niveau simultanément.

Étape 10 : Ajouter l'observabilité avant la production

Mesurez au minimum :

• Nombre de requêtes.
• Noms des outils.
• Latence.
• Taux d'erreur.
• Durée des tâches.
• Fréquence des demandes de saisie.
• Taux de succès du cache.
• Nombre d'échecs d'authentification.
• Latence des API en aval.
• ID de trace.

Les systèmes sans état sont plus faciles à mettre à l'échelle, mais les systèmes distribués nécessitent toujours une bonne observabilité.

Exemple : Avant et après migration

Avant migration

Le serveur stocke les objets de rapport en mémoire :

sessions[session_id]["report"] = report

L'appel d'outil suivant s'attend à atteindre le même processus.

Après migration

Le serveur stocke l'état persistant :

report_id = save_report(report)
return {"report_id": report_id}

L'outil suivant reçoit :

{
"report_id": "report_123"
}

N'importe quelle instance de serveur peut charger ce rapport.

Le changement clé se situe au niveau de l'architecture :

État de session de transport caché
→ État applicatif explicite

Un MCP sans état signifie-t-il des coûts réduits ?

C'est possible, mais pas automatique.

Un déploiement sans état peut réduire la complexité de l'infrastructure :

• Aucun stockage de session MCP partagé.
• Moins de besoins en routage persistant.
• Mise à l'échelle automatique plus facile.
• Déploiements serverless plus simples.
• Basculement simplifié.

La mise en cache peut également réduire les appels de métadonnées répétés.

Cependant, l'état applicatif a toujours un coût.

Si les workflows nécessitent un état persistant, les développeurs peuvent toujours avoir besoin de Redis, d'une base de données SQL, d'un stockage d'objets, d'une file de tâches ou d'un moteur de workflows.

La nouvelle conception permet aux développeurs de choisir l'architecture de stockage, plutôt que de laisser la session du protocole imposer une solution unique.

MCP devient-il « le HTTP de l'IA » ?

L'article source utilise cette analogie.

Cette analogie est utile, mais elle ne doit pas être prise au pied de la lettre.

HTTP est le standard de transport fondamental du Web, utilisé dans presque tous les systèmes internet.

MCP est un protocole spécialisé, conçu pour connecter les clients et agents IA à des outils, ressources, invites, interfaces et services externes.

Ce que cette analogie capture, c'est la direction du développement :

• Une interface standard.
• De nombreux serveurs indépendants.
• De nombreux clients compatibles.
• Des conventions partagées.
• Une infrastructure capable d'acheminer et d'observer les requêtes de manière universelle.

La refonte de 2026-07-28 renforce cette analogie, car le trafic MCP s'adapte désormais plus naturellement à l'infrastructure HTTP sans état traditionnelle.

La question de savoir si MCP atteindra un degré d'adoption comparable à celui de HTTP reste ouverte.

Un écosystème plus large que Claude

MCP est né chez Anthropic, mais il est maintenant gouverné comme un projet de protocole open source plus vaste.

Cet écosystème comprend des mainteneurs indépendants, des groupes de travail, des propositions d'amélioration de la spécification, des SDK dans plusieurs langages, des applications MCP, des tâches, des extensions d'autorisation d'entreprise, des registres, ainsi que des implémentations dans plusieurs produits d'IA.

Par exemple, les applications MCP sont développées avec des contributeurs de la communauté MCP ainsi qu'avec des participants d'Anthropic, d'OpenAI et de MCP-UI.

C'est important, car la valeur d'un protocole augmente lorsque les clients et les serveurs peuvent l'implémenter sans dépendre d'un fournisseur unique.

Paysage actuel des SDK

Le projet MCP officiel maintient ou reconnaît des implémentations SDK dans plusieurs langages.

Les dépôts principaux incluent des SDK pour TypeScript, Python, Go, C# et d'autres écosystèmes.

Juin 2026

L'annonce de la version candidate a particulièrement mis en avant la prise en charge bêta de quatre SDK de premier niveau :

• TypeScript.
• Python.
• Go.
• C#.

Fin juillet, la documentation actuelle du SDK inclut le comportement de 2026-07-28.

Étant donné que l'adoption des SDK se fait de manière indépendante, consultez toujours les notes de version de la version et du langage exacts que vous utilisez.

Une stratégie de migration plus sûre

Pour les systèmes de production, évitez les migrations de type « jour de bascule ».

Un processus plus sûr est le suivant :

1. Mettre à niveau l'environnement de développement.
2. Exécuter les tests de conformité.
3. Tester les clients 2026-07-28.
4. Tester les anciens clients.
5. Activer le déploiement sans état dans l'environnement de préproduction.
6. Ajouter plusieurs instances de serveur.
7. Forcer la distribution des requêtes entre les instances.
8. Tester l'authentification.
9. Tester les tâches de longue durée.
10. Tester les identifiants d'état d'application.
11. Surveiller la latence et les erreurs.
12. Déployer progressivement.

C'est particulièrement important car la nouvelle révision modifie intentionnellement le comportement fondamental du cycle de vie.

Ce qu'il ne faut pas supposer

Ne supposez pas que chaque serveur est automatiquement sans serveur

Le protocole prend plus naturellement en charge les déploiements sans serveur.

Votre application peut encore nécessiter une base de données, des exécuteurs de tâches persistants, un stockage de fichiers ou des temps d'exécution plus longs.

Ne supposez pas que tout l'état disparaîtra

Seul l'état de session au niveau du protocole est supprimé du nouveau modèle en ligne.

L'état de l'application reste un problème propre à l'application elle-même.

Ne supposez pas que les applications MCP fonctionneront dans tous les clients

Les extensions sont négociées, et la prise en charge varie selon les hôtes.

Ne supposez pas que les tâches sont rétrocompatibles

L'extension Tasks actuelle diffère des implémentations expérimentales antérieures.

Ne supposez pas que l'abandon signifie l'inutilité

Roots, Sampling et Logging restent disponibles pendant la période de dépréciation.

Ne supposez pas que tous les clients prennent déjà en charge 2026-07-28

Les rythmes d'adoption des SDK et des produits varient.

Ne supposez pas qu'un « protocole ouvert » signifie « pas de travail de sécurité »

MCP peut exécuter des outils puissants.

L'autorisation, le consentement de l'utilisateur, le cloisonnement (sandboxing), la conception des outils, la gestion des secrets et l'audit restent essentiels.

Questions fréquentes

Qu'est-ce que MCP 2026-07-28 ?

MCP 2026-07-28 est la plus grande révision architecturale du Model Context Protocol depuis son lancement. Ses principaux changements incluent un cœur de protocole sans état, la suppression de la poignée de main de session dans le nouveau format en ligne, des extensions de premier niveau, des applications MCP, des tâches repensées, MRTR, une autorisation renforcée, des métadonnées de cache et une politique de dépréciation officielle.

MCP est-il désormais entièrement sans état ?

La couche protocolaire de 2026-07-28 est conçue pour être sans état. Les applications peuvent toujours conserver l'état via des identifiants explicites, des bases de données, des systèmes de flux de travail ou d'autres stockages persistants.

Qu'est-il arrivé à Mcp-Session-Id ?

Le format en ligne de 2026-07-28 supprime le mécanisme Mcp-Session-Id au niveau du protocole. Les SDK actuels peuvent encore prendre en charge le comportement basé sur les sessions pour les anciennes révisions du protocole, afin d'assurer la rétrocompatibilité.

Puis-je déployer un serveur MCP sur AWS Lambda ou Cloudflare Workers ?

Le protocole sans état facilite les déploiements sans serveur et en périphérie, car les requêtes ne nécessitent plus d'affinité de session au niveau du protocole. Votre serveur doit toujours respecter les limites d'exécution, de réseau, de stockage et de durée du runtime.

Qu'est-ce qu'une application MCP ?

Une application MCP est une extension officielle

qui permet aux outils de renvoyer des interfaces interactives, telles que des tableaux de bord, des formulaires, des graphiques et d'autres expériences HTML, au sein d'un hôte MCP compatible. Cette interface s'exécute dans un iframe cloisonné et communique via l'hôte MCP.

Qu'est-ce qu'une tâche MCP ?

La fonctionnalité Tasks permet au serveur de renvoyer des identifiants de tâches asynchrones et persistants pour des travaux de longue durée. Le client peut interroger l'état via tasks/get, fournir les entrées requises via tasks/update, ou annuler l'opération via tasks/cancel.

Qu'est-ce que l'autorisation hébergée d'entreprise ?

L'autorisation hébergée d'entreprise est une extension de MCP qui permet un contrôle d'accès centralisé via le fournisseur d'identité de l'organisation. Elle permet aux administrateurs informatiques de gérer l'accès aux serveurs MCP en fonction des politiques d'identité de l'entreprise, sans que chaque utilisateur n'ait à autoriser individuellement chaque serveur.

Dois-je migrer immédiatement depuis l'ancienne version de MCP ?

Pas nécessairement. Les SDK peuvent prendre en charge les anciennes révisions du protocole via la négociation de version, et les fonctionnalités dépréciées bénéficient d'une fenêtre de prise en charge explicite. Les équipes de production devraient néanmoins commencer les tests, car la conception sans état modifie les hypothèses concernant les sessions, les opérations de longue durée et l'infrastructure.

Outils connexes

• Model Context Protocol : documentation officielle de la spécification MCP, de l'architecture, des SDK, des extensions et des guides pour développeurs.
• SDK TypeScript MCP : implémentation officielle TypeScript pour les clients et serveurs MCP.
• SDK Python MCP : SDK Python officiel et exemples pour le développement MCP.
• SDK Go MCP : implémentation officielle Go, prenant actuellement en charge le chemin de protocole sans état.
• SDK C# MCP : SDK .NET officiel, avec documentation détaillée sur les modes sans état, les tâches et la compatibilité.
• Applications MCP : documentation officielle des extensions et SDK pour les interfaces interactives au sein des hôtes MCP.
• Tâches MCP : documentation officielle des opérations asynchrones MCP de longue durée.
• [Registre MCP](https://registry.modelcontextprotocol.

io/) : infrastructure de registre officielle pour découvrir les serveurs MCP publiés.

Liens connexes

• Aperçu de la version candidate MCP du 28/07/2026 : explications des mainteneurs officiels sur la refactorisation sans état, les extensions, les changements d'authentification, la mise en cache et les éléments dépréciés.
• Publications du dépôt de spécification MCP : historique officiel des publications GitHub des révisions du protocole.
• Feuille de route MCP 2026 : feuille de route officielle couvrant l'extensibilité des transports, la communication entre agents, la gouvernance et la préparation pour l'entreprise.
• Documentation officielle des applications MCP : spécifications, SDK, exemples et guides pour développeurs des applications MCP interactives.
• Extension des tâches MCP :

spécification officielle des tâches, cycle de vie, modèle de sécurité et méthodes prises en charge.

• Autorisation gérée par l'entreprise : documentation officielle sur l'accès MCP basé sur des fournisseurs d'identité centralisés.
• Tunnels MCP Anthropic : documentation d'Anthropic sur les connexions MCP en réseau privé dans les agents gérés par Claude.

Résumé

La révision MCP du 28/07/2026 fait évoluer le protocole vers des modèles d'infrastructure couramment adoptés dans les grands systèmes Web. Les requêtes deviennent autonomes, les sessions au niveau du protocole disparaissent du nouveau format en ligne, le routage des passerelles devient plus simple, et la mise à l'échelle horizontale ordinaire ne nécessite plus de sessions MCP persistantes.

Parallèlement, l'écosystème progresse également. Les applications MCP ajoutent des interfaces utilisateur interactives, les tâches prennent en charge le travail asynchrone persistant, l'autorisation gérée par l'entreprise centralise les accès des entreprises, et les tunnels MCP offrent aux utilisateurs de la plateforme Claude un accès aux serveurs privés internes.

La migration ne consiste pas simplement à "supprimer les identifiants de session". Les équipes doivent identifier les dépendances d'état cachées, migrer l'état des applications vers des gestionnaires explicites ou un stockage persistant, tester les MRTR et les tâches, mettre à jour l'autorisation, maintenir la compatibilité avec les anciens clients et ajouter une observabilité appropriée.

Le changement le plus important est au niveau architectural : MCP passe d'un modèle d'intégration d'agents orienté connexion à un protocole sans état et extensible, s'adaptant ainsi plus naturellement à l'infrastructure cloud moderne.