MCP n8n : créer et modifier vos workflows avec Claude, guide 2026

Avec le serveur MCP intégré à n8n, un client compatible comme Claude Desktop ou Claude Code peut créer ou modifier des workflows selon les droits accordés. Il peut aussi lancer ceux qui sont disponibles en MCP. Vérifiez les configurations et les résultats avant publication.

Choisir votre setup MCP n8n en 30 secondes

Le mot-clé “mcp n8n” recouvre plusieurs modes. Le bon choix dépend d’une seule question : qui est le client, et où se trouve le serveur MCP.

Ce tableau présente les modes de connexion. Les sections suivantes expliquent leurs réglages, leurs droits et leurs limites.

MCP n8n en clair : server, client, tools, node, workflow

MCP (Model Context Protocol) est un protocole standard pour que des clients (Claude, IDE, agents, scripts) puissent appeler des tools exposés par un serveur.

Deux éléments de contexte avant de choisir votre mode. D'abord, MCP n'est plus un projet maison d'Anthropic : le 9 décembre 2025, le protocole a été donné à l'Agentic AI Foundation, un fonds dirigé sous égide de la Linux Foundation, co-fondé par Anthropic, Block et OpenAI, avec le soutien de Google, Microsoft, AWS, Cloudflare et Bloomberg. À cette date, MCP revendiquait plus de 97 millions de téléchargements de SDK par mois et environ 10 000 serveurs actifs, avec un support client natif dans ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot et VS Code. Ensuite, la spécification vit : une révision a été publiée le 28 juillet 2026. Sources : annonce Anthropic, communiqué Linux Foundation et spécification MCP.

Dans la pratique, MCP n8n se lit comme ceci :

Un client se connecte à un serveur MCP. Il récupère la liste des tools. Il appelle un tool avec un input, souvent en json. Le serveur exécute, puis renvoie une réponse.

n8n s’intègre à MCP de trois manières complémentaires :

1. Le serveur MCP d’instance permet de rechercher, créer, modifier, valider et tester des workflows selon les droits accordés. Il peut lancer les workflows autorisés en MCP.
2. Le nœud MCP Server Trigger expose les outils reliés à un workflow. Pour proposer un autre workflow comme outil, reliez-le au nœud Custom n8n Workflow Tool.
3. n8n peut aussi appeler des outils MCP externes depuis un workflow avec MCP Client, ou depuis un agent avec MCP Client Tool.

Retenez une règle simple : pour créer ou modifier des workflows depuis Claude, commencez par le serveur MCP natif. Pour exposer un workflow précis comme serveur MCP sur mesure, utilisez MCP Server Trigger.

Mode 1 : activer le serveur MCP natif de n8n (instance-level access)

Une connexion au serveur MCP de l’instance donne accès aux opérations autorisées pour l’utilisateur et le client. Les outils de création, de modification et de test sont distincts de l’exécution des workflows rendus disponibles en MCP.

Activer MCP sur votre instance n8n

Dans n8n, ouvrez Settings > Instance-level MCP et activez « Enable MCP access » : cette activation demande le rôle de propriétaire ou d’administrateur. La création et la modification de workflows par MCP sont documentées à partir de n8n 2.13.0 ; vérifiez les outils disponibles sur votre instance.

Selon la version de n8n, les réglages affichent les informations de connexion, les accès aux workflows et les clients connectés.

• « Connection details » permet de connecter un client et de récupérer l’URL du serveur ;
• « Access » permet de consulter les workflows disponibles en MCP ;
• « Connected clients » permet d’examiner ou de révoquer les clients OAuth. L’interface détaillée dépend de la version de n8n.

Si vous êtes en self-hosted et que vous voulez désactiver la fonctionnalité au niveau config, n8n permet de retirer les endpoints MCP via la variable d’environnement N8N_DISABLED_MODULES=mcp.

OAuth2 ou token : quelle auth choisir pour vos clients

Le serveur MCP d’instance accepte OAuth ou une clé API personnelle transmise comme jeton Bearer. Les droits accordés à un client OAuth et les permissions de l’utilisateur déterminent les opérations possibles.

Avec OAuth, vérifiez les permissions demandées à la connexion. n8n permet ensuite de consulter et de révoquer chaque client OAuth dans « Connected clients ».

La clé API personnelle est liée au compte qui la génère. Copiez-la lors de sa création, conservez-la dans un emplacement sûr et prévoyez sa rotation : un nouveau jeton révoque l’ancien pour tous les clients qui l’utilisaient.

