Un agent qui répond bien mais ne peut rien vérifier reste un chatbot. Ce qui change tout, c'est sa capacité à appeler vos systèmes : une facture, un stock, un statut de commande. Brancher chaque outil à la main devient vite ingérable. C'est là que MCP entre en jeu : un standard ouvert qui décrit comment un agent découvre et appelle des outils, sans que vous réécriviez votre système d'information.
MCP en une phrase
MCP signifie Model Context Protocol. C'est un protocole ouvert, apparu fin 2024, qui définit un échange en JSON-RPC entre un client — l'agent — et un serveur qui expose des capacités. Trois primitives suffisent à comprendre : les tools, des actions que l'agent peut appeler ; les resources, des données qu'il peut lire ; les prompts, des gabarits réutilisables. Le transport est local (stdio) pour le développement ou distant (HTTP) pour la production. On peut le voir comme une prise standardisée : chaque outil se branche une fois, et tous les agents compatibles peuvent l'utiliser.
MCP, API REST, fonction sur mesure : quoi choisir
- Une API REST déjà en place : l'exposer via un serveur MCP évite de la modifier et la rend découvrable.
- Une logique très proche de la plateforme : une fonction interne peut suffire, mais elle reste liée à un seul agent.
- Un outil réutilisable par plusieurs équipes : MCP est le bon niveau, car le contrat est explicite et le branchement standard.
- Un simple document à lire : la base de connaissance (RAG) est plus adaptée qu'un outil.
La règle pratique : les faits et les actions passent par des outils, le savoir passe par le RAG. On ne demande pas à un document le solde d'un compte, et on ne code pas une règle tarifaire dans une API.
Ce que MCP change vraiment
- La découverte : l'agent liste les outils disponibles au lieu de dépendre d'un câblage figé.
- Le contrat : chaque outil déclare son nom, sa description et le schéma de ses entrées, ce qui permet de valider les appels.
- Le branchement sans redéploiement : ajouter un outil ne demande pas de reconstruire l'agent.
- La réutilisation : le même serveur sert à plusieurs agents, plusieurs équipes, plusieurs environnements.
- La gouvernance : permissions, secrets et journaux se gèrent au niveau de l'outil, pas dans le prompt.
Anatomie d'un serveur MCP utile
Un bon serveur expose peu d'outils, mais des outils clairs : « get_invoice », « list_payments », « check_stock », « create_ticket ». Chaque outil a une description précise, car c'est elle que le modèle lit pour choisir. Il déclare aussi un schéma d'entrée strict : identifiant client, numéro de commande, période. Séparez les outils de lecture des outils d'écriture : un agent de support n'a pas besoin de supprimer un client. Enfin, versionnez le serveur : un changement de contrat sans prévenir casse les parcours en silence.
Sécurité : les six règles à poser
- Moindre privilège : lecture seule par défaut, écriture seulement pour les outils qui en ont besoin.
- Secrets côté serveur : jamais de clé API dans un prompt ou dans une conversation.
- Validation des entrées : bornes de montant, identifiants vérifiés, champs obligatoires.
- Réseau verrouillé : en production, les adresses privées et les métadonnées cloud doivent rester bloquées pour éviter les détournements de type SSRF.
- Journalisation : qui a appelé quoi, quand, avec quel résultat, pour pouvoir expliquer chaque décision.
- Idempotence : une action qui débite ou crédite doit pouvoir être rejouée sans doubler l'effet.
Trois questions avant de brancher un outil
L'outil est-il en lecture ou en écriture ? Un outil qui modifie une donnée mérite un garde-fou, un seuil et une trace. Qui peut l'appeler ? Un outil de facturation n'a pas sa place dans l'agent qui répond aux questions de livraison. Que se passe-t-il s'il échoue ? Un délai d'attente, une reprise et un message honnête valent mieux qu'un agent qui tourne en boucle. Répondez à ces trois questions avant d'écrire une ligne de code : elles évitent la majorité des incidents.
Brancher un serveur MCP dans Deep Agent Studio
Le parcours est volontairement court : ouvrez Outils puis MCP, ajoutez un serveur distant par son URL ou un serveur local, testez la connexion, vérifiez la liste des outils exposés, renseignez les secrets, puis activez seulement les outils utiles pour l'agent concerné. Jouez ensuite les scénarios dans le simulateur avant de publier. Les appels restent visibles dans les traces : vous savez quel outil a été sollicité et ce qu'il a renvoyé.
Trois cas d'usage concrets
La facturation : « get_invoice » renvoie le montant, la date et les prélèvements ; « create_refund » déclenche le remboursement dans le cadre autorisé. L'agent vérifie l'identité par SMS avant d'appeler l'outil d'écriture.
Le commerce : « check_stock » répond sur la disponibilité, « create_order » enregistre une commande. Deux outils séparés, deux niveaux de permission.
Le CRM : « get_customer » donne le statut du compte, « create_ticket » ouvre un dossier pour le conseiller. Le transfert humain repart avec toutes les informations déjà rassemblées.
Les erreurs fréquentes
Une description vague fait choisir le mauvais outil. Un outil fourre-tout avec vingt paramètres rend le comportement imprévisible. Exposer une écriture sans garde-fou transforme une erreur de compréhension en incident réel. Partager une clé administrateur entre tous les agents empêche de savoir qui a fait quoi. Oublier les délais d'attente et les reprises bloque une conversation sur un service lent. Enfin, ne tester que le cas nominal laisse passer les erreurs, les réponses vides et les timeouts.
FAQ
Faut-il coder un serveur MCP ? Seulement si vos outils n'existent pas encore. Une API existante peut être exposée par un serveur, souvent sans la modifier.
MCP remplace-t-il les API ? Non. Il les expose proprement à des agents, avec un contrat et des permissions.
Local ou distant ? Local pour prototyper et pendant le développement, distant pour la production et le partage entre équipes.
Comment savoir quel outil a été appelé ? Les traces du simulateur et le journal des appels donnent l'outil, les paramètres et le résultat.
