Déployer un serveur MCP pour ChatGPT : guide de la conception à la mise en production

Déployer un serveur MCP pour ChatGPT ne se résume pas à obtenir une réponse sur /mcp. ChatGPT doit pouvoir l’atteindre, découvrir les bons outils, authentifier les utilisateurs et les sélectionner à bon escient. Pour la plupart des équipes, l’hébergement géré reste le choix le plus raisonnable ; l’infrastructure privée doit plutôt passer par Secure MCP Tunnel.

Définissez le périmètre de déploiement avant d’écrire du code

Le périmètre de déploiement détermine le transport utilisé, le travail nécessaire côté authentification, la charge opérationnelle et la possibilité de publier le serveur. ChatGPT est un client MCP distant : contrairement à certains clients de bureau, il ne lance pas directement un processus local en stdio (Centre d’aide OpenAI).

Privilégiez l’hébergement géré si le serveur MCP est sans état, que le trafic est intermittent et que l’équipe n’exploite pas déjà une plateforme applicative publique fiable. Le modèle de route handler de Vercel comme celui du Worker sans état de Cloudflare fournissent tous deux le point de terminaison HTTPS stable attendu par ChatGPT ; vérifiez toutefois les contraintes propres à chaque plateforme en matière de durée des requêtes, de streaming et d’état avant de trancher (Vercel, Cloudflare).

Autogérez le point de terminaison public lorsque le serveur doit rester au plus près de bases de données existantes, s’intégrer à votre infrastructure d’identité, respecter des règles de résidence des données ou exécuter des traitements incompatibles avec le modèle de durée du serverless. Ce choix n’est pertinent que si l’équipe dispose déjà d’une gestion des secrets, d’un mécanisme de retour arrière, d’alertes et d’un responsable d’astreinte.

Choisissez Secure MCP Tunnel lorsque l’exposition publique n’est pas la bonne frontière de sécurité. Le client tunnel d’OpenAI établit des connexions HTTPS sortantes vers api.openai.com:443 et relaie les requêtes vers un serveur privé en HTTP ou stdio ; aucun écouteur Internet entrant n’est nécessaire. La documentation de déploiement d’OpenAI précise également que Secure MCP Tunnel ne satisfait pas à l’exigence de publication publique d’un point de terminaison HTTPS stable et accessible publiquement (documentation OpenAI sur les tunnels, guide de création OpenAI).

Passez des outils locaux à un serveur MCP ChatGPT prêt pour la production

Un déploiement fiable de serveur MCP pour ChatGPT repose sur plusieurs étapes distinctes : comportement des outils, conformité au protocole, accessibilité en production et routage par le modèle. Réussir l’une ne garantit pas la réussite de la suivante.

1. Définissez des outils ciblés et des contrats stables

Commencez par créer un outil pour chaque action utilisateur identifiable. Le guide de création d’OpenAI recommande par exemple des outils distincts comme list_projects, get_project et update_project, plutôt qu’un outil unique regroupant des modes sans rapport (documentation développeur OpenAI). Chaque outil doit avoir un nom orienté action, une description précise, un schéma d’entrée explicite, une sortie exploitable et des annotations de sécurité exactes.

Ne définissez readOnlyHint: true que si l’outil ne peut absolument pas modifier l’état. Utilisez destructiveHint: true pour les effets irréversibles ou difficiles à annuler, et openWorldHint: true lorsqu’un outil accède à des entités externes sans périmètre prédéfini. OpenAI décrit ces annotations comme des métadonnées destinées au modèle, utilisées pour le comportement des outils et la gestion de la sécurité, tout en exigeant que l’autorisation soit contrôlée par le serveur à chaque requête protégée (documentation développeur OpenAI).

Renvoyez les identifiants stables des enregistrements dans structuredContent lorsqu’un appel ultérieur peut devoir modifier le même enregistrement. Ne placez ni jetons, ni secrets, ni données personnelles superflues dans content, structuredContent ou _meta ; OpenAI précise explicitement que _meta est masqué au modèle, mais ne constitue pas un espace de stockage sécurisé.

2. Exposez Streamable HTTP en local

La connexion distante standard de ChatGPT utilise Streamable HTTP, généralement sur /mcp. Ce chemin est conventionnel, pas obligatoire, mais l’URL complète du serveur déployé doit être saisie dans ChatGPT (guide de connexion OpenAI).

Lancez le serveur en local, puis ouvrez MCP Inspector :

npx @modelcontextprotocol/inspector@latest

Connectez Inspector à une URL telle que http://localhost:3000/mcp. Vérifiez l’initialisation, listez les outils, puis appelez chacun d’eux avec une requête valide, un schéma invalide, un identifiant manquant et un cas sans résultat. Pour les outils protégés, vérifiez que des identifiants absents ou insuffisants provoquent bien un refus.

3. Ajoutez les contrôles d’accès avant toute exposition