Limitez les permissions du client et les workflows disponibles en MCP. Tous les clients reliés avec un même utilisateur peuvent accéder aux workflows qu’il a rendus disponibles ; l’exposition ne se règle pas workflow par workflow pour chaque client.

Exposer un workflow à MCP : les règles d’éligibilité

Un client peut rechercher les aperçus des workflows visibles par son utilisateur, même si « Available in MCP » est désactivé. L’accès au contenu complet, la modification et l’exécution demandent l’activation MCP du workflow et les droits requis.

Pour rendre un workflow disponible en MCP, publiez-le et utilisez un déclencheur compatible : Webhook, Schedule, Chat ou Form. La création et les tests peuvent aussi porter sur un brouillon ; l’exécution en production utilise la version publiée.

C’est un point important pour la conception : si vous voulez un “tool” simple, un Webhook trigger est souvent le plus clair, car vous maîtrisez l’input json attendu.

Aider Claude à “comprendre” vos inputs : la description de workflow

Quand un client MCP choisit un workflow à exécuter, il a besoin de comprendre le format d’entrée. n8n recommande d’ajouter les détails dans la description du workflow, surtout si vous utilisez un webhook trigger. 

Une bonne description fait gagner beaucoup de temps. Elle doit rester simple et efficace.

Exemple de contenu utile dans la documentation du workflow :

• Ce que fait le workflow en une phrase.
• Les champs attendus en json (exemples inclus).
• Les valeurs possibles si vous avez des options.
• Le format de sortie.

Vous créez ainsi un “contrat” lisible par des clients et par un agent.

Execution : ce qui se passe vraiment quand un client lance un workflow

L’outil « execute_workflow » démarre le workflow et renvoie immédiatement un identifiant d’exécution. Consultez ensuite son statut et, si nécessaire, ses données avec « get_workflow_execution » ou l’onglet Executions de n8n. Le mode production lance la version publiée ; le mode manuel teste la version courante.

Il y a trois contraintes à connaître dès le début, car elles changent la façon de concevoir vos workflows MCP :

1. Le délai de cinq minutes est la valeur par défaut du test « test_workflow » ; sur les versions qui proposent le paramètre « timeout », il peut être relevé jusqu’à 60 minutes. « execute_workflow » démarre l’exécution sans attendre son résultat.
2. Si plusieurs déclencheurs sont compatibles, indiquez celui à utiliser quand votre version propose « triggerNodeName ». Sur les versions antérieures, vérifiez le déclencheur effectivement lancé.
3. Les formulaires à plusieurs étapes et les interactions humaines pendant l’exécution MCP ne sont pas pris en charge. Préparez les données d’entrée attendues par le déclencheur, par exemple un objet JSON pour un Webhook.

Avant la publication, testez un cas nominal et un cas d’erreur avec des données de test. Un brouillon n’est pas un bac à sable : une exécution manuelle peut agir sur les services reliés. Même « test_workflow », qui utilise des données simulées pour certains nœuds, peut exécuter du code ou modifier des fichiers. Vérifiez ses effets avant de lancer « publish_workflow », qui peut publier le brouillon courant.

Connecter Claude Desktop à votre n8n MCP server (instance-level)

n8n documente un chemin simple dans Claude Desktop : Settings > Connectors > Add custom connector. Collez l’URL « Server URL » fournie par n8n, terminée par /mcp-server/http, puis autorisez la connexion OAuth. Un connecteur distant Claude doit pouvoir joindre ce serveur depuis l’infrastructure d’Anthropic.

Dans Claude Code, la documentation n8n donne « claude mcp add --transport http n8n <URL> » pour OAuth, ou la même commande avec « --header "Authorization: Bearer <JETON>" » pour une clé API. Utilisez l’URL MCP de l’instance, pas celle de l’éditeur.

Choisissez les permissions nécessaires, contrôlez les workflows accessibles et vérifiez la réponse de chaque outil avant de lui confier une action sensible.

Mode 2 : MCP Server Trigger dans n8n (un workflow devient un server MCP)

Ce mode expose un ensemble d’outils défini dans un workflow. Il convient lorsque vous voulez choisir précisément les outils accessibles à ce point d’entrée.

Ce que fait vraiment le node MCP Server Trigger

Le node MCP Server Trigger expose une URL que les clients MCP peuvent appeler. Ensuite, les clients listent les tools disponibles et appellent un tool pour effectuer un travail.

