Résultat du projet de synthèse

Une intégration MCP prête pour la production n’est pas simplement un agent capable d’appeler un outil. C’est une application qui connecte un agent d’IA à des outils ou à des données approuvés, fait transiter chaque demande par un client MCP et fournit aux utilisateurs un compte rendu fiable de ce qui s’est passé. Dans ce projet de synthèse, vous concevrez et évaluerez l’ensemble de ce parcours à l’aide de demandes réalistes, y compris des demandes ambiguës, dangereuses ou impossibles à traiter.

Gardez les rôles distincts. L’hôte est l’application qui gère l’expérience de l’agent et ses clients MCP. Un client MCP maintient une connexion avec un serveur MCP. Le serveur expose des fonctionnalités telles que des outils ou des ressources. Le modèle peut contribuer à sélectionner une action, mais l’hôte reste responsable des décisions de politique, de l’interaction avec l’utilisateur et de la restitution des résultats. Ne considérez pas une instruction du modèle ou une description d’outil comme une frontière d’autorisation.

Définir la demande et les limites

Commencez par un workflow concret, comme le triage d’un ticket d’assistance. Notez ce que l’utilisateur peut demander, les données auxquelles l’application peut accéder et les actions susceptibles de modifier un état externe. Un ensemble initial de fonctionnalités utile comprend la recherche en lecture seule d’un ticket et une action qui modifie l’état, comme l’ajout d’une note interne. Précisez les entrées autorisées, le résultat attendu et les exigences d’autorisation pour chaque action avant de connecter l’agent.

Séparez la collecte d’informations des décisions qui ont des conséquences. L’application peut récupérer un ticket et rédiger une note suggérée sans rien modifier. Elle ne doit pas ajouter la note ni modifier le statut du ticket tant que l’utilisateur n’a pas confirmé l’action et la cible exactes. Si la demande n’identifie pas de ticket, ou si les informations récupérées laissent subsister une incertitude importante, posez une question de clarification au lieu de deviner. Utilisez des données de bac à sable pour le développement et l’évaluation ; n’utilisez pas de véritables dossiers clients pour rendre une démonstration plus réaliste.

Construire le parcours MCP

Connectez-vous au serveur à l’aide d’un client MCP pris en charge par le SDK et le transport que vous avez choisis. Pour un serveur local, l’entrée et la sortie standard peuvent être appropriées ; pour un serveur distant, utilisez un transport HTTP pris en charge et configurez sa sécurité de manière délibérée. Traitez le transport, le SDK et la version du serveur comme des dépendances explicites du projet. Enregistrez l’identité et les fonctionnalités attendues du serveur au démarrage, et échouez de manière explicite si un outil requis est absent ou si son schéma d’entrée annoncé est incompatible avec votre application.

Utilisez la découverte et l’invocation MCP comme des opérations de protocole, et non comme des noms inventés pour le modèle. Le client peut découvrir les outils disponibles via tools/list et invoquer un outil sélectionné via tools/call. Les serveurs peuvent également exposer des ressources, que les clients peuvent découvrir et lire via les opérations de ressources correspondantes. Ne demandez que les capacités nécessaires à ce workflow. Avant d’invoquer un outil, l’hôte doit vérifier sa propre politique, valider les arguments par rapport aux attentes de l’application et obtenir une confirmation lorsque cela est requis. Après l’invocation, validez le résultat avant de le transmettre à l’agent ou de le présenter comme un fait.

Appliquer les règles de sécurité et de fiabilité

Les schémas et descriptions des outils aident un agent à comprendre une capacité, mais ne prouvent pas qu’un appel est sûr. Les annotations telles que les indications de lecture seule ou d’opération destructive constituent des métadonnées utiles, et non des substituts à la politique de l’application. Contrôlez les accès à l’aide des autorisations du serveur et de vos propres vérifications d’autorisation côté hôte. N’accordez au serveur que les identifiants nécessaires aux opérations et aux enregistrements dont il a besoin, stockez les secrets en dehors des prompts et du contrôle de version, et utilisez les mécanismes d’autorisation distants adaptés au transport sélectionné.

Traitez à la fois les arguments générés par le modèle et le contenu renvoyé par le serveur comme des entrées non fiables. Validez les identifiants, les valeurs d’état autorisées, la longueur du texte et toutes les autorisations pertinentes de l’utilisateur. La sortie d’un outil peut contenir des données incorrectes ou des instructions destinées à manipuler l’agent ; elle ne peut pas outrepasser la politique de l’hôte. Définissez des délais d’expiration et prévoyez une voie d’échec claire. Ne réessayez que les opérations dont la répétition est connue pour être sûre, car réessayer une requête qui modifie l’état après un délai d’expiration incertain peut créer des effets en double. Lorsque cela est pris en charge, gérez l’annulation et arrêtez proprement les connexions du client et du serveur.

Évaluer de bout en bout

Testez l’intégralité du workflow utilisateur, et pas seulement l’ouverture de la connexion MCP. Incluez une recherche simple, une demande nécessitant des précisions, une demande de modification, le cas d’un utilisateur qui refuse la confirmation, ainsi que le cas d’un serveur qui expire ou renvoie une erreur. Ajoutez un cas dans lequel la sortie de l’outil contient une instruction contraire à la politique de l’application. Pour chaque cas, précisez la réponse attendue visible par l’utilisateur et indiquez si un appel d’outil est autorisé.

Mesurez le comportement observable. Enregistrez si l’outil prévu a été sélectionné, si les arguments ont passé la validation, si une approbation requise a bien eu lieu et si la réponse finale correspond au résultat réel de l’outil. Un test ne réussit que si l’application refuse les appels non sûrs et décrit précisément les échecs. Examinez les journaux et les traces pour vérifier qu’ils contiennent suffisamment de détails permettant de diagnostiquer une requête échouée, tout en masquant les identifiants et en limitant les données utilisateur sensibles. Indiquez la couverture des tests et les limites connues au lieu d’affirmer qu’une petite suite de tests prouve la sécurité générale.

Mettre en production et réviser

Avant la mise en production, verrouillez les dépendances, documentez la configuration du serveur MCP et du transport, et assurez-vous que l’application refuse par défaut toute opération lorsque la configuration ou les capacités requises sont indisponibles. Examinez les contrôles d’accès, la gestion des identifiants, l’exposition réseau, les délais d’expiration et la conservation des journaux. Séparez les configurations des serveurs de développement, de test et de production. Toute modification du schéma d’un outil ou de l’implémentation d’un serveur doit déclencher des tests de compatibilité et de sécurité avant le déploiement.

Le livrable final est une application reproductible, et non une capture d’écran réussie. Incluez les étapes de configuration, les limites de confiance, les actions nécessitant une approbation et les résultats des tests. Un évaluateur doit pouvoir exécuter l’application avec des données de sandbox, reproduire une recherche réussie ainsi qu’une action rejetée ou échouée, et vérifier que le message final ne prétend jamais qu’une modification a eu lieu tant que le serveur ne l’a pas confirmée. Ces normes rendent l’intégration compréhensible, testable et plus sûre à exploiter.