n8n serveur MCP : connecter vos agents IA aux workflows

Un agent IA capable d’interroger votre stock, de créer une tâche ou d’envoyer un rapport sans qu’on lui code chaque appel : c’est l’objet du Model Context Protocol couplé à n8n. Le protocole, développé initialement par Anthropic, sert d’interface standard entre un modèle de langage et des outils externes. En l’intégrant, n8n transforme ses 700 et quelques intégrations en outils directement utilisables par Claude, Cursor ou un agent maison.

Cet article détaille les quatre façons d’utiliser MCP dans n8n, leur configuration exacte, les pièges de déploiement en production et les questions de sécurité que tout responsable technique se pose avant d’exposer une instance.

Qu’est-ce que le protocole MCP et pourquoi il change l’automatisation avec n8n

Le Model Context Protocol définit un langage commun pour qu’un agent IA découvre et appelle des outils. Au lieu de coder chaque intégration à la main, l’agent demande au serveur MCP la liste des outils disponibles, lit leur description, puis les invoque avec les bons paramètres. n8n peut être ce serveur : chaque workflow exposé devient un outil que le modèle peut déclencher de lui-même.

L’apport concret tient dans cette découverte automatique. Un workflow n8n nommé « Vérifier le stock produit » avec une description claire devient utilisable par Claude sans intervention humaine supplémentaire. Le modèle comprend qu’il dispose de cet outil, sait quels paramètres lui passer, et reçoit le résultat structuré.

MCP vs API REST classique : ce qui change concrètement

Un appel API REST classique suppose que le développeur connaisse à l’avance l’endpoint, le format du payload et la structure de la réponse. Tout est figé dans le code de l’agent. Si vous ajoutez une fonctionnalité, vous modifiez le code client.

Avec MCP, l’agent interroge le serveur pour obtenir la liste des outils et leur schéma au moment de l’exécution. Ajoutez un nouveau workflow exposé côté n8n, et l’agent le voit immédiatement sans redéploiement. Cette découverte dynamique est la vraie rupture par rapport à un simple webhook ou une route REST documentée.

Les quatre rôles possibles de n8n dans un écosystème MCP

n8n peut occuper plusieurs positions, parfois simultanément. L’accès MCP au niveau de l’instance expose vos workflows existants sans en créer de nouveau. Le nœud MCP Server Trigger transforme un workflow donné en serveur MCP autonome. Le nœud MCP Client Tool permet à un agent n8n de consommer des serveurs MCP tiers. Et le nœud MCP Client plus général sert à interroger des outils externes hors contexte agent.

Ces modes répondent à des besoins distincts. Les sections suivantes les détaillent un par un, car la confusion entre eux est la source la plus fréquente d’erreurs de configuration.

Mode 1 : activer le serveur MCP natif de n8n au niveau de l’instance

Depuis la version 2.18.4 sortie en avril 2026, n8n embarque un serveur MCP intégré accessible via Settings puis Connectors. Ce mode expose vos workflows existants comme outils, sans construire de workflow dédié. Lancé le 29 avril 2026, il va plus loin que la simple exposition : un client comme Claude peut construire, valider et exécuter des workflows depuis une invite.

Activer l’accès MCP sur une instance n8n Cloud ou self-hosted

Sur n8n Cloud, l’activation se fait depuis les paramètres de l’instance, dans la section Connectors. Vous générez un point d’accès MCP et choisissez la méthode d’authentification. Aucun surcoût : la fonctionnalité est disponible sur toutes les éditions, Cloud, Enterprise et Community.

En self-hosted, l’activation passe par les paramètres de l’interface mais nécessite aussi des variables d’environnement côté serveur, détaillées plus loin. Le principe reste le même : une fois activé, le serveur expose les workflows que vous autorisez explicitement.

Authentification OAuth2 ou Access Token : quelle méthode choisir

Deux méthodes coexistent. L’Access Token, ou Bearer Token, est un jeton statique que vous générez et copiez dans la configuration du client MCP. Simple à mettre en place, il convient aux usages internes et aux tests. Sa limite : un jeton compromis donne accès jusqu’à révocation manuelle.

OAuth2 ajoute une couche de flux d’autorisation et convient mieux aux déploiements multi-utilisateurs ou exposés. Le client négocie un jeton temporaire, ce qui réduit la surface de risque. Pour une équipe qui partage l’accès ou une exposition publique, OAuth2 est le choix par défaut ; pour un agent unique en environnement contrôlé, le Bearer Token suffit.