Différence clé : ce node ne se comporte pas comme un trigger classique qui envoie des données au node suivant. Il se connecte et exécute uniquement des tools nodes.

Autre point utile : le node supporte SSE et streamable HTTP, mais ne supporte pas stdio. 

L’exemple de configuration locale plus bas utilise une passerelle vers stdio. Les connecteurs distants compatibles peuvent aussi utiliser directement une URL HTTP accessible.

Un point de calendrier à intégrer dès maintenant dans vos choix : la révision 2026-07-28 de la spécification MCP a officiellement déprécié le transport HTTP+SSE historique, avec une période de transition annoncée d'un an. Le streamable HTTP devient la voie par défaut. Concrètement, si vous montez un nouveau serveur MCP dans n8n aujourd'hui, privilégiez le streamable HTTP et traitez SSE comme un mode de compatibilité, pas comme une cible. Source : note de version de la spécification 2026-07-28.

Test URL et Production URL : comprendre le mode d’execution

Le node affiche une URL de test et une URL de production.

En test, n8n “écoute” et affiche les données dans l’éditeur quand vous exécutez le workflow en mode test.

La publication du workflow enregistre son URL de production. Les données des appels de production se consultent dans l’onglet Executions, selon les réglages de conservation des exécutions.

C’est un bon design pour le travail quotidien : test pour régler les inputs, production pour l’exploitation.

Auth et path : sécuriser votre endpoint MCP

Le node permet de forcer une auth côté client. Vous pouvez choisir Bearer auth ou Header auth.

Pour un endpoint accessible hors d’un réseau de confiance, configurez Bearer auth ou Header auth, protégez les identifiants et limitez les outils reliés au nœud. Une URL difficile à deviner ne remplace pas une authentification.

Le paramètre “Path” est aussi important. Par défaut, n8n génère un chemin aléatoire pour éviter les collisions entre nodes. Vous pouvez fixer un path propre si vous avez besoin d’URL stables, par exemple pour un template ou une documentation partagée. 

Configuration Claude Desktop : exemple json avec passerelle

La documentation n8n propose ci-dessous une configuration locale de Claude Desktop avec « npx » et « mcp-remote » pour relier ce serveur HTTP à stdio. Cet exemple utilise un jeton Bearer ; adaptez l’authentification à votre nœud.

Voici la structure telle qu’exposée dans la doc, avec vos valeurs :

{

  "mcpServers": {

    "n8n": {

      "command": "npx",

      "args": [

        "mcp-remote",

        "<MCP_URL>",

        "--header",

        "Authorization: Bearer ${AUTH_TOKEN}"

      ],

      "env": {

        "AUTH_TOKEN": "<MCP_BEARER_TOKEN>"

      }

    }

  }

}

Renseignez l’URL du nœud et gardez le jeton hors des documents partagés. Dans Claude Desktop, ce serveur local et un connecteur distant suivent deux modes de connexion distincts.

Docker, queue mode et reverse proxy : les deux pièges qui font tomber MCP

En auto-hébergement, vérifiez le routage des requêtes MCP et la configuration du proxy avant d’ouvrir l’URL de production.

Premier point : en queue mode, si vous avez plusieurs webhook replicas, SSE et streamable HTTP peuvent casser si les requêtes ne reviennent pas à la même instance. La doc n8n recommande de router toutes les requêtes /mcp* vers une seule instance dédiée, ou d’avoir un replica set séparé avec un seul conteneur webhook pour MCP.

Derrière nginx, la documentation du nœud recommande de désactiver « proxy buffering » sur l’endpoint MCP et de vérifier les autres réglages qui interrompent SSE ou streamable HTTP.

Ces contraintes concernent le nœud MCP Server Trigger documenté par n8n ; ne les transposez pas automatiquement au serveur MCP d’instance.

Mode 3 : n8n comme client MCP (MCP Client node) pour consommer des tools externes

Ici, le mot-clé “mcp n8n” prend l’autre sens : vous utilisez n8n pour appeler des tools exposés par un server externe, comme une étape normale d’un workflow.

Le node MCP Client est fait pour ça. Il permet de se connecter à un endpoint MCP, de choisir un tool, puis de fournir les paramètres. 

Quand ce mode est le bon choix

Ce mode est parfait si :

• vous avez déjà un server MCP externe (Notion, interne, outil maison),
• vous voulez l’utiliser dans des workflows existants,
• vous ne voulez pas exposer votre instance n8n à des clients externes.

Vous gardez n8n comme orchestrateur. Vous consommez MCP comme une brique.