Un contrôle de santé public ne justifie pas l’exposition publique de vos outils. Si ces derniers ne donnent accès qu’à des données volontairement publiques et en lecture seule, un point de terminaison sans authentification peut être acceptable. Les données privées, les données propres à un utilisateur et les actions exigent une authentification et une autorisation à chaque requête (guide de création OpenAI).

Avec OAuth pour un MCP protégé, le serveur joue le rôle de resource server. Une requête non authentifiée renvoie 401 et indique au client où trouver les métadonnées de la ressource protégée, généralement sur /.well-known/oauth-protected-resource. Le flux d’autorisation doit utiliser PKCE, des jetons aux portées strictement limitées, une validation rigoureuse de l’émetteur et de l’audience, ainsi que la prise en charge des refresh tokens lorsque des connexions persistantes l’exigent (Centre d’aide OpenAI).

Ne transmettez pas le jeton d’accès MCP à un service en aval sous prétexte que les deux services acceptent les bearer tokens. Le jeton doit être destiné à la ressource qui le reçoit ; utilisez des identifiants de service ou une architecture appropriée d’échange de jetons pour les appels en aval (guide de sécurité pour le déploiement MCP).

4. Déployez un artefact immuable

Déployez sur un environnement de prévisualisation ou de staging exactement le build validé avec Inspector, puis promouvez cet artefact en production. Le point de terminaison de production doit utiliser HTTPS, conserver le chemin MCP complet, accéder à ses dépendances et stocker les secrets dans le gestionnaire de secrets de la plateforme d’hébergement.

Pour suivre le parcours de référence compact de Vercel, installez mcp-handler, @modelcontextprotocol/server et zod ; montez le Web handler renvoyé dans app/api/mcp/route.ts ; exportez-le pour GET et POST ; puis déployez avec :

npx vercel deploy --prod

L’URL de connexion ChatGPT prend alors la forme https://your-project.vercel.app/api/mcp. Vercel documente une durée de fonction par défaut de 300 secondes avec Fluid compute, ainsi que des plafonds plus élevés dans certaines configurations payantes éligibles. Déportez donc les traitements qui dépassent la durée d’une requête vers un job reprenable, plutôt que de maintenir un flux inactif ouvert (guide de déploiement Vercel). Gardez la route sans état, sauf si le runtime choisi fournit une véritable architecture d’état partagé.

Ajoutez ces quatre contrôles opérationnels avant de connecter ChatGPT :

1. Définissez des délais d’expiration et des limites de débit pour les outils coûteux.
2. Consignez les échecs d’initialisation et d’appel d’outil sans enregistrer les jetons ni les résultats sensibles.
3. Associez un identifiant de version à chaque invocation afin de relier rapidement un incident au code déployé.
4. Conservez une procédure de retour arrière testée pour les régressions de schéma d’outil ou d’autorisation.

Exécutez MCP Inspector sur l’URL de production, pas uniquement sur localhost. Revérifiez la découverte, les schémas, les annotations, l’authentification, les appels valides et les erreurs. Un répartiteur de charge, un proxy, une règle CORS ou une redirection du fournisseur d’identité peut échouer alors que l’application fonctionnait en local.

Concevez le contrôle d’accès sur trois niveaux

L’accès MCP de ChatGPT repose sur trois niveaux de contrôle indépendants ; activer OAuth ne traite que le niveau de l’identité.

Dans ChatGPT Business, les administrateurs ou propriétaires contrôlent le mode développeur et la publication. Les espaces Enterprise et Edu ajoutent un RBAC pour l’accès développeur, l’accès aux applications et les actions (Centre d’aide OpenAI). Ces contrôles encadrent l’utilisation de l’application dans ChatGPT ; ils ne prouvent pas qu’un appelant peut modifier l’enregistrement du client A dans le backend.

Le gestionnaire MCP doit déduire l’identité à partir d’identifiants validés et appliquer l’autorisation du tenant et de l’objet à chaque appel. N’acceptez jamais un identifiant utilisateur, un identifiant d’organisation ou un rôle transmis dans les arguments générés par le modèle comme preuve d’identité. Considérez tous les arguments d’outil comme des entrées non fiables.

Séparez les portées de lecture des portées d’écriture. Une politique concrète peut autoriser largement projects:read, réserver projects:write aux éditeurs et imposer une nouvelle vérification côté serveur avant toute opération destructive. ChatGPT peut demander une confirmation pour les actions importantes, mais cette confirmation relève de l’expérience utilisateur, pas du contrôle d’autorisation.

L’injection de prompt est également un problème de contrôle d’accès. Les sorties des outils et les documents récupérés peuvent contenir des instructions malveillantes ; les outils d’écriture doivent donc exposer l’action la plus limitée possible et valider côté serveur les champs autorisés. Un outil fourre-tout comme execute_action augmente à la fois l’ambiguïté du routage et le rayon d’impact potentiel.