Exposer un workflow au serveur MCP : règles d’éligibilité et descriptions

Un workflow doit être actif pour être exposé. La description joue un rôle critique : c’est elle que le client MCP lit pour décider quand et comment appeler l’outil. Une description vague comme « traite les données » empêche le modèle de comprendre quand l’utiliser.

Rédigez la description comme une consigne destinée à un assistant : « Récupère le niveau de stock d’un produit à partir de sa référence SKU, renvoie la quantité disponible et la date de dernier réapprovisionnement. » Précisez les entrées attendues et le format de sortie. C’est l’élément le plus souvent bâclé, et celui qui explique le plus d’échecs d’appel.

Mode 2 : créer un serveur MCP avec le nœud MCP Server Trigger

Le nœud MCP Server Trigger transforme un workflow individuel en serveur MCP indépendant. Contrairement à l’accès instance-level qui expose un ensemble de workflows existants, ce mode crée un serveur dédié dont vous contrôlez le contenu outil par outil. Chaque outil rattaché à ce trigger correspond à un sous-workflow n8n indépendant.

Différence entre instance-level MCP access et MCP Server Trigger

La distinction tient au périmètre. L’accès instance-level expose globalement les workflows que vous autorisez, et permet même au client de manipuler la structure des workflows. Le MCP Server Trigger, lui, définit un serveur ciblé : vous choisissez précisément quels outils il propose, en attachant des nœuds-outils à ce trigger unique.

Critère	Accès instance-level	MCP Server Trigger
Périmètre	Workflows de l’instance	Outils attachés au trigger
Création de workflow	Possible par le client	Non, exécution seulement
Cas d’usage	Assistant de build n8n	Serveur d’outils métier ciblé

Pour un agent métier qui ne doit appeler que trois ou quatre actions précises, le MCP Server Trigger est le bon choix. Pour donner à un assistant la capacité de construire et tester des workflows, l’accès instance-level s’impose.

Test URL et Production URL : comprendre les deux modes d’exécution

Le nœud MCP Server Trigger génère deux URLs. L’URL de test ne fonctionne que pendant l’écoute active de l’éditeur n8n, lorsque vous cliquez sur « Listen for test event ». Elle sert au développement et expire dès que vous quittez ce mode.

L’URL de production est permanente et fonctionne dès que le workflow est activé. L’erreur classique consiste à configurer un client MCP avec l’URL de test, puis à constater que les appels échouent en dehors des sessions d’édition. Vérifiez toujours que le client pointe vers l’URL de production une fois le serveur stabilisé.

Sécuriser l’endpoint MCP : authentification et configuration du path

L’endpoint accepte Bearer Token ou Header Auth. Le Header Auth permet de définir un nom de header et une valeur attendue, utile pour s’intégrer à une passerelle existante. Choisissez un path non devinable plutôt que la valeur par défaut, et ne laissez jamais un endpoint sans authentification accessible depuis internet.

En production, l’HTTPS n’est pas optionnel. Le jeton circule dans les headers ; sans TLS, il est exposé en clair. La documentation officielle du nœud MCP Server Trigger précise les options d’authentification et de path disponibles, qu’il vaut mieux consulter avant toute exposition publique.

Mode 3 : utiliser n8n comme client MCP pour consommer des outils externes

n8n n’est pas seulement serveur. Le nœud MCP Client Tool permet à un agent n8n d’utiliser des serveurs MCP tiers comme outils. Un agent IA construit dans n8n peut ainsi appeler un serveur MCP Supabase, Google Calendar ou GitHub sans que vous codiez chaque intégration.

Configurer le nœud MCP Client Tool dans un agent n8n

Le nœud se rattache à un nœud AI Agent. La configuration minimale demande l’URL du serveur MCP cible, le mode de transport et les identifiants. Deux transports existent : SSE (Server-Sent Events) sur HTTP, adapté aux serveurs distants, et stdio, réservé aux serveurs lancés en processus local.

Pour un serveur MCP hébergé sur une autre machine ou dans le cloud, choisissez SSE et renseignez l’authentification, généralement un Bearer Token. Pour un serveur exécuté localement à côté de n8n, stdio est plus direct mais suppose que le binaire soit accessible dans l’environnement de n8n.