Configuration du node MCP Client : transport, auth, json

Le node demande :

• Server Transport et MCP Endpoint URL,
• Authentication (Bearer, header, OAuth2, ou none),
• Tool (la liste est récupérée automatiquement depuis le server),
• Input Mode : Manual ou JSON.

Le choix “Input Mode” est plus important qu’il n’y paraît.

Manual est bien si le tool a 2 ou 3 paramètres simples.

JSON est préférable si vous avez des paramètres imbriqués. C’est aussi plus simple à versionner et à relire dans un template.

Le node propose aussi un timeout et une option “Convert to Binary” selon le type de retour (images, audio).

Dans un flux de production, je recommande de garder le JSON explicite. Cela facilite la validation, la revue, et le debug.

Mode 4 : connecter un agent n8n à des tools MCP externes (MCP Client Tool node)

Ce mode est très “agent”. Vous voulez que l’agent puisse choisir et appeler des tools externes, sans que vous codiez la sélection du tool.

Le node MCP Client Tool sert précisément à ça. Il connecte un agent à un server MCP et expose ses tools à l’agent.

La configuration minimale

Le node demande :

• un endpoint SSE dans l’interface documentée ;
• une authentification adaptée au serveur externe ;
• « Tools to Include » pour choisir les outils visibles par l’agent.

Ce dernier point est votre meilleur levier de gouvernance.

En “All”, l’agent voit tout.

En “Selected”, vous créez une whitelist.

« All Except » exclut quelques outils. « Selected » permet de limiter explicitement la liste ; vérifiez aussi les droits du compte distant et les contrôles dans le workflow.

Le pattern “agent” qui marche en entreprise

Un agent sans garde-fous est souvent trop libre. MCP n8n devient puissant quand vous structurez le flux.

Un pattern simple :

• l’agent reçoit la demande,
• il ne voit que des tools utiles,
• le workflow appelé valide les champs et les règles avant toute écriture sensible ;
• l’agent ou l’utilisateur vérifie le résultat et les effets produits.

C’est cette combinaison qui transforme MCP en vrai levier de travail, et pas en gadget.

Des idées de workflows MCP n8n qui apportent vite de la valeur

On parle beaucoup de protocole. En réalité, ce qui compte, c’est le résultat dans vos flux.

Voici des exemples qui se prêtent bien à MCP n8n, car ils ont un input clair, une execution rapide, et un output utile.

Un assistant “ops” qui prépare un compte rendu. Le client (Claude Desktop) appelle un tool “resume” avec un json contenant notes, date, participants. n8n transforme, met en forme, puis pousse dans Notion ou Google Docs. Le workflow fait le travail lourd, le client guide.

Un agent commercial qui qualifie un lead. Le client envoie un json (source, entreprise, taille, besoin). Le workflow enrichit, applique une règle de level, puis renvoie une recommandation. Si le score dépasse un seuil, un second workflow crée une tâche. Tout est traçable dans l’execution.

Un flux support prépare une réponse. Claude appelle un outil « draft_reply » ; n8n récupère le contexte et produit un brouillon. Si une validation humaine est requise, elle peut avoir lieu dans un processus séparé avant l’envoi : l’exécution MCP elle-même ne prend pas en charge une attente humaine à plusieurs étapes.

Un setup finance simple. Un tool déclenche un export, calcule des indicateurs, puis renvoie un tableau synthétique. Le client reçoit un output structuré. Le workflow garde l’historique.

Ces exemples ont un point commun : vous n’essayez pas de faire parler MCP. Vous faites travailler n8n. MCP devient l’access standard pour déclencher le bon workflow au bon moment.

Sécurité, access, validation : le vrai niveau de qualité sur MCP n8n

Sur “mcp n8n”, la sécurité est rarement un sujet au début. Puis elle devient centrale dès que plusieurs clients apparaissent.

Quelques principes simples qui évitent les accidents.

N’activez « Available in MCP » que pour les workflows nécessaires et vérifiez les droits des utilisateurs. « search_workflows » peut toutefois retourner un aperçu des autres workflows qu’un utilisateur est autorisé à voir.

Avec OAuth, examinez les permissions accordées à chaque client et révoquez celles qui ne sont plus nécessaires. Le jeton personnel suit une autre logique : sa rotation affecte tous les clients qui l’utilisent.

Si vous utilisez un token, organisez la rotation. n8n révoque l’ancien token quand vous en générez un nouveau. Préparez un processus pour mettre à jour vos clients.

