Choisissez le transport avec discernement
Un serveur stdio local et un service HTTP distant ont des besoins de déploiement différents. Utilisez un transport distant pris en charge, TLS et une route authentifiée. Vérifiez les versions du client et du serveur plutôt que de supposer que chaque implémentation prend en charge les mêmes capacités.
Traitez chaque outil comme un API
Validez les arguments, appliquez une autorisation propre à l'utilisateur et limitez les ressources. N'exposez pas l'exécution shell arbitraire comme outil de commodité. Restreignez les destinations sortantes lorsqu'un outil récupère des URL et gardez les secrets hors des descriptions et des réponses.
Garder la collecte d'identité proportionnée
Un hébergeur sans KYC peut minimiser les données d'inscription chez le fournisseur, mais le service MCP peut encore nécessiter ses propres utilisateurs, une sécurité de session et des contrôles d'abus. Expliquez ce qu'il journalise et évitez de conserver les entrées d'outils sans finalité définie.
Déployez pour plus de clarté opérationnelle
Exécutez sous un utilisateur dédié, utilisez des contrôles de santé, limitez les temps de requête et gardez la mise en tampon et les délais d'expiration du proxy inverse compatibles avec le protocole. Testez l'authentification, la révocation, les déconnexions et les nouvelles tentatives avant d'accorder des privilèges d'écriture.
Alignez l'authentification sur le protocole pris en charge
Pour un déploiement MCP basé sur HTTP, examinez les exigences d'autorisation actuelles du protocole et la version prise en charge par le client. L'accès aux ressources via OAuth implique l'audience du jeton, la découverte et la portée, et pas simplement un mot de passe sur la page d'accueil. Utilisez HTTPS, validez les jetons pour la ressource visée et gardez les identifiants porteurs hors des chaînes de requête. Un serveur stdio utilise une frontière d'identification locale différente.
- Tester une requête non authentifiée
- Testez une requête authentifiée hors de son périmètre
- Révoquez un identifiant et vérifiez qu’il cesse de fonctionner
Documentation officielle : Spécification d'autorisation MCP
Publiez un premier ensemble d'outils limité
Commencez par des outils en lecture seule qui renvoient une quantité de données limitée. N'ajoutez l'écriture de fichiers, les opérations de cycle de vie du serveur ou les messages externes qu'une fois leurs permissions et leur comportement en cas de doublon compris. Considérez les pages web et documents renvoyés comme des entrées non fiables ; ils ne doivent pas étendre silencieusement l'autorité du serveur d'outils.
Figez le comportement du protocole avant d'écrire des règles de proxy
Consignez à la fois la version SDK du serveur et la révision MCP que le client utilisera. Dans la révision 2026-07-28 Streamable HTTP, les requêtes utilisent un point de terminaison POST ; les exemples plus anciens reposant sur des sessions de protocole ou un flux GET autonome correspondent à une autre révision. Ne supprimez pas une exigence de compatibilité apparente avant de savoir quel client vous prenez en charge. Un proxy inverse doit préserver les en-têtes requis, le statut HTTP et le comportement de diffusion en continu des réponses pour cette version.
- Commencez par un outil en lecture seule sur un écouteur loopback, puis placez la frontière HTTPS/authentification prévue devant celui-ci.
- Testez un résultat normal, un résultat en streaming, un délai d'expiration et un client déconnecté via le proxy public.
- Validez les valeurs Origin autorisées comme l'exige le transport ; une vérification Origin ne remplace pas l'authentification de l'appelant.
- Si les événements n'arrivent qu'à la fin, inspectez le buffering et le comportement des délais d'expiration du proxy avant de modifier le code de l'outil.
Documentation officielle : MCP 2026-07-28 : HTTP diffusable en flux
Testez les échecs d'autorisation aussi délibérément que les succès
Pour l'accès HTTP protégé par OAuth, le serveur MCP est une ressource protégée. Testez la découverte des métadonnées, l'émetteur attendu et l'audience du jeton, ainsi que les portées nécessaires à une opération donnée. Gardez le jeton d'autorisation hors des chaînes de requête URL et ne le transmettez jamais tel quel à un service en aval non lié. Un échec d'authentification côté client doit préserver le défi HTTP approprié afin que le client puisse se rétablir via son flux pris en charge.
- Aucun jeton ou jeton expiré : le point de terminaison protégé refuse l'accès plutôt que de renvoyer des données d'outil privées.
- Jeton valide avec des permissions insuffisantes : la ressource demandée reste inaccessible.
- Jeton destiné à un autre public : rejetez-le même si sa signature est par ailleurs valide.
- URL externe ou chemin de fichier inattendu : validez auprès de l’autorité de l’outil avant toute lecture ou écriture.
- Journaux et traces d'erreurs : conservez un identifiant d'opération et le résultat tout en supprimant les jetons et les entrées d'outils privées.
Documentation officielle : MCP 2026-07-28 : autorisation HTTP · MCP : bonnes pratiques de sécurité