Connecter un agent n8n à des serveurs MCP externes comme Supabase ou Google Calendar

Un agent de planification illustre bien l’usage. Vous attachez un MCP Client Tool pointant vers un serveur MCP Google Calendar, et l’agent peut créer, lire ou déplacer des événements à la demande de l’utilisateur. Le LLM choisit l’outil et les paramètres en fonction de la requête en langage naturel.

Même logique avec Supabase : l’agent interroge la base, insère des lignes ou exécute des requêtes via le serveur MCP correspondant. L’intérêt est de composer plusieurs serveurs MCP dans un seul agent, qui orchestre alors des actions sur plusieurs systèmes à partir d’une conversation unique.

Connecter Claude Desktop, Cursor et Codex CLI à un serveur MCP n8n

Côté client, la connexion se fait par un fichier de configuration JSON déclarant les serveurs MCP disponibles. La structure varie peu d’un client à l’autre, l’essentiel tenant dans l’URL et la méthode d’authentification.

Configuration JSON pour Claude Desktop avec OAuth2 ou token Bearer

Claude Desktop lit un objet mcpServers dans son fichier de configuration. Pour un serveur n8n avec Bearer Token, la déclaration ressemble à ceci :

{
  "mcpServers": {
    "n8n": {
      "url": "https://votre-instance.n8n.cloud/mcp/votre-path",
      "headers": {
        "Authorization": "Bearer VOTRE_TOKEN"
      }
    }
  }
}

Avec OAuth2, vous renseignez le point d’autorisation plutôt qu’un jeton statique, et Claude gère le flux de négociation. Le reste de la structure reste identique. Après modification, redémarrez Claude Desktop pour qu’il recharge la liste des outils exposés par n8n.

Connecter Codex CLI ou un agent Google ADK à n8n

Codex CLI et les agents construits avec Google ADK suivent le même principe : déclarer l’URL du serveur MCP n8n et l’en-tête d’authentification. La documentation officielle de n8n fournit des exemples de configuration pour ces clients, à adapter selon le transport SSE retenu.

Tout client supportant SSE ou stdio se connecte de la même façon. Cursor et Windsurf, par exemple, exposent une interface de configuration MCP dans leurs paramètres où vous collez l’URL et le jeton. Le mécanisme de découverte fait le reste.

Déploiement n8n MCP en production : Docker, queue mode et reverse proxy

Le passage en production introduit des contraintes que les tutoriels locaux ignorent. Le transport SSE maintient une connexion persistante entre client et serveur, ce qui change la donne pour le reverse proxy et le mode de file d’attente.

Variables d’environnement à configurer pour activer MCP en self-hosted

En self-hosted, certaines variables d’environnement doivent être définies pour activer le serveur MCP et fixer l’URL publique. La variable N8N_HOST et WEBHOOK_URL doivent refléter l’adresse réellement accessible depuis internet, sans quoi les URLs générées par le MCP Server Trigger pointeront vers une adresse interne inutilisable. Vérifiez aussi que N8N_PROTOCOL est positionné sur https derrière votre proxy.

Dans un Docker Compose, ces variables se déclarent dans le bloc environment du service n8n. Une URL mal configurée est la cause la plus fréquente des connexions clients qui échouent silencieusement après un déploiement.

Reverse proxy Nginx ou Traefik : points de configuration critiques pour SSE

SSE repose sur une réponse HTTP qui reste ouverte. Un proxy mal réglé coupe la connexion au bout de quelques secondes ou met la réponse en tampon, ce qui casse le flux. Côté Nginx, désactivez le buffering avec proxy_buffering off et allongez les timeouts avec proxy_read_timeout à plusieurs minutes.

Il faut aussi forcer HTTP/1.1 et neutraliser l’en-tête Connection pour autoriser le streaming :

location /mcp/ {
    proxy_pass http://n8n:5678;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    proxy_read_timeout 3600s;
}

Sur Traefik, l’équivalent passe par la désactivation du buffering au niveau du middleware et l’augmentation des timeouts de réponse. C’est le point le moins documenté et celui qui bloque le plus d’installations en production.

Queue mode et MCP Server Trigger : précautions à prendre

Le queue mode répartit l’exécution des workflows sur plusieurs workers. Les connexions SSE étant persistantes et liées à un processus, elles s’accommodent mal d’une architecture où les requêtes sont distribuées. Une connexion établie sur le main process peut perdre le contexte si l’exécution est routée vers un worker distinct.