Décrivez les entrées et sorties attendues des workflows. Cette description guide le client ; elle ne remplace pas la validation des données dans n8n.

Ajoutez une validation côté n8n quand l’action est sensible. Un node de contrôle, une vérification de champs, un test de règles. MCP donne l’accès. La validation donne la confiance.

Pour le serveur d’instance, distinguez « execute_workflow », qui renvoie un identifiant, et « test_workflow », dont le délai est de cinq minutes par défaut et peut être ajusté selon la version. Les interactions humaines à plusieurs étapes restent hors du parcours d’exécution décrit.

Docker et configuration : ce qu’il faut vérifier avant d’ouvrir à des clients

Si vous êtes en docker, vous avez deux niveaux de config. Celui de n8n et celui de votre réseau.

Côté n8n, sachez que vous pouvez désactiver MCP totalement via N8N_DISABLED_MODULES=mcp si vous avez besoin d’un kill switch.

Côté réseau, retenez deux règles.

Pour le nœud MCP Server Trigger en queue mode avec plusieurs réplicas webhook, la documentation n8n demande de router toutes les requêtes /mcp* vers un seul réplica dédié.

La spécification MCP du 28 juillet 2026 décrit un protocole sans session et un routage par en-têtes « Mcp-Method » et « Mcp-Name ». Cela ne prouve pas que le nœud n8n déployé sur votre instance utilise déjà ce fonctionnement : suivez sa documentation et testez votre routage réel.

Derrière nginx, vérifiez le proxy de l’endpoint MCP Server Trigger pour SSE et streamable HTTP. n8n recommande notamment de désactiver « proxy buffering » pour /mcp/.

Ce n’est pas un détail. Si vous voulez un service fiable pour vos clients, c’est la base.

Quand ça bloque : diagnostic rapide

• Workflow absent : vérifiez les droits de l’utilisateur et « Available in MCP ». La recherche peut afficher un aperçu sans donner le droit d’exécuter. Ne publiez un brouillon qu’après l’avoir relu.
• Erreur 401 ou 403 : contrôlez l’URL, l’authentification et les permissions. La rotation d’un jeton exige de mettre à jour les clients qui l’utilisent.
• Connexion interrompue avec MCP Server Trigger : contrôlez le proxy et sa mise en tampon des réponses (« proxy buffering »).
• MCP Server Trigger avec plusieurs instances : vérifiez le routage /mcp* vers une instance dédiée selon la configuration documentée par n8n.
• Délai dépassé : identifiez l’outil appelé. « execute_workflow » renvoie un identifiant à suivre ; « test_workflow » attend un résultat avec un délai configurable selon la version. Vérifiez l’état avant de relancer pour éviter les doublons.

Différentes causes de bugs n8n

L’idée est de rester simple : MCP n8n n’échoue pas souvent “au hasard”. Il échoue presque toujours à cause de l’access, du mode réseau, ou d’un workflow mal adapté.

Industrialiser vos workflows IA en production

Connecter Claude à n8n via MCP en démo, c'est une chose. Le tenir en production, fiabilité, sécurité, coûts sous contrôle, montée en charge, en est une autre. C'est le cœur du métier de Scroll : le développement d'applications et d'automatisations assistées par IA, pensées pour la prod dès le départ.

Si vous avez un projet d'intégration IA sérieux, voir notre approche développement code IA ou intégrer Claude en entreprise. Pour un projet IA déjà lancé qui patine, le diagnostic de reprise IA est gratuit et sans engagement.

Pour une vue d'ensemble du protocole et des serveurs MCP essentiels, voir notre guide complet MCP 2026.

Le prochain pas : industrialiser MCP n8n dans votre stack

Quand MCP n8n est bien posé, vous obtenez un effet très concret : vos clients peuvent déclencher des workflows fiables, vos agents peuvent utiliser des tools maîtrisés, et votre instance garde la trace de chaque exécution.

C’est aussi là que les projets se jouent : choix du mode (instance-level ou MCP Server Trigger), design des workflows, validation, config docker, gouvernance des tokens, documentation et templates pour les clients.

Chez Scroll, on aide justement les équipes à passer de “ça marche sur mon desktop” à un setup propre, sécurisé et maintenable : architecture MCP, design d’agents, refonte de flux, industrialisation n8n, et mise en production avec un niveau de validation adapté à votre contexte. Si vous voulez gagner du temps et éviter les pièges classiques, on peut cadrer ensemble votre cas d’usage “mcp n8n” et livrer une configuration qui tient dans la durée.