Construire un agent IA avec n8n et MCP
MCP, en clair
MCP, pour Model Context Protocol, est un protocole standard qui décrit comment un agent IA découvre des outils, les appelle, et reçoit leurs résultats. L'idée est simple : au lieu de coder une intégration spécifique entre chaque agent et chaque service, on expose les outils derrière une interface commune que tout client compatible MCP sait lire.
Pour bien situer MCP, il faut d'abord comprendre ce qu'est un outil pour un agent. Si la notion d'agent IA et de tools ne vous est pas familière, commencez par notre définition d'un agent IA, puis par le guide de base créer un agent IA avec n8n qui couvre le noeud AI Agent, les tools et la mémoire. Le présent guide suppose ces fondations acquises et se concentre uniquement sur MCP.
Pourquoi MCP est utile ? Trois raisons concrètes :
- Réutilisation : un même serveur MCP peut servir plusieurs agents, plusieurs projets, voire des clients différents (n8n, un assistant de bureau, un IDE).
- Standardisation : l'agent n'a pas besoin de connaître les détails d'implémentation de chaque outil, seulement le contrat MCP.
- Découplage : les outils évoluent côté serveur sans casser l'agent côté client, tant que le contrat tient.
MCP ne remplace pas les tools natifs de n8n. C'est une voie supplémentaire pour donner ou exposer des outils, particulièrement pertinente quand le même outillage doit être partagé.
Les deux rôles de n8n avec MCP
n8n peut jouer deux rôles distincts vis-à-vis de MCP. Bien les distinguer évite la confusion la plus fréquente.
n8n comme client : MCP Client Tool
Le sub-node MCP Client Tool se branche sur un noeud AI Agent comme n'importe quel autre tool. Il pointe vers un serveur MCP externe et met les outils de ce serveur à disposition de votre agent. Votre agent n8n devient ainsi consommateur d'outils définis ailleurs. L'authentification se fait par Bearer token, header personnalisé ou OAuth2 selon ce qu'attend le serveur.
n8n comme serveur : MCP Server Trigger
Le noeud MCP Server Trigger fait l'inverse : il transforme vos workflows n8n en outils exposés via une URL. n8n devient alors un serveur MCP que d'autres agents ou clients compatibles MCP peuvent appeler. Les transports supportés sont SSE et streamable HTTP (pas de stdio). C'est utile pour publier des capacités métier (interroger une base, lancer une action) sous forme d'outils standardisés.
| Rôle | Noeud | n8n est | Usage type |
|---|---|---|---|
| Client | MCP Client Tool (sub-node) | Consommateur | Donner des outils externes à votre agent n8n |
| Serveur | MCP Server Trigger | Fournisseur | Exposer vos workflows comme outils à d'autres agents |
Les deux peuvent coexister : un workflow n8n peut consommer un serveur MCP externe tout en exposant ses propres outils à d'autres clients.
Donner des outils MCP à votre agent n8n, étape par étape
Voici la marche à suivre côté client, c'est-à-dire pour brancher un serveur MCP externe sur un agent n8n existant. Elle suppose que vous avez déjà un agent fonctionnel (Chat Model, au moins un tool, mémoire optionnelle).
- Partez d'un agent n8n fonctionnel. Vérifiez que votre noeud AI Agent répond déjà correctement sur des cas simples, avec son Chat Model configuré. C'est la base décrite dans le guide de base.
- Ajoutez le sub-node MCP Client Tool. Connectez-le à l'entrée tool de votre noeud AI Agent, comme vous le feriez pour n'importe quel autre outil.
- Renseignez l'URL du serveur MCP et l'authentification. Indiquez l'endpoint du serveur externe et choisissez le mode d'auth attendu : Bearer token, header personnalisé ou OAuth2.
- Sélectionnez et limitez les outils exposés. Ne donnez à l'agent que les outils dont il a réellement besoin. Restreindre le périmètre réduit les erreurs et la surface de risque.
- Testez sur des cas réels. Faites tourner l'agent sur des requêtes représentatives et vérifiez qu'il appelle les bons outils MCP avec les bons paramètres.
- Posez les points de contrôle avant les actions à conséquence. Pour tout outil qui écrit, supprime ou déclenche une dépense, intercalez une validation humaine ou une condition explicite avant exécution.
La mémoire de l'agent ne persiste pas entre les sessions : si votre cas d'usage exige de retrouver un contexte d'une exécution à l'autre, prévoyez un stockage externe, indépendant de MCP.
Exposer vos workflows n8n via MCP
Côté serveur, le principe est de publier un ou plusieurs workflows comme outils consommables par des agents tiers. Le noeud MCP Server Trigger sert de point d'entrée.
Quelques points pratiques :
- Transports : MCP Server Trigger expose les outils en SSE et en streamable HTTP. Il n'y a pas de transport stdio côté n8n, ce qui signifie que la communication passe par une URL réseau accessible au client.
- Définition des outils : chaque workflow exposé devient un outil avec ses paramètres d'entrée. Soignez les noms et descriptions, car c'est ce que l'agent client lira pour décider quand appeler l'outil.
- Authentification : protégez l'URL exposée. Un serveur MCP ouvert sans auth donne à n'importe quel client la capacité de déclencher vos workflows.
Exposer des workflows via MCP est une bonne façon de mutualiser des capacités métier entre plusieurs agents sans dupliquer la logique. Pour replacer cette brique dans une démarche d'automatisation plus large, voir notre page automatisation IA.
Les garde-fous
Brancher des outils sur un agent, qu'ils viennent de MCP ou non, augmente sa capacité d'action et donc sa capacité à se tromper avec des conséquences réelles. Quelques garde-fous robustes :
- Périmètre minimal des outils. N'exposez que les outils nécessaires, côté client comme côté serveur. Moins d'outils disponibles signifie moins de mauvaises décisions possibles.
- Points de contrôle avant action. Pour toute action à conséquence (écriture, suppression, envoi, dépense), insérez une validation explicite, humaine ou conditionnelle, avant exécution. L'agent propose, un contrôle dispose.
- Authentification systématique. Côté client, utilisez Bearer, header ou OAuth2 selon le serveur. Côté serveur, ne jamais exposer une URL MCP Server Trigger sans authentification.
- Traçabilité. Conservez les exécutions et les appels d'outils pour pouvoir auditer ce que l'agent a fait, et reconstituer une décision a posteriori.
- Tests sur cas réels avant mise en production. Un agent qui répond bien sur des exemples jouets peut dériver sur des cas réels. Validez sur des données représentatives.
Ces garde-fous ne sont pas spécifiques à MCP, mais MCP les rend d'autant plus importants qu'il facilite l'ajout d'outils nombreux et hétérogènes. Sur des contextes sensibles (par exemple un workflow opéré pour un acteur sous licence réglementaire), la routine peut être autonome côté agent, mais les actions à conséquence restent confirmées par l'opérateur.