Si vous utilisez le queue mode, isolez le traitement du MCP Server Trigger sur le main process et assurez-vous que le proxy maintient l’affinité de session vers le bon nœud. Tester ce comportement sous charge avant la mise en service évite des coupures intermittentes difficiles à diagnostiquer.

Sécurité et gestion des accès sur un serveur MCP n8n

Exposer un serveur MCP revient à donner à un agent IA la capacité de déclencher des actions dans vos systèmes. Le périmètre d’exposition et la gestion des jetons méritent autant d’attention que la configuration technique.

Limiter l’exposition des workflows : accès par projet ou par dossier

N’exposez pas l’ensemble de l’instance par défaut. Organisez vos workflows par projet et n’activez l’accès MCP que sur le périmètre nécessaire. Un agent support n’a aucune raison d’accéder aux workflows de facturation ou d’administration.

Cette granularité réduit l’impact d’un jeton compromis et clarifie ce qu’un agent peut faire. Plus le périmètre est restreint, plus l’audit est simple.

Ce qu’un client MCP peut et ne peut pas faire sur votre instance n8n

Cela dépend du mode. Avec le MCP Server Trigger, le client se limite à exécuter les outils attachés au trigger : il ne peut ni créer ni modifier de workflow. Avec l’accès instance-level activé pour le build, depuis la 2.18.4, le client peut au contraire construire, valider et exécuter des workflows.

Cette distinction est décisive. Si vous voulez interdire toute modification de structure, utilisez exclusivement le MCP Server Trigger et n’activez pas les capacités de build de l’accès instance-level.

Révoquer un token MCP et auditer les exécutions déclenchées par un agent

Un jeton compromis se révoque depuis les paramètres de connexion MCP, ce qui invalide immédiatement tout client l’utilisant. Pour OAuth2, la révocation s’opère au niveau du flux d’autorisation. Tournez régulièrement les jetons des intégrations sensibles.

Chaque appel MCP déclenche une exécution visible dans l’historique d’exécutions de n8n. Vous y voyez le workflow appelé, les paramètres reçus et le résultat. C’est votre piste d’audit pour vérifier qu’un agent n’a déclenché que des actions attendues.

Cas d’usage concrets du serveur MCP n8n en entreprise

L’intérêt du serveur MCP se mesure aux usages qu’il débloque. Trois scénarios reviennent fréquemment en PME, et de manière générale les cas concrets de workflows n8n sont réalisables en quelques heures de configuration.

Chatbot e-commerce connecté au stock en temps réel via MCP

Un client demande au chatbot si un produit est disponible. L’agent IA appelle un outil MCP n8n qui interroge l’ERP ou la base de données et renvoie la quantité réelle. Le modèle formule alors une réponse en langage naturel, avec la date de réapprovisionnement si le stock est nul.

Le workflow n8n centralise la logique d’accès aux données, et n’importe quel canal conversationnel s’y branche via MCP. Pas de duplication de l’intégration ERP pour chaque interface.

Assistant support avec base de connaissances interne déclenchée par MCP

Un agent support récupère des articles de FAQ ou consulte des tickets existants via un tool MCP. Quand un utilisateur pose une question, l’agent interroge la base de connaissances interne, identifie les articles pertinents et propose une réponse sourcée. Si le problème dépasse la FAQ, il crée un ticket.

Toute la logique de recherche et de création reste dans n8n, ce qui permet de l’auditer et de la faire évoluer sans toucher au modèle. Dans ce type de scénario, la manipulation des fichiers binaires n8n devient utile dès qu’un outil renvoie des pièces jointes ou des documents.

Agent de gestion interne PME : création de tâches, emails et rapports automatiques

Un seul serveur MCP n8n peut exposer plusieurs outils métier : créer une tâche dans Notion, envoyer un email, générer un rapport hebdomadaire. Un LLM orchestre ces actions à partir d’une instruction comme « envoie le rapport de ventes de la semaine à l’équipe commerciale et crée une tâche de relance pour les comptes inactifs ».

Avec les centaines d’intégrations de l’outil d’automatisation n8n, du CRM à la messagerie, l’agent compose des actions sur plusieurs systèmes sans intégration spécifique. C’est l’usage qui apporte le plus de valeur le plus vite. Les équipes pédagogiques retrouvent d’ailleurs des utilisations d’n8n en formation calquées sur cette même logique d’orchestration.

