KDnuggets explique comment déployer un serveur MCP stateless en Python accessible via HTTP

Le 9 octobre 2026, KDnuggets a publié un guide pas à pas intitulé « Build Your First MCP Server in Python (Stateless Spec Edition) ». Il montre comment écrire un serveur MCP en Python et exposer en HTTP les trois primitives du Model Context Protocol : les outils (tools), les ressources (resources) et les prompts. L'accent porte sur le mot stateless : le serveur ne conserve aucune session entre les appels. L'annonce est courte, et tous les détails de l'édition de la spécification devront être vérifiés dans la documentation officielle. La direction, en revanche, est claire : le protocole sur lequel repose la connexion des agents à des systèmes externes devient plus simple à exploiter.

Pourquoi l'état est le principal point de friction

MCP a été conçu comme une méthode unique pour connecter à un modèle de langage des fonctions et des données externes. Les premières implémentations s'appuyaient sur stdio et sur des connexions de longue durée. Pour un prototype local, c'est pratique. En production, les problèmes commencent : il faut stocker la session quelque part, router les requêtes vers la même instance, le scaling horizontal se complique, et les plateformes serverless s'accommodent très mal des connexions longues.

L'approche stateless lève ces contraintes. Chaque requête HTTP est autosuffisante : elle arrive, elle est traitée, elle reçoit une réponse. Le serveur peut se placer derrière un répartiteur de charge classique, tourner en plusieurs copies et redémarrer sans perte de contexte. Si un état reste nécessaire, il vit dans un stockage externe, et non dans la mémoire du processus.

Ce que contient le guide

Le document s'adresse à ceux qui construisent leur premier serveur MCP. Voici ce que l'annonce indique :

• Langage : Python
• Transport : HTTP
• Primitives : 3 (tools, resources, prompts)
• Mode : stateless, sans sessions entre les requêtes
• Source et date : KDnuggets, 9 octobre 2026

Les rôles des primitives diffèrent, et les confondre à la conception coûte cher. Les tools sont des fonctions que le modèle appelle lui-même : recherche, requête vers une API, écriture dans une base. Les resources sont des données adressables par URI : fichiers, documents, lignes de tableau. Les prompts sont des modèles d'instructions préparés à l'avance, que choisit généralement l'utilisateur ou l'application cliente.

Le choix du HTTP plutôt que d'un processus local est révélateur. Un tel serveur est accessible à plusieurs clients et à plusieurs équipes, peut être protégé par une authentification et se supervise comme n'importe quel autre service réseau.

Comment l'utiliser en pratique

Mieux vaut commencer petit. Créez un seul outil avec une signature et une description claires : le modèle choisit les fonctions précisément d'après leur description, et un texte vague se traduit par des appels erronés. Ajoutez ensuite une ressource et un prompt pour voir les trois primitives à l'œuvre. Testez le serveur avec un outil de débogage comme MCP Inspector avant de le connecter à un véritable agent.

Avant la mise en production, trois vérifications s'imposent. Première : la version de la spécification et celle du SDK. L'« édition stateless » signifie qu'une partie des anciens exemples peut se comporter différemment. Deuxième : l'endroit où est stocké tout ce qui vivait auparavant dans la session. Paniers, tokens et résultats intermédiaires doivent être déplacés vers Redis ou une base de données. Troisième : l'authentification et la limitation des droits des outils. Un serveur capable d'écrire dans une base ne doit pas être ouvert à tout Internet.

Pour les équipes qui construisent des agents, le guide constitue un bon point d'entrée. Il ne remplace pas la spécification, mais montre un squelette minimal fonctionnel, à partir duquel on peut avancer vers ses propres intégrations.