Héberger un serveur MCP : hébergé, auto-hébergé ou serverless

Prends l'hébergé quand ton agent a besoin d'OAuth, de refresh de tokens et d'une disponibilité que tu ne veux pas porter. Prends l'auto-hébergé quand les données ne peuvent pas sortir de ton réseau. Le serverless est entre les deux, et c'est devenu plus simple en 2026 : la révision du 28 juillet a supprimé les sessions du protocole, donc un serveur MCP distant peut maintenant être stateless.

Ce que veut dire héberger un serveur MCP depuis la spec 2026-07-28

Un serveur MCP répond en JSON-RPC sur l'un des deux bindings. En stdio, ton client le lance comme sous-processus sur la même machine. En Streamable HTTP, c'est un service web avec un seul endpoint POST. L'hébergement ne se pose que pour le second.

La révision 2026-07-28 a changé ce que ce service doit garder en mémoire. Elle a supprimé les sessions du protocole et le flux GET autonome, et elle a déplacé la version du protocole et les capacités du client dans des champs _meta par requête que le transport recopie dans les headers HTTP. Les révisions précédentes, 2025-03-26 à 2025-11-25, faisaient l'inverse : le serveur pouvait émettre un Mcp-Session-Id, le client pouvait réouvrir un flux long avec GET, et les flux étaient reprenables avec Last-Event-ID. Aucun de ces mécanismes n'existe dans la révision actuelle, et un serveur qui ne parle qu'elle doit répondre aux GET ou DELETE sur l'endpoint MCP par un 405 Method Not Allowed.

Ce seul changement est l'essentiel de l'histoire de l'hébergement. Un serveur sans état de session est un service HTTP stateless ordinaire : fais tourner quatre réplicas derrière un load balancer, déploie en pleine conversation, perds une instance, et aucun client n'a besoin de se reconnecter. Un serveur qui parle encore les révisions 2025 doit router chaque requête vers l'instance qui détient la session, et c'est pour ça que tant de déploiements distants des débuts étaient une seule machine avec des sessions collantes et un propriétaire inquiet.

Deux réserves à connaître avant de dimensionner. Les flux ne sont plus reprenables, donc une connexion coupée veut dire que le client réémet la requête au lieu de reprendre où il s'était arrêté. Et les notifications de changement longue durée passent maintenant par le flux de réponse d'une requête subscriptions/listen, qui est un flux que tu dois garder ouvert, avec des commentaires de keep-alive, aussi longtemps que le client écoute.

Serveur MCP distant ou local : ce qui change vraiment

Un serveur stdio local hérite de ta machine : ton système de fichiers, tes variables d'environnement, ton réseau. Les credentials viennent de l'environnement, et la spec dit explicitement que les implémentations stdio ne devraient pas suivre le flow OAuth. C'est pour ça qu'un serveur local est rapide à construire et impossible à partager.

Dès que le serveur devient distant, quatre choses tombent sur celui qui le fait tourner :

• Identité. Les serveurs en HTTP sont des resource servers OAuth 2.1. Ils doivent implémenter Protected Resource Metadata (RFC 9728), vérifier que chaque token a été émis pour eux en tant qu'audience, conformément à la spec d'autorisation, et renvoyer 401 avec un header WWW-Authenticate qui porte l'URL resource_metadata et le scope requis.
• Tokens des plateformes. Le token de l'agent lui ouvre ton serveur. Ton serveur a toujours besoin de ses propres credentials pour ce qu'il appelle, et ceux-là expirent selon le calendrier de quelqu'un d'autre.
• Logs. Un appel d'outil qui a publié quelque chose est une action dans le monde réel. Sans trace par appel, tu ne peux pas dire ce que l'agent a fait à 3 h du matin.
• Disponibilité. Un agent qui ne peut pas joindre le serveur ne se dégrade pas en douceur, il annonce que l'outil n'existe pas.

Le travail que personne ne compte sur un serveur MCP hébergé

La danse OAuth est la partie que les gens estiment, et ce n'est pas la partie chère. Les parties chères sont celles qui n'ont pas de date de fin.

Le refresh des tokens est le premier. Chaque plateforme que tu connectes te rend un credential avec sa propre durée de vie et son propre rituel de renouvellement, et une expiration silencieuse ressemble exactement à un bug dans ton agent. La doc WhatsApp de PlugKit le dit concrètement : connecte un vrai numéro, parce qu'un numéro de test Meta embarque un token de 24 heures et s'arrête le lendemain.

La deuxième, c'est la boucle de consentement. Les tokens expirent, les gens révoquent des apps, et les scopes se révèlent trop étroits. La spec a un chemin pour ce dernier cas : le serveur répond 403 avec error="insufficient_scope" et les scopes nécessaires, et le client lance un flow de step-up en demandant l'union de ce qu'il avait et de ce qui vient d'être exigé. Implémente ça mal et tes utilisateurs vivent dans une boucle de redirection.