Diagnostic et résolution des problèmes courants sur n8n MCP

Les blocages se concentrent sur trois symptômes : outils invisibles, connexion SSE qui échoue, exécution muette. Chacun a des causes identifiables.

Le client MCP ne trouve pas les outils exposés par n8n

La cause la plus fréquente est un workflow inactif : un workflow non activé n’apparaît pas dans la liste des outils. Vient ensuite la description manquante, qui empêche le client d’interpréter l’outil, et l’accès MCP non activé au niveau du projet concerné.

Vérifiez dans cet ordre : workflow actif, description renseignée, accès MCP autorisé sur le périmètre, URL de production et non de test côté client. Quatre points qui couvrent la quasi-totalité des cas.

Erreur de connexion SSE avec Claude Desktop ou Cursor

Un échec de connexion SSE pointe presque toujours vers le reverse proxy ou le certificat. Un timeout court coupe la connexion persistante ; un buffering activé empêche le streaming. En self-hosted, un certificat SSL auto-signé est rejeté par certains clients qui exigent une chaîne valide.

Reprenez la configuration proxy détaillée plus haut, vérifiez que l’URL utilise HTTPS avec un certificat reconnu, et testez la connexion avec un outil en ligne de commande avant de blâmer le client.

Exécution qui échoue silencieusement sans retour d’erreur au client

Quand l’agent ne reçoit ni résultat ni message d’erreur, l’exécution a souvent échoué à l’intérieur du workflow sans remonter l’information. Ouvrez l’historique d’exécutions de n8n : vous y verrez l’exécution déclenchée par l’agent et le nœud qui a planté.

Activez les logs détaillés et vérifiez le format de sortie de l’outil. Un workflow qui renvoie une structure inattendue peut être interprété comme un succès vide côté client. Standardiser le format de réponse des outils prévient ce silence. Les mêmes bonnes pratiques que pour la configuration des webhooks n8n s’appliquent ici pour fiabiliser les retours.

FAQ sur le serveur MCP n8n

Qu’est-ce que le serveur MCP n8n ?

C’est la capacité de n8n à exposer ses workflows comme outils via le Model Context Protocol, pour qu’un agent IA comme Claude les découvre et les exécute. n8n supporte MCP nativement depuis la version 1.68, avec un serveur intégré disponible depuis la 2.18.4 d’avril 2026.

Quelle est la différence entre le MCP Server Trigger et l’accès MCP instance-level ?

Le MCP Server Trigger expose les outils d’un workflow précis, en exécution seulement. L’accès instance-level expose les workflows de l’instance et peut autoriser un client à les construire et modifier. Critère de choix : limitez-vous au Server Trigger si vous voulez interdire toute modification de structure.

Faut-il des compétences en développement pour déployer un serveur MCP dans n8n ?

Sur n8n Cloud, non : l’activation et la configuration se font dans l’interface, en une dizaine de minutes pour un premier serveur. En self-hosted, des bases en Docker, variables d’environnement et reverse proxy sont nécessaires pour gérer le transport SSE en production.

Quels clients MCP sont compatibles avec n8n ?

Claude Desktop, Cursor, Windsurf, Codex CLI, les agents Google ADK, Cline et plus généralement tout client supportant le transport SSE ou stdio. La configuration repose sur une déclaration JSON de l’URL du serveur et de l’authentification.

Un client MCP peut-il créer ou modifier des workflows n8n directement ?

Cela dépend du mode. Via le MCP Server Trigger, non : le client exécute uniquement les outils exposés. Via l’accès instance-level avec capacités de build activées depuis la 2.18.4, oui : le client peut construire, valider et exécuter des workflows.

MCP n8n fonctionne-t-il uniquement en local ou aussi en production cloud ?

Les deux. En local, le transport stdio suffit pour un usage de développement. En production cloud ou self-hosted, il faut une URL publique en HTTPS, le transport SSE et un reverse proxy correctement configuré pour les connexions persistantes.

Comment sécuriser un serveur MCP n8n exposé sur internet ?

HTTPS obligatoire, authentification par Bearer Token ou Header Auth, exposition limitée aux seuls workflows nécessaires par projet, rotation et révocation des jetons, et audit régulier des exécutions déclenchées via l’historique de n8n.