n8n et MCP : brancher vos workflows sur un LLM local

#n8n et MCP : deux nœuds, deux sens de circulation

Le Model Context Protocol (MCP) est un protocole ouvert qui décrit comment une application d'IA découvre et appelle des outils fournis par un serveur. Si la notion vous est nouvelle, le guide « MCP : c'est quoi ? » pose les bases ; ici, on suppose acquis le vocabulaire client, serveur et outil.

Dans n8n, MCP apparaît sous la forme de deux nœuds de la famille IA (paquet n8n-nodes-langchain). Ils répondent à deux besoins opposés, et l'on confond facilement les deux en lisant les tutoriels.

MCP Server Trigger : n8n devient serveur

Le nœud publie une URL MCP. Chaque outil que vous lui rattachez (un sous-workflow, une requête HTTP, un outil intégré) devient un outil MCP qu'un client externe peut lister et appeler. Usage typique : donner à votre assistant local l'accès à « créer un ticket », « chercher dans le CRM » ou « envoyer un récapitulatif », sans lui donner vos identifiants.

MCP Client Tool : n8n devient client

Le nœud se branche comme un outil sous un nœud AI Agent. Il se connecte à un serveur MCP existant, récupère sa liste d'outils et les met à disposition de l'agent. Usage typique : un workflow planifié dont l'agent lit des fichiers, interroge une base ou fouille une documentation via un serveur MCP déjà en place.

Ce que MCP ne change pas

Le choix du modèle reste indépendant. L'agent n8n peut tourner sur Ollama ; le client qui appelle votre MCP Server Trigger peut, lui aussi, utiliser un modèle local. MCP ne transporte que la description des outils et leurs appels, pas le modèle.

Les deux nœuds peuvent coexister dans la même instance : un workflow « serveur » qui expose quelques actions métier, et un workflow « agent » qui consomme un ou plusieurs serveurs MCP. Rien n'empêche même un agent n8n d'appeler le MCP Server Trigger d'un autre workflow de la même instance, ce qui revient à découper un gros agent en briques réutilisables.

#Prérequis

Une instance n8n récente