Connectez, testez et publiez l’application dans ChatGPT

La connexion du point de terminaison crée une application brouillon et une copie des métadonnées. La publication rend une configuration vérifiée disponible dans l’espace de travail ; ce n’est pas la même opération que le déploiement du code serveur.

1. Activez le mode développeur conformément à la politique de l’espace de travail ChatGPT concerné.
2. Ouvrez le flux de création d’application et saisissez l’URL MCP HTTPS complète, en incluant /mcp si c’est la route montée.
3. Sélectionnez le mécanisme d’authentification et terminez le flux OAuth si nécessaire.
4. Lancez Scan Tools, examinez chaque nom, schéma, annotation et action découverts, puis créez le brouillon.
5. Testez le brouillon dans une nouvelle conversation avant de le publier dans l’espace de travail.

Pour un serveur privé, choisissez Tunnel comme mode de connexion, puis sélectionnez un tunnel associé ou saisissez son tunnel_id. L’opérateur doit disposer de l’autorisation OpenAI Platform Tunnels Read + Use, tandis que le mode développeur de ChatGPT reste une permission distincte au niveau de l’espace de travail (documentation OpenAI sur les tunnels).

Les changements de métadonnées nécessitent un cycle de mise à jour explicite. Pour une connexion en mode développeur, déployez ou redémarrez le serveur, ouvrez la connexion, sélectionnez Refresh, vérifiez les métadonnées modifiées, puis démarrez une nouvelle conversation. Les consignes actuelles d’OpenAI pour Business indiquent que les applications publiées doivent être recréées et republiées pour modifier les outils ou les métadonnées ; les administrateurs Enterprise/Edu peuvent actualiser les actions, examiner les différences et activer de nouvelles actions, désactivées par défaut (Centre d’aide OpenAI).

Une évolution rétrocompatible reste la politique la plus sûre côté serveur. Ajoutez des champs facultatifs et de nouveaux outils ; évitez de modifier discrètement le sens d’un outil existant. Conservez les anciens schémas jusqu’à ce que tous les instantanés approuvés et tous les clients aient migré.

Testez le comportement que les utilisateurs de ChatGPT verront réellement

Les tests de protocole prouvent qu’un serveur sait répondre. Les tests dans ChatGPT vérifient que le modèle sélectionne le bon outil, fournit des arguments adaptés, respecte les limites et évite l’outil lorsqu’il n’est pas pertinent.

L’utilisateur Reddit u/EmailNo8428 a résumé ce problème à deux niveaux :

« Vous testez en réalité deux choses à la fois : la logique de vos outils et la façon dont un client donné les appelle. » (r/mcp)

Constituez un petit jeu d’évaluation versionné couvrant les cas suivants :

Consignez l’outil sélectionné, les arguments, le résultat renvoyé, l’erreur éventuelle et le comportement de confirmation. Rejouez les cas concernés dès qu’un nom d’outil, une description, un schéma, une annotation, une règle d’authentification ou la structure d’un résultat change ; OpenAI recommande le même cycle d’actualisation et de retest dans son guide de connexion.

Un serveur qui passe Inspector mais route mal les requêtes dans ChatGPT a généralement besoin de frontières d’outils, de descriptions ou de schémas plus précis. Un serveur qui route correctement mais renvoie 401, expire ou perd son état souffre plutôt d’un problème d’infrastructure ou d’autorisation. Séparer ces deux diagnostics accélère nettement les corrections.

FAQ

ChatGPT peut-il se connecter directement à un serveur MCP localhost ou stdio ?

Non. ChatGPT se connecte normalement à un point de terminaison MCP distant. OpenAI Secure MCP Tunnel peut relayer les requêtes vers un serveur privé en stdio ou HTTP sans exposition entrante publique, tandis qu’un tunnel HTTPS temporaire peut servir au développement, mais pas à la soumission publique d’un plugin.

Un serveur MCP ChatGPT doit-il disposer d’un point de terminaison HTTPS public ?

Une connexion distante classique et la soumission publique d’un plugin exigent un point de terminaison HTTPS stable. Un serveur privé utilisé en mode développeur peut passer par Secure MCP Tunnel, qui maintient le serveur dans l’environnement contrôlé par le client.

Les outils search et fetch sont-ils obligatoires ?

Non. OpenAI indique que les serveurs connectés n’en ont plus besoin. Implémentez les contrats standards search et fetch lorsque l’application doit participer aux surfaces de recherche dans les connaissances de l’entreprise ou de deep research (Centre d’aide OpenAI).

Pourquoi ChatGPT affiche-t-il encore les anciens outils après le déploiement ?

ChatGPT conserve les métadonnées découvertes au lieu de considérer chaque déploiement du code comme une modification approuvée des outils. Actualisez une connexion en mode développeur et démarrez une nouvelle conversation ; les applications publiées dans un espace de travail suivent le processus de vérification et de republication prévu par le forfait.