MCP
Exécuter un serveur MCP en production : authentification, délais limites, journaux et versions
Un serveur MCP hébergé exige la même rigueur qu’une API : authentification, validation des entrées, délais limites, secrets, contrôles de santé, journaux et historique des déploiements.
Dès qu’un serveur MCP peut agir pour le compte d’un utilisateur ou d’un produit, il doit être exploité comme un backend de production.
Les démonstrations locales cachent les difficultés
Un serveur MCP local peut prouver que la structure d’un outil fonctionne. Il ne prouve pas que ce serveur doit recevoir des identifiants de production, accepter du trafic client distant ou agir sur les ressources partagées d’une équipe.
Au-delà d’une démonstration personnelle, le serveur a besoin d’une URL stable, d’une authentification aux permissions limitées, de journaux clairs, d’une exécution bornée et d’un moyen de revenir sur les changements défectueux.
Traiter les outils comme des endpoints API
Chaque outil MCP doit valider les entrées, vérifier les autorisations, imposer des délais aux appels aval et renvoyer des erreurs prévisibles. Un outil qui crée de l’infrastructure, lit des journaux ou touche aux données clients exige des limites plus strictes qu’un utilitaire local.
Les secrets méritent la même attention. Stockez les jetons des prestataires et les URL de bases de données hors du code source, ne transmettez que les valeurs nécessaires au serveur et évitez de réafficher des identifiants dans les résultats d’outils ou les journaux.
- —Validez chaque entrée d’outil avant d’appeler un prestataire.
- —Utilisez des identifiants aux permissions limitées plutôt que des jetons d’administration étendus.
- —Imposez des délais limites aux services externes et aux tâches longues.
- —Renvoyez des erreurs utiles sans révéler de valeurs privées.
Déployer avec un véritable parcours de mise en production
Un serveur MCP en production doit être compilé depuis le code source, exposer une route de contrôle de santé, être publié en HTTPS et associer ses journaux à la version qui les a produits. Les développeurs peuvent ainsi identifier le code qui a traité un appel d’outil.
Adios peut héberger un serveur MCP personnalisé comme application classique. La page MCP Adios couvre un autre usage : piloter la plateforme Adios elle-même depuis un client compatible MCP.
Tester les limites de confiance
Avant d’exposer Streamable HTTP, rejetez un Origin inattendu, un jeton manquant ou invalide, une entrée trop volumineuse et une requête vers un service aval dépassant son délai limite. Confirmez que le client reçoit une erreur dans un délai limité, tandis que le journal serveur conserve l’identifiant de requête et exclut les identifiants d’accès et les résultats d’outils pouvant contenir des données privées.
Répétez un appel d’outil valide après les échecs et vérifiez que le serveur reste opérationnel. Ce test distingue un transport de production d’un gestionnaire qui ne fonctionne que sur une machine locale de confiance.