MCP n8n : connecter Claude à vos workflows, et passer en production sans surprises

Vous voulez que Claude (Desktop ou autre client) puisse lancer vos workflows n8n comme des tools, avec une configuration simple, un accès sécurisé et une exécution fiable. MCP n8n est fait pour ça.

Choisir votre setup MCP n8n en 30 secondes

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

Ce tableau vous évite 80% des erreurs de départ. Ensuite, on déroule chaque mode, avec la config, les nodes, le json, et les points de validation.

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.

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 deux manières complémentaires :

1. n8n peut être un serveur MCP au niveau instance, et exposer des workflows choisis, comme si chaque workflow était un tool.
2. n8n peut exposer un serveur MCP depuis un workflow via le node MCP Server Trigger, et exécuter uniquement des tool nodes, pas un flux classique. 
3. n8n peut être un client MCP pour consommer des tools externes dans vos workflows ou dans un agent, via MCP Client et MCP Client Tool. 

Retenez une règle simple : si votre objectif est “Claude utilise mes workflows n8n”, commencez par le mode instance-level. Si votre objectif est “je fabrique un server MCP custom dans n8n”, utilisez MCP Server Trigger.

Mode 1 : activer le MCP server intégré de n8n (instance-level access)

C’est le chemin le plus direct pour “mcp n8n”. Vous activez l'accès MCP sur l’instance, puis vous exposez quelques workflows. Les clients se connectent, listent les workflows disponibles, puis déclenchent une exécution.

Activer MCP sur votre instance n8n

Dans n8n, allez dans Settings puis Instance-level MCP, puis activez “Enable MCP access”. Il faut être owner ou admin. 

Une fois activé, n8n vous affiche une page qui centralise :

• la liste des workflows exposés,
• les clients OAuth connectés,
• un bouton “Connection details” avec l’URL du server et les instructions de config. 

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

n8n propose deux options de configuration côté client : OAuth2 ou Access Token. 

OAuth2 est souvent le meilleur choix quand vous avez plusieurs clients, ou quand vous voulez pouvoir révoquer un client précisément. n8n permet de révoquer l’access d’un client OAuth depuis l’onglet “Connected clients”. 

Le token est très rapide pour un premier test. Attention : lors de la première génération, n8n vous demande de copier le token tout de suite. Ensuite il est masqué. Il existe un mécanisme de rotation qui révoque l’ancien token et oblige à mettre à jour tous les clients. 

Dans les deux cas, pensez “access minimal” : n’exposez que les workflows utiles, et gardez une logique de validation en amont.

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

Dans le mode instance-level, un workflow n’est visible par aucun client tant que vous ne l’avez pas explicitement activé.

Pour être éligible, le workflow doit être publié, et contenir un trigger supporté : Webhook, Schedule, Chat ou Form.

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

Quand un client déclenche un workflow via MCP, l'exécution se déroule comme d’habitude dans n8n. Vous pouvez la suivre dans la liste des Executions. Quand l’execution se termine, le client récupère le résultat.

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

1. n8n impose un timeout de 5 minutes pour les executions déclenchées par des clients MCP, même si vous avez configuré autre chose dans le workflow. 
2. Si un workflow contient plusieurs triggers supportés, un client peut n’en utiliser qu’un, souvent le premier. 
3. Les interactions humaines multi-étapes ne sont pas supportées, et l’input binaire n’est pas supporté. MCP se limite à du texte, donc plutôt du json. 

En clair : pour MCP n8n, privilégiez des workflows rapides, déterministes, et “tout automatisable”.

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

n8n documente un chemin simple dans Claude Desktop : Settings, puis Connectors, puis “Add custom connector”, puis renseigner l’URL du server n8n, puis autoriser.

Si vous utilisez Claude Code en ligne de commande, n8n fournit aussi un exemple avec ajout d’un server MCP en transport HTTP et un header Authorization Bearer avec votre token.

Le point important n’est pas l’outil. Le point important est la discipline : un client doit avoir un access clair, un token maîtrisé, et des workflows bien décrits.

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

Ce mode est très recherché car il donne une liberté énorme : vous créez un server MCP “sur mesure” dans un workflow, avec vos tools, vos règles, votre validation, et vos nodes.

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. 

Cela explique pourquoi certains clients desktop ont besoin d’une passerelle.

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.

En production, l’URL devient stable quand vous publiez le workflow. Vous ne voyez pas les données dans l’éditeur, mais vous pouvez les consulter dans l’onglet Executions.

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.

Utilisez un token dès le départ. En production, évitez les endpoints MCP ouverts, même pour un POC.

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

Comme le node MCP Server Trigger n’est pas en stdio, n8n propose une configuration Claude Desktop qui utilise une passerelle via npx et mcp-remote, avec un header Authorization Bearer.

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>"

      }

    }

  }

}

‍

Ce format est très pratique pour vos clients internes : vous leur donnez un template de config, plus un token, plus une URL. Ensuite, Claude peut use vos tools comme des actions.

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

Sur un setup docker auto-hébergé, les soucis MCP n8n viennent rarement du node. Ils viennent du réseau et du mode d’execution.

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.

Deuxième point : derrière un reverse proxy comme nginx, vous devez configurer l’endpoint MCP pour SSE, notamment en désactivant le proxy buffering, et en ajustant des options comme gzip, chunked transfer encoding, et le header Connection. n8n fournit un exemple de bloc nginx pour /mcp/.

Si vous retenez une seule chose pour docker : MCP demande une connexion persistante. Donc votre config réseau doit être pensée pour ça.

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 SSE Endpoint,
• une auth (Bearer, header, OAuth2, ou none),
• un réglage “Tools to Include” pour décider quels tools sont 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.

En “All Except”, vous bloquez quelques tools sensibles. Dans un contexte client, je privilégie “Selected”. Cela réduit le risque et améliore la qualité de l’agent. Moins de tools, mieux choisis, mieux documentés.

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,
• un node de validation vérifie l’input json et les limites (ex : pas d’écriture CRM si champ vide),
• puis seulement vous lancez l’execution.

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 qui propose une réponse. Claude use un tool “draft_reply”. Le workflow cherche la bonne documentation, récupère le contexte ticket, produit une réponse, puis déclenche une validation humaine avant envoi.

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.

Exposez peu. En instance-level, aucun workflow n’est exposé par défaut, et vous choisissez explicitement ceux qui le sont. Gardez cette discipline.

Préférez OAuth2 quand vous avez plusieurs clients. Vous pouvez révoquer un client sans casser les autres. 

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.

Écrivez des descriptions de workflows. Ce n’est pas cosmétique. C’est une part de la validation, car elle guide le client sur les bons inputs. 

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.

Enfin, respectez les limites du mode MCP. Pas de binaire en input, pas de human-in-the-loop, et 5 minutes max d’execution en instance-level. Cela doit influencer votre design.

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.

SSE et streamable HTTP demandent une connexion stable sur la même instance. En queue mode avec plusieurs webhook replicas, routez /mcp* vers une instance dédiée. 

Derrière nginx, configurez l’endpoint MCP pour SSE. Sinon vous aurez des connexions qui coupent, des réponses incomplètes, ou des tools qui ne répondent pas. La doc 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

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é.

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.

‍