MCP et n8n : connecter assistants IA, outils et workflows
Identifiez le bon sens de connexion entre MCP et n8n, réunissez les prérequis et préparez un premier test aux effets maîtrisés.
Quand on cherche « MCP n8n », on peut vouloir trois choses différentes : que n8n utilise des outils hébergés ailleurs, qu'un assistant IA déclenche des automatisations n8n, ou qu'un assistant aide à construire des workflows. Les trois reposent sur le même protocole, mais pas sur les mêmes composants, ni sur les mêmes risques. Cet article aide à nommer votre objectif, à réunir les informations utiles et à cadrer un premier essai dont on peut juger le résultat.
Comment utiliser MCP avec n8n, et quel montage choisir ?
Tout dépend de qui appelle quoi. Pour que n8n appelle un serveur externe : MCP Client en étape de workflow, MCP Client Tool si c'est un agent IA qui choisit l'outil. Pour qu'un assistant déclenche vos automatisations : le serveur d'instance n8n (plusieurs workflows) ou MCP Server Trigger (les outils d'un seul workflow). Pour être aidé à concevoir : le serveur d'instance, selon version et permissions, ou le projet tiers n8n-mcp, distinct du serveur officiel. Commencez par un essai limité, avec des droits réduits, et vérifiez le résultat réel, pas seulement la connexion. Les sources ne garantissent pas une procédure identique selon la version, l'hébergement et le client.
Qui appelle quoi : client, serveur et workflow
Trois rôles se distinguent, quel que soit le montage :
- le client est celui qui appelle un outil ;
- le serveur est celui qui met des outils à disposition ;
- le workflow est l'automatisation n8n qui s'exécute.
Prenons un exemple volontairement fictif : un assistant doit rechercher une commande de démonstration et renvoyer son statut, sans rien modifier. L'assistant est le client, n8n joue le rôle de serveur, et le workflow effectue la recherche. La demande va de l'assistant vers n8n, le résultat fait le chemin inverse. Dans l'autre sens, c'est n8n qui devient client d'un service extérieur.
🚨Attention aux accès accordés:
- Selon les permissions, un assistant connecté peut consulter, créer, modifier et exécuter des workflows : accordez le minimum nécessaire.
- Avec le projet tiers n8n-mcp, la session hérite des privilèges de la clé API configurée, et certains outils peuvent remplacer entièrement un workflow.
- Le projet tiers czlonkowski/n8n-mcp n'est pas le serveur officiel n8n.
- Vérifiez sur votre instance que les outils de création ou de modification nécessaires sont disponibles pour votre version et votre rôle.
Choisir son parcours selon l'objectif
Faire appeler un outil externe par n8n
Selon la documentation du nœud MCP Client, il permet d'utiliser des outils MCP comme des étapes ordinaires d'un workflow. Pour que ces outils soient utilisés par un agent IA, la même page renvoie vers le nœud MCP Client Tool. Choisissez le premier pour un enchaînement prévisible, le second quand c'est l'agent qui décide quel outil appeler.
Rendre n8n accessible à un assistant
Deux options officielles existent, et elles n'ont pas la même portée :
- le serveur MCP d'instance donne une connexion par instance n8n ;
- le MCP Server Trigger n'expose que les outils d'un seul workflow, ceux qui lui sont raccordés.
Le second convient à un périmètre étroit et bien délimité ; le premier à un assistant qui doit pouvoir parcourir plusieurs automatisations.
Se faire aider pour concevoir des workflows
Concevoir n'est pas exécuter, et consulter n'est pas modifier. Le serveur d'instance officiel peut, selon la version et les permissions, consulter, créer, modifier et exécuter. Le projet tiers n8n-mcp propose une autre voie, centrée sur la recherche de nœuds, la documentation et la validation. Rien n'indique que la conception exige ce projet tiers : il s'agit d'une option, pas d'un passage obligé.
| Votre objectif | Composant à examiner | Qui appelle | Portée |
|---|---|---|---|
| Utiliser un service MCP externe dans un enchaînement fixe | MCP Client | n8n | L'outil choisi dans le workflow |
| Laisser un agent n8n choisir ses outils externes | MCP Client Tool | L'agent n8n | Les outils du serveur externe |
| Laisser un assistant utiliser plusieurs automatisations | Serveur d'instance | L'assistant | L'instance, selon droits et disponibilité |
| Exposer un seul workflow | MCP Server Trigger | L'assistant | Les outils raccordés à ce workflow |
| Aide à la conception | Serveur d'instance ou projet tiers | L'assistant | Selon permissions ou clé API |
Lecture : ce tableau est une orientation, ses lignes peuvent se recouper (un assistant peut devoir concevoir puis exécuter). Pour le premier essai, retenez une seule opération, puis départagez les montages selon le périmètre voulu et les opérations nécessaires.
Réunir les prérequis avant de configurer
Avant de configurer, remplissez une fiche d'une page : objectif, sens de l'appel, version de n8n, hébergement, client utilisé, workflow visé, méthode d'authentification, entrée de démonstration, résultat attendu, effets autorisés et interdits. Distinguez deux familles de lignes : objectif, sens de l'appel et résultat attendu suffisent pour choisir le parcours ; version, hébergement, authentification et droits sont indispensables avant de configurer ou d'exécuter.
Ces informations sont un conseil de méthode, pas une exigence de la documentation. Elles évitent surtout qu'on découvre en plein essai que personne ne sait quel résultat était attendu. Pour un dirigeant, le point le plus utile est de désigner qui valide les effets autorisés : c'est une décision métier avant d'être un réglage technique. Si l'hébergement ou les droits sont mal connus, faites appel à la personne qui administre l'instance plutôt que de deviner.
Préparer la connexion qui correspond à votre besoin
De n8n vers un serveur MCP externe
Pour le nœud MCP Client, renseignez le transport, l'adresse du serveur et l'authentification, puis choisissez un outil découvert et ses paramètres. Si vous utilisez MCP Client Tool avec un agent, suivez la configuration propre à ce nœud et à votre version.
D'un assistant vers le serveur d'instance
Sur n8n Cloud comme en auto-hébergement, un propriétaire ou un administrateur active l'accès MCP au niveau de l'instance dans Settings. Le client utilise ensuite l'URL du serveur, qui se termine par /mcp-server/http. L'authentification recommandée est OAuth ; un jeton personnel Bearer est l'alternative.
Deux contrôles comptent avant d'aller plus loin :
- La disponibilité : un workflow doit être marqué Available in MCP pour être exposé. L'option « Auto-expose new workflows » est désactivée par défaut, son déploiement est progressif depuis la version 2.36.0 et elle ne concerne que les créations ultérieures. Distincte de cette option, la création d'un workflow via MCP le positionne à availableInMCP = true : après toute création par un assistant, vérifiez sa disponibilité et les permissions accordées.
- Les droits : chaque client connecté n'a que les permissions accordées, et OAuth peut limiter les opérations autorisées.
👉Activer le MCP expose-t-il tous mes workflows ?
Non. Il faut les rendre disponibles (Available in MCP) et les droits accordés au client s'appliquent. Attention : search_workflows peut afficher des aperçus de workflows accessibles mais non exposés, sans leurs données complètes. Il n'existe pas de sélection de workflows propre à chaque client.
Exposer un workflow avec MCP Server Trigger
On raccorde des nœuds d'outils au déclencheur ; pour exposer un workflow entier, la documentation cite le nœud Custom n8n Workflow Tool. Le déclencheur n'expose pas automatiquement tous les workflows. Il propose une URL de test (après Listen for Test Event ou Execute workflow) et une URL de production (après publication). Le client peut alors lister puis appeler les outils.
Si un reverse proxy est présent, son administrateur doit désactiver le buffering pour l'endpoint ; avec plusieurs réplicas webhook, la documentation demande de router /mcp* vers un seul réplica dédié. Ce sont des points d'infrastructure : confiez-les à la personne qui gère le serveur.
Se faire assister par le projet tiers
Le projet n8n-mcp n'est pas publié par n8n. Sa démarche proposée : rechercher, configurer et valider les nœuds, assembler le JSON, puis valider le workflow avant déploiement.
Avec le projet tiers, séparez deux usages. Les outils documentaires (recherche de nœuds, documentation, validation) fonctionnent sans API n8n. Les outils de gestion exigent N8N_API_URL et N8N_API_KEY, et l'accès à la session confère les privilèges de cette clé. Une validation structurelle ne prouve ni identifiants corrects ni résultat métier.
Ses consignes de sécurité rappellent le même point. Certaines opérations passent en outre par le MCP officiel et demandent des accès supplémentaires, car l'API publique ne peut pas les réaliser.
Tester jusqu'au résultat métier
Séparez quatre constats, car chacun peut réussir sans les suivants :
- la connexion est acceptée ;
- l'outil attendu apparaît dans la liste ;
- l'appel accepte l'entrée et démarre ;
- l'exécution se termine et produit l'effet voulu.
Avec la commande fictive : choisissez une référence de démonstration et notez son statut connu dans la source avant l'appel. Transmettez la référence selon le schéma d'entrée réel de l'outil (il n'existe pas de syntaxe commune à tous). Comparez ensuite la réponse au statut noté, puis vérifiez que le dossier n'a pas été modifié. Chaque étape prouve une chose différente : la liste prouve la découverte, le démarrage prouve seulement l'acceptation, la comparaison prouve le résultat.
Avant de lancer quoi que ce soit, vérifiez les conditions d'exécution (version publiée ou courante, déclencheur admissible) et rappelez-vous qu'un test peut avoir des effets réels. Pour le serveur d'instance officiel, testez ensuite en trois temps : consultez le workflow avec get_workflow_details, lancez-le avec execute_workflow, puis relisez l'issue avec get_workflow_execution et l'executionId reçu. L'appel renvoie l'identifiant sans attendre la fin ; l'état final et l'effet métier se contrôlent séparément.
Selon la référence des outils, le mode production utilise la version publiée, le mode manual la version courante. Production exige un déclencheur Webhook, Chat, Form ou Schedule ; manual accepte aussi le Manual Trigger. Avec des entrées, le nom du déclencheur est requis. Les formulaires multiétapes et les interactions avec validation humaine ne sont pas pris en charge. Pour récupérer les données d'une exécution, utilisez includeData=true.
👉Peut-on tester un workflow par MCP sans risque d'effet réel ?
Non, pas par principe. L'outil test_workflow, disponible depuis n8n 2.15.0, simule les déclencheurs, les nœuds avec identifiants et HTTP Request. Les autres nœuds s'exécutent normalement, y compris des commandes ou des lectures et écritures de fichiers sans identifiants. Utilisez donc un workflow de démonstration sans effet sensible.
Que faire en cas d'échec
Observez d'abord où le parcours s'arrête, sans conclure à une panne :
| Observation | Montage | Vérification, puis décision |
|---|---|---|
| Connexion impossible | Serveur d'instance | Comparez l'URL utilisée (terminée par /mcp-server/http) à celle affichée dans les réglages ; demandez à l'administrateur si l'accès MCP d'instance est activé. Sinon, vérifiez l'authentification acceptée par le client. |
| Connexion impossible | MCP Server Trigger | Vérifiez le transport accepté par le client (pas de STDIO natif) et l'éventuel proxy (buffering). Si le doute persiste, transmettez à l'administrateur l'adresse et le message d'erreur. |
| Outil absent | Trigger | Comparez l'adresse utilisée à l'URL de test ou de production selon le mode, et confirmez que l'écoute de test ou la publication est effective. |
| Workflow absent | Serveur d'instance | Distinguez un outil MCP absent d'un workflow non disponible : contrôlez Available in MCP et les droits ; un simple aperçu n'est pas un accès complet. |
| Appel accepté, exécution en échec | Tous | Contrôlez l'entrée fournie, le déclencheur admissible, les identifiants du workflow, puis le journal d'exécution. |
| Exécution terminée, résultat inattendu | Tous | Comparez avec le résultat attendu de la fiche ; un statut final ne suffit pas. |
Si le blocage persiste après ces vérifications, ou s'il touche des droits, un proxy ou des données sensibles, sollicitez la personne responsable de l'instance ou un prestataire.
Quand MCP apporte quelque chose, et quand viser plus direct
MCP est utile lorsqu'un assistant doit découvrir et utiliser des outils. Pour un échange fixe entre deux applications, commencez par examiner leur intégration native, une API ou un webhook : vous éviterez une couche de configuration si elle n'apporte rien au besoin.
Une nuance : le projet tiers décrit certaines opérations qu'il réalise par le MCP officiel, car l'API publique ne peut pas les effectuer. Le présenter comme un simple relais de l'API serait donc réducteur. Pour trancher, posez la question métier : qui doit déclencher quoi, avec quels droits, et pour quel gain constaté ? Il est parfois plus sage de ne pas automatiser un point.
Cadrer un essai limité
Choisissez d'abord le sens de connexion : n8n appelle un outil, ou un assistant appelle n8n. Préparez ensuite un workflow de démonstration, des droits minimaux et un résultat vérifiable. Une fois ce premier appel validé dans l'application finale, ajoutez les outils nécessaires un par un et gardez la possibilité de révoquer l'accès.