La troisième, c'est simplement être joignable. Les agents réessaient, et un agent qui réessaie un outil de publication n'est pas un événement idempotent.

Hébergé, auto-hébergé ou serverless

Le serverless paraît le moins cher et l'est souvent, pour un serveur en lecture seule au-dessus d'une API publique sans credentials à garder. Ajoute OAuth et des tokens de plateforme à rafraîchir et tu as réintroduit une base de données, un ordonnanceur et un coffre à secrets, c'est-à-dire l'infrastructure que tu évitais. Ajoute un flux de notifications ouvert et tu butes sur les limites de temps d'exécution.

L'auto-hébergement gagne sur deux arguments, et ils sont bons : les données ne peuvent vraiment pas sortir de ton réseau, ou les outils que tu exposes sont les tiens et personne ne les vend. Si l'un des deux s'applique, héberge toi-même et budgète le travail OAuth comme du vrai travail.

Où se situe PlugKit, et quand c'est la mauvaise réponse

PlugKit est le cas hébergé pour un travail précis : donner à un agent l'accès à tes comptes sociaux. Le serveur vit à https://api.plugkit.co/mcp, parle Streamable HTTP, est stateless, et expose 103 tools plus trois workflows prêts à l'emploi, vérifiés sur docs.plugkit.co le 21 octobre 2026. L'authentification est OAuth 2.1 avec PKCE et sans client secret, avec deux scopes : mcp:read pour les profils, les comptes, les posts, les conversations et les analytics, mcp:write pour ajouter la publication, la messagerie, les réponses aux commentaires et la connexion de comptes. Les clients sans OAuth envoient une clé API en bearer token, qui a un accès complet et aucun scope.

L'ajouter à Claude Code tient en une ligne :

claude mcp add -t http plugkit https://api.plugkit.co/mcp

C'est $49 par mois pour 5 comptes connectés ou $97 pour 30, résiliable à tout moment, après 7 jours gratuits sans carte, avec un compte connecté pendant l'essai. Une réserve honnête tirée de la même doc : le serveur demande au modèle d'obtenir ton accord avant une écriture publique, et c'est une instruction au niveau du prompt, pas un contrôle imposé. Si ça compte pour toi, accorde mcp:read et garde les écritures derrière ton propre code.

PlugKit est la mauvaise réponse quand les outils que tu veux ne sont pas des comptes sociaux, quand tes règles de conformité disent que les tokens restent dans ton VPC, ou quand tu veux une publication déterministe sans modèle dans la boucle. Le dernier cas est un appel REST, pas un serveur MCP, et le compromis est posé dans MCP ou API REST pour ton agent. Pour les mécaniques d'authentification en détail, lis OAuth pour serveur MCP. Pour voir à quoi ressemble un serveur hébergé mono-plateforme en pratique, le serveur MCP Instagram, et pour savoir qui d'autre en propose un, le comparatif des serveurs MCP pour les réseaux sociaux.

FAQ

Est-ce que j'ai vraiment besoin d'héberger un serveur MCP ?

Pas s'il tourne sur ta propre machine pour ton propre usage. Un serveur stdio lancé par ton client n'a besoin d'aucun hébergement et d'aucun OAuth, et il lit ses credentials dans l'environnement. L'hébergement devient nécessaire dès qu'une deuxième personne, un téléphone ou un agent dans le cloud doit joindre les mêmes outils.

Est-ce qu'un serveur MCP peut être stateless ?

Depuis la révision 2026-07-28, oui. Cette révision a supprimé les sessions du protocole et le flux GET, donc chaque POST porte ses propres métadonnées et n'importe quelle instance peut y répondre. Les serveurs qui gardent les révisions 2025 conservent un état de session et ont besoin de routage collant.

Qu'est-ce qu'un serveur MCP hébergé fait vraiment que je devrais construire sinon ?

Le resource server OAuth 2.1 avec Protected Resource Metadata et validation d'audience, la boucle de refresh pour chaque token de plateforme, le journal d'audit par appel, le flow de step-up quand un scope manque, et la disponibilité. Le premier est un sprint ; le reste ne finit jamais.

Est-ce que le serverless convient à MCP ?

Pour un serveur en lecture seule sans credentials stockés, oui. Dès que tu as besoin d'OAuth, de tokens rafraîchissables ou d'un flux subscriptions/listen ouvert, tu as besoin d'un état durable et de connexions longues, et tu finis par reconstruire un serveur avec des étapes en plus.

Comment je pointe un client vers un serveur MCP distant ?

Donne-lui l'URL de l'endpoint. Dans Claude Code, claude mcp add -t http <name> <url>. Dans les apps Claude, Customize puis Connectors puis un connecteur personnalisé. Dans Cursor ou VS Code, un lien d'installation en un clic ou trois lignes de JSON. Le client découvre le serveur d'autorisation à partir du 401 que l'endpoint renvoie.

AB

Antoine BlancoFondateur de PlugKit. Gère ses propres comptes Instagram, YouTube et X via l'API et le serveur MCP décrits ici.