Le protocole MCP déprécie Roots, Sampling et Logging pour se simplifier
La nouvelle révision de la spécification du Model Context Protocol rend le protocole sans état et déprécie plusieurs fonctionnalités historiques. Les serveurs MCP doivent désormais s'orienter vers des intégrations directes d'API et des paramètres explicites.
Fil « Dépréciation de fonctionnalités clés dans la spécification MCP »
Le protocole standard Model Context Protocol (MCP, le protocole ouvert permettant de connecter des assistants IA à des outils et des données de code) fait évoluer sa spécification. L'objectif principal de cette révision est de simplifier l'architecture globale en éliminant la gestion d'état au niveau du protocole, tout en amorçant la dépréciation de plusieurs briques historiques.
Ce qui change pour vos serveurs MCP
La modification majeure réside dans la dépréciation formelle des fonctionnalités Roots, Sampling et Logging (portée par le SEP-2577). Ces fonctionnalités restent utilisables pendant une période de transition garantie d'au moins 12 mois, mais la spécification conseille de ne plus les intégrer dans vos nouveaux projets.
Pour remplacer ces briques, des alternatives plus explicites sont préconisées :
- Roots (gestion des répertoires et fichiers de projet) : passer les répertoires ou fichiers directement via les paramètres des outils, les URI de ressources ou la configuration du serveur.
- Sampling (demande de génération de texte IA par le serveur) : intégrer directement les API des fournisseurs de modèles de langage (LLM, Large Language Models).
- Logging (flux de journaux applicatifs) : utiliser la sortie d'erreur standard (
stderr) ou OpenTelemetry (un standard ouvert de collecte de métriques et de traces).
Passage au mode sans état et requêtes multi-allers-retours
En parallèle, MCP devient totalement sans état (stateless). L'étape d'initialisation préalable (initialize / notifications/initialized) ainsi que les sessions au niveau du protocole sont supprimées. Chaque requête embarque désormais directement sa version de protocole et les capacités du client dans le champ _meta.
Un nouvel appel de procédure à distance, server/discover (RPC, Remote Procedure Call), permet au serveur d'annoncer son identité et les versions supportées. Pour remplacer les requêtes initiées par le serveur vers le client, le protocole adopte le motif Multi Round-Trip Requests (MRTR) : le serveur retourne une réponse intermédiaire contenant le type resultType: "input_required" afin de réclamer les informations manquantes.
{
"jsonrpc": "2.0",
"id": 101,
"result": {
"resultType": "input_required",
"inputRequests": [
{
"uri": "file:///workspace/config.json"
}
]
}
}
Caching et abandon progressif de l'HTTP+SSE
Sur le réseau, le transport HTTP+SSE (Server-Sent Events, la technologie d'envoi d'événements du serveur vers le client) est classé comme déprécié au profit du transport Streamable HTTP. Enfin, afin d'optimiser le taux de succès du cache d'instructions (prompt cache hit rate), la réponse aux requêtes comme tools/list implémente l'interface CacheableResult et exige désormais deux champs : ttlMs (durée de fraîcheur du cache en millisecondes) et cacheScope (définissant une portée public ou private).