Auto-hébergée, de préférence avec Docker. Les nœuds MCP sont apparus en 2025 et ont évolué depuis (transports, options d'authentification) : mettez n8n à jour et fiez-vous à ce qu'affiche votre éditeur. L'installation elle-même est détaillée dans le guide n8n avec Docker.

Ollama joignable depuis n8n

Ollama écoute par défaut sur http://localhost:11434. Si n8n tourne dans un conteneur, localhost désigne le conteneur, pas votre machine : il faudra une autre adresse (voir étape 1).

Un modèle qui gère l'appel d'outils

Un agent n'est utile que si le modèle sait produire des appels d'outils structurés. Choisissez un modèle dont la fiche Ollama affiche la capacité tools, par exemple de la famille Qwen3. En Q4_K_M, un 8B tient dans environ 5 Go de VRAM et un 14B dans environ 9 Go, ce qui reste confortable sur une RTX 3060 12 Go ou une RTX 4070 12 Go.

Pour l'étape 2

Un serveur MCP accessible en HTTP. Les serveurs lancés uniquement en local via stdio (une commande npx ou uvx) ne sont pas joignables tels quels par n8n : il faut un serveur qui écoute sur une URL.

Pour l'étape 4

Un client MCP capable de parler à un serveur distant : LM Studio, Open WebUI, Claude Desktop via une passerelle, ou l'inspecteur officiel du protocole pour tester.

#Étape 1 : un agent n8n branché sur un modèle local

Les deux sens de MCP passent par un agent, côté n8n ou côté client. Commencez donc par vérifier que n8n sait parler à votre modèle local. La connexion de base est couverte en détail dans le guide n8n + Ollama ; voici le strict nécessaire.

# Télécharger un modèle compatible avec l'appel d'outils
ollama pull qwen3:8b

# Vérifier qu'Ollama répond et liste le modèle
curl http://localhost:11434/api/tags

Si n8n tourne dans Docker et Ollama directement sur l'hôte, ajoutez au service n8n une entrée qui fait pointer host.docker.internal vers la machine hôte. Sous Docker Desktop (macOS, Windows), ce nom existe déjà ; sous Linux, il faut le déclarer.

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    extra_hosts:
      - "host.docker.internal:host-gateway"

Sous Linux, Ollama n'écoute par défaut que sur 127.0.0.1 : un conteneur ne le joindra pas via host-gateway tant que vous n'avez pas défini OLLAMA_HOST=0.0.0.0 dans le service Ollama. Si les deux tournent dans le même fichier Compose, utilisez plutôt le nom du service, par exemple http://ollama:11434.

1. 01
   Créer l'agent

   Dans un nouveau workflow, ajoutez un déclencheur Chat Trigger (pratique pour tester), puis un nœud AI Agent.
2. 02
   Brancher le modèle

   Sur l'entrée Chat Model de l'agent, ajoutez Ollama Chat Model. Créez l'identifiant Ollama avec l'URL de base http://host.docker.internal:11434 (ou http://localhost:11434 si n8n n'est pas conteneurisé), puis sélectionnez qwen3:8b.
3. 03
   Tester sans outil

   Ouvrez le chat du workflow et posez une question simple. Une réponse confirme la liaison n8n vers Ollama ; le reste du guide ajoute des outils par-dessus.

#Étape 2 : consommer un serveur MCP depuis un agent n8n

Le nœud MCP Client Tool se rattache à l'entrée Tool de l'AI Agent, comme n'importe quel outil. À l'exécution, il interroge le serveur MCP, récupère la liste des outils avec leur description et leur schéma de paramètres, et les présente au modèle. C'est le modèle qui décide d'appeler tel outil avec tels arguments ; n8n se charge de relayer l'appel et de renvoyer le résultat.

1. 01
   Ajouter le nœud

   Sous l'agent créé à l'étape 1, cliquez sur le + de l'entrée Tool et choisissez MCP Client Tool.
2. 02
   Renseigner le point d'accès

   Collez l'URL du serveur MCP et choisissez le transport proposé par ce serveur. La documentation n8n cite le flux HTTP (streamable HTTP), transport actuel du protocole, et les Server-Sent Events (SSE), plus anciens et encore servis par certains serveurs. Si le serveur documente une URL se terminant par /sse, c'est généralement du SSE ; sinon, essayez le HTTP.
3. 03
   Choisir l'authentification

   Aucune, Bearer (un jeton envoyé dans l'en-tête Authorization) ou un en-tête personnalisé, selon ce qu'exige le serveur. Les options exactes dépendent de votre version de n8n ; le jeton est stocké comme un identifiant n8n, pas en clair dans le workflow.
4. 04
   Filtrer les outils

   Le paramètre Tools to Include propose All, Selected ou All Except. Préférez Selected : un modèle local de 8B choisit mieux parmi trois outils bien décrits que parmi trente, et vous limitez ce que l'agent peut déclencher.
5. 05
   Tester

   Demandez dans le chat une action qui nécessite l'outil. Dans le journal d'exécution de l'agent, vous voyez l'outil appelé, les arguments générés par le modèle et la réponse du serveur.

Rappel pratique : n8n doit pouvoir joindre le serveur MCP. Un serveur lancé sur votre poste à l'adresse localhost:3000 n'est pas visible depuis le conteneur n8n ; la même règle host.docker.internal ou nom de service Docker s'applique.

#Étape 3 : exposer vos workflows avec le MCP Server Trigger

C'est le sens le plus demandé derrière la recherche « n8n mcp » : transformer des automatisations existantes en outils qu'un assistant peut appeler. Le MCP Server Trigger se distingue des déclencheurs classiques : il ne lance pas une suite de nœuds, il ne se connecte qu'à des nœuds outils et les publie.

1. 01
   Créer le workflow serveur

   Nouveau workflow, ajoutez le nœud MCP Server Trigger. Il affiche une URL de test et une URL de production, ainsi qu'un champ Path qui détermine la fin de l'URL. Remplacez l'identifiant aléatoire par un chemin lisible si vous le souhaitez, mais gardez-le difficile à deviner.
2. 02
   Rattacher des outils

   Cliquez sur l'entrée Tool du trigger et ajoutez des outils. Le plus utile est l'outil qui appelle un autre workflow n8n (Call n8n Workflow Tool) : votre automatisation existante devient un outil MCP. Vous pouvez aussi rattacher HTTP Request Tool ou des outils d'intégration fournis par n8n.
3. 03
   Soigner nom et description

   Le client ne voit que le nom de l'outil, sa description et le schéma de ses paramètres. C'est ce texte que le modèle lit pour décider d'un appel. Écrivez une description explicite, en une ou deux phrases : ce que fait l'outil, les paramètres attendus, ce qu'il renvoie.
4. 04
   Définir les paramètres du sous-workflow

   Dans le workflow appelé, déclarez les champs d'entrée attendus (par exemple titre et priorité d'un ticket). Le client MCP recevra ce schéma et le modèle remplira les valeurs.
5. 05
   Tester puis activer

   L'URL de test ne répond que pendant que l'éditeur écoute un événement de test ; les exécutions s'affichent alors dans le canevas. L'URL de production ne fonctionne qu'une fois le workflow activé. Gardez l'URL de test pour le réglage et donnez l'URL de production à vos clients.

Test        : https://n8n.mondomaine.lan/mcp-test/<chemin>
Production  : https://n8n.mondomaine.lan/mcp/<chemin>

L'adresse de base reprend celle que n8n utilise pour ses webhooks. Si n8n affiche localhost:5678 alors que vous y accédez par un autre nom, corrigez la variable WEBHOOK_URL de l'instance : c'est elle qui détermine l'URL affichée dans le nœud.

#Étape 4 : brancher un client MCP local sur n8n

Il reste à faire appeler ces outils par un assistant qui tourne, lui aussi, sur un modèle local. Avant tout client « intelligent », vérifiez le serveur avec l'inspecteur officiel du protocole : il liste les outils exposés et permet de les appeler à la main, sans modèle dans la boucle.

# Lance l'inspecteur MCP dans le navigateur (nécessite Node.js)
npx @modelcontextprotocol/inspector

Dans l'interface, choisissez le transport correspondant, collez l'URL de production, ajoutez l'en-tête Authorization si vous avez activé l'authentification, puis listez les outils. Si vos outils n8n apparaissent avec leur description, le serveur est prêt.

#LM Studio et les clients qui acceptent une URL

Les clients récents acceptent directement un serveur MCP distant décrit par une URL. LM Studio, par exemple, lit un fichier mcp.json au format mcpServers ; une entrée distante prend la forme ci-dessous. Vérifiez dans la documentation de votre client le nom exact des champs, qui peut varier d'un logiciel à l'autre.

{
  "mcpServers": {
    "n8n": {
      "url": "https://n8n.mondomaine.lan/mcp/<chemin>",
      "headers": {
        "Authorization": "Bearer <votre-jeton>"
      }
    }
  }
}

#Les clients limités à stdio : passer par une passerelle

Certains clients ne savent lancer que des serveurs locaux en stdio. La documentation n8n décrit pour ce cas l'utilisation de la passerelle mcp-remote, qui se lance comme un serveur stdio et relaie les appels vers l'URL de n8n. Le jeton est passé via une variable d'environnement plutôt qu'en dur dans les arguments.

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://n8n.mondomaine.lan/mcp/<chemin>",
        "--header",
        "Authorization: Bearer ${AUTH_TOKEN}"
      ],
      "env": {
        "AUTH_TOKEN": "<votre-jeton>"
      }
    }
  }
}

Côté modèle, les mêmes règles qu'à l'étape 2 s'appliquent : chargez dans votre client un modèle qui gère l'appel d'outils, gardez peu d'outils visibles et testez d'abord avec une demande sans ambiguïté. Le guide MCP et LLM local détaille la configuration côté client pour Ollama et ses interfaces.

#Sécuriser les points d'accès MCP de n8n

Une URL MCP Server Trigger est un point d'entrée qui déclenche vos workflows avec les identifiants enregistrés dans n8n. Quiconque la connaît, sans authentification, peut créer vos tickets ou lire votre CRM. Traitez-la comme une clé d'API.

Activer l'authentification

Le nœud propose une authentification par jeton Bearer ou par en-tête. Activez-la systématiquement, même sur un réseau local. Générez un jeton long et aléatoire, par exemple avec la commande openssl ci-dessous, et un jeton différent par client pour pouvoir en révoquer un seul.

Ne pas exposer n8n sur Internet sans raison

Pour un usage personnel ou en petite équipe, gardez n8n sur le réseau local ou derrière un VPN (WireGuard, Tailscale). Si l'exposition est nécessaire, passez par un proxy inverse en HTTPS, avec filtrage d'IP si possible.

Limiter ce que chaque outil peut faire

Un outil MCP doit faire une chose précise avec des paramètres bornés. Évitez d'exposer un outil générique « exécuter une requête SQL » ou « appeler une URL quelconque » : un modèle qui se trompe, ou un contenu malveillant lu par l'agent, peut le détourner.

Se méfier de l'injection de prompt

Si l'agent lit des contenus externes (e-mails, pages web, documents) et dispose d'outils qui agissent, un texte piégé peut lui ordonner d'appeler un outil. Séparez les outils de lecture et d'action, et ajoutez une validation humaine (nœud d'attente ou d'approbation) avant toute action irréversible.

Auditer côté serveur MCP tiers

Dans le sens client, n'ajoutez à un agent que des serveurs MCP dont vous connaissez l'éditeur et le code. Les descriptions d'outils fournies par le serveur entrent directement dans le contexte du modèle.

Surveiller les exécutions

Chaque appel d'outil produit une exécution dans n8n. Consultez régulièrement l'historique du workflow serveur : c'est votre journal d'audit.

# Générer un jeton aléatoire de 64 caractères hexadécimaux
openssl rand -hex 32

Si un proxy inverse se trouve devant n8n, il doit laisser passer une réponse en flux continu. La documentation n8n donne un exemple nginx qui désactive la mise en tampon pour les chemins MCP ; l'extrait ci-dessous reprend ces directives, à adapter à votre configuration et à compléter par le chemin /mcp-test/ si vous testez à travers le proxy.

location /mcp/ {
    proxy_pass http://127.0.0.1:5678;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    proxy_cache off;
    chunked_transfer_encoding off;
    gzip off;
}

#Dépannage n8n MCP : les blocages fréquents

Le client ne voit aucun outil

Vérifiez que des outils sont bien rattachés à l'entrée Tool du MCP Server Trigger, que vous utilisez l'URL de production avec un workflow activé, ou l'URL de test pendant que l'éditeur écoute.

Erreur 401 ou 403

Le jeton ne correspond pas, ou le client n'envoie pas l'en-tête. Testez avec l'inspecteur MCP, qui montre exactement les en-têtes envoyés. Attention à l'espace après « Bearer ».

Connexion qui coupe ou reste bloquée

Presque toujours un proxy qui met en tampon le flux, ou un mauvais transport choisi côté client (SSE contre HTTP). Testez en direct sur le port 5678 pour isoler le proxy.

L'URL affichée contient localhost

La variable WEBHOOK_URL de n8n n'est pas définie : l'URL ne sera pas joignable depuis une autre machine. Définissez-la avec l'adresse publique ou réseau de l'instance, puis redémarrez n8n.

ECONNREFUSED vers Ollama

n8n en conteneur cherche Ollama dans le conteneur. Utilisez host.docker.internal ou le nom du service Docker, et vérifiez qu'Ollama écoute sur une interface accessible.

Le modèle n'appelle jamais l'outil

Modèle sans support des outils, description d'outil trop vague ou trop d'outils exposés. Passez à un modèle marqué tools, réécrivez la description et réduisez la sélection.

Le modèle invente des paramètres

Le schéma du sous-workflow est trop libre. Déclarez des champs typés et décrivez les valeurs attendues ; validez les entrées dans le workflow avant toute action.

#Pour aller plus loin

Ce guide couvre MCP dans n8n. Pour les bases du protocole, la configuration des clients MCP côté Ollama ou la connexion de n8n à un modèle local, ces guides prennent le relais.