Le protocole de contexte de modèle a connu sa plus grande révision architecturale depuis sa publication. MCP a d'abord été introduit comme u...
模型上下文协议（Model Context Protocol）迎来了自发布以来最大规模的一次架构修订。
MCP最初被引入时，是作为一种让AI应用将模型与工具、API、数据源、文件及外部系统连接起来的通用方式。在不到两年的时间里，它已从一个由Anthropic主导的集成项目，发展成为一个更广泛的开源协议，拥有自己的治理流程、SDK生态系统、工作组、扩展以及横跨众多AI产品的实现。
2026-07-28修订版聚焦于MCP离开开发者笔记本电脑、进入大型生产环境时出现的问题。
最主要的变更可以概括为：
MCP正在协议层转变为无状态。
这一变更从新的线上格式中移除了协议级的会话和初始化握手，使远程MCP服务器能够更轻松地部署在普通负载均衡器、无服务器基础设施、边缘计算节点和水平扩展架构之后。
但无状态传输只是本次更新的一部分。
该修订版还正式确立了一个扩展框架，重塑了长时间运行的任务，引入了多轮往返请求，增加了可路由的HTTP头和缓存提示，强化了授权机制，扩展了JSON Schema支持，并制定了一项正式的功能弃用策略。
在协议本身之外，MCP生态系统还在增加交互式应用、企业级托管授权、私有网络隧道以及更强大的开发者工具。
正是在这一点上，MCP开始不再像一个便捷的智能体连接器，而更像生产级基础设施。
源报告强调了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 维护者得出的结论是，这些要求与协议本身的耦合过于紧密。
新修订版本移除了这一假设。
在 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.
Les handles visibles présentent plusieurs avantages.
Le modèle peut :
Le serveur peut :
Ainsi, MCP sans état déplace la gestion de l'état de la couche de transport vers une conception applicative explicite.
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 :
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.
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 :
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.
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 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 :
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 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 révision documente également la propagation du contexte de trace W3C.
Des clés telles que :
traceparenttracestatebaggagepeuvent ê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.
Le protocole évolue également dans la manière dont les fonctionnalités optionnelles progressent.
Le cadre actuel donne aux extensions :
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.
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 :
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.
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.
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.
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.
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.
Le travail d'autorisation central a également bénéficié de plusieurs améliorations de sécurité.
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.
Decrivez votre idee une fois, et We0 AI peut generer un site vitrine, des pages et un CMS, puis vous aider a attirer clients et trafic apres le lancement.
Une génération de projet complète pour une inscription gratuite
Idéal pour essayer un flux de génération complet et voir rapidement une première ébauche de projet.
Cela aide à prévenir les attaques de confusion de serveur d'autorisation.
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.
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.
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.
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.
Trois capacités centrales plus anciennes ont été officiellement dépréciées :
| Fonctionnalité | Direction recommandée |
|---|---|
| Roots | Paramètres d'outil, URI de ressources, ou configuration serveur |
| Sampling | Intégration directe auprès des fournisseurs de LLM |
| Logging | stderr pour stdio ; OpenTelemetry pour l'observabilité structurée |
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 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.
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 :
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.
Ces deux fonctionnalités améliorent MCP en environnement de production, mais elles résolvent des problèmes différents.
| Fonctionnalité | Problème résolu |
|---|---|
| Applications MCP | Interfaces riches au sein des hôtes MCP |
| Tâches | Opérations d'outils persistantes de longue durée |
| Autorisation d'hébergement d'entreprise | Stratégies d'accès centralisées en entreprise |
| Tunnels MCP | Accès aux serveurs MCP privés sans exposition publique |
| Cœur MCP sans état | Transport de protocole évolutif |
| MRTR | Saisie client en cours d'appel sans session de protocole de longue durée |
Les serveurs peuvent utiliser une, plusieurs ou la totalité de ces fonctionnalités.
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.
Recherchez le code qui s'appuie sur :
Mcp-Session-IdDé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é.
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.
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.
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.
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.
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.
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.
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.
La rétrocompatibilité est un problème d'écosystème, pas seulement de serveur.
Maintenez une matrice de tests :
| Client | Révision du protocole | Résultat |
|---|---|---|
| Client actuel | 2026-07-28 | Chemin sans état attendu |
| Ancien client | 2025-11-25 | Chemin de compatibilité |
| Client non pris en charge | Version ancienne/inconnue | Échec de négociation explicite |
Ne supposez pas silencieusement que chaque client effectue la mise à niveau simultanément.
Mesurez au minimum :
Les systèmes sans état sont plus faciles à mettre à l'échelle, mais les systèmes distribués nécessitent toujours une bonne observabilité.
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.
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
C'est possible, mais pas automatique.
Un déploiement sans état peut réduire la complexité de l'infrastructure :
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.
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 :
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.
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.
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 :
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.
Pour les systèmes de production, évitez les migrations de type « jour de bascule ».
Un processus plus sûr est le suivant :
2026-07-28.C'est particulièrement important car la nouvelle révision modifie intentionnellement le comportement fondamental du cycle de vie.
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.
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.
Les extensions sont négociées, et la prise en charge varie selon les hôtes.
L'extension Tasks actuelle diffère des implémentations expérimentales antérieures.
Roots, Sampling et Logging restent disponibles pendant la période de dépréciation.
2026-07-28Les rythmes d'adoption des SDK et des produits varient.
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.
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.
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.
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é.
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.
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.
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.
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.
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.
io/) : infrastructure de registre officielle pour découvrir les serveurs MCP publiés.
spécification officielle des tâches, cycle de vie, modèle de sécurité et méthodes prises en charge.
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.
Partez d’une phrase et obtenez un site complet en quelques minutes.
