Une pull request déposée sur le Model Context Protocol Python SDK officiel a été fusionnée à 14:54 UTC le 28 août, modifiant deux valeurs par défaut qui déterminent combien de temps les serveurs MCP conservent les connexions et combien ils en accepteront.

Les deux valeurs par défaut

Délai d’inactivité de session passe de non défini à 1 800 secondes, si bien qu’une session sans activité pendant trente minutes est révoquée. Nombre maximal de sessions simultanées passe de illimité à 10 000 ; au-delà, un serveur répond avec HTTP 503 et le code d’erreur JSON-RPC -32603. Les deux sont des valeurs par défaut défendables — des tables de session sans limite constituent une surface de déni de service, et un délai d’inactivité sans limite entraîne une fuite de ressources.

Ce que l’encadrement habituel laisse de côté

Les métadonnées indiquent qu’il est sûr d’intégrer ce changement, mais le corps du texte dit le contraire. La pull request comporte sa propre section « Breaking Changes », tandis que la liste de contrôle de soumission laisse la case de changement cassant non cochée et coche deux cases affirmant l’inverse. C’est cette incohérence qui se propage : les outils de publication, les générateurs de changelog et les décisions de version sémantique lisent la liste de contrôle, pas le texte. Un mainteneur qui parcourt les métadonnées en conclut qu’une incrémentation mineure est appropriée, et les opérateurs en aval effectuent la mise à jour sans lire la section qui leur indique que leurs sessions de longue durée expireront désormais.

Qui cela casse réellement

Tout déploiement qui maintient des sessions MCP ouvertes pendant de longues périodes d’attente avec intervention humaine — un agent en attente d’une validation, un assistant inactif entre le matin et l’après-midi — commencera à voir les sessions disparaître au bout d’une demi-heure. Du point de vue du client, l’échec est silencieux jusqu’à l’appel suivant. Les déploiements dépassant dix mille sessions simultanées commenceront à refuser les connexions avec un code que la plupart des clients MCP ne distinguent pas d’une panne serveur.

Où en est la modification

Le changement a été fusionné dans la branche principale et n’est pas encore dans une version publiée, donc rien n’a été livré à qui que ce soit via un gestionnaire de paquets aujourd’hui. C’est précisément la fenêtre pendant laquelle la liste de contrôle peut encore être corrigée et où l’incrément de version peut être choisi délibérément.