Avant un rendez-vous, une responsable commerciale voudrait demander à Claude où en est le dossier d'un client et s'il a réglé sa dernière facture. Les réponses sont dans le CRM et dans l'outil de facturation. Le plus rapide serait de brancher l'assistant sur ces outils avec un compte qui voit tout et peut tout modifier. Personne n'a envie d'accorder ce niveau d'accès, surtout sur la facturation.
Une voie intermédiaire consiste à exposer à Claude quelques workflows n8n, chacun limité à une action précise : retrouver une fiche client, donner le statut d'une facture. L'assistant voit ces outils, jamais le CRM entier. Les identifiants restent dans n8n, et chaque appel laisse une trace dans l'historique des exécutions.
Voici comment fonctionne un serveur MCP n8n construit avec le noeud MCP Server Trigger, quelles actions exposer en premier, lesquelles garder hors de portée, et comment l'exploiter sur une instance auto-hébergée.
Qu'est-ce qu'un serveur MCP n8n
Selon sa documentation officielle, le Model Context Protocol (MCP) est un standard open source pour connecter des applications d'IA comme Claude à des systèmes externes. La spécification décrit ce qu'un serveur peut proposer à un client : des ressources, des modèles de prompts et des outils, c'est-à-dire des fonctions que le modèle peut exécuter.
Le noeud MCP Server Trigger fait de n8n un serveur MCP. Il expose une URL que les clients MCP appellent. Contrairement aux autres déclencheurs, il ne se connecte qu'à des noeuds outils, qu'il exécute.
Pour transformer un workflow existant en outil, on le rattache au déclencheur avec le noeud Custom n8n Workflow Tool, aujourd'hui documenté sous le nom Call n8n Workflow Tool. Le schéma : Claude appelle l'URL MCP de n8n, n8n lance le sous-workflow "chercher une fiche client", le sous-workflow interroge le CRM avec ses propres identifiants et renvoie quelques champs.
Pourquoi passer par n8n plutôt que brancher chaque outil
Des actions précises plutôt qu'un accès complet. Un accès direct donne à l'assistant tout ce que permet le compte connecté. Un outil n8n ne fait que ce que son workflow prévoit.
Les identifiants restent dans n8n, et chaque appel est tracé. Claude s'authentifie auprès de n8n, n8n auprès du CRM, et chaque appel devient une exécution consultable dans l'onglet Executions. Les bonnes pratiques de sécurité MCP décrivent le "token passthrough", le fait de relayer vers une API un jeton qui n'a pas été émis pour le serveur MCP, comme un anti-modèle interdit par la spécification d'autorisation de MCP. Ici, le jeton de Claude n'ouvre que n8n.
La réutilisation. Un workflow existant, comme celui de l'article sur Plaud, n8n et MCP, devient un outil sans réécriture. Sur le partage des rôles, voir aussi n8n et Claude Code : les faire travailler ensemble.
Quelles actions exposer à Claude, et lesquelles garder à distance
Je recommande d'avancer par niveaux, en relisant les journaux avant chaque passage.
| Niveau | Exemples | Règle |
|---|---|---|
| Lecture ciblée | Fiche client, statut d'une facture, état d'une commande | Peu de champs renvoyés, nombre de résultats plafonné |
| Écriture réversible | Ajouter une note au CRM, créer une tâche, préparer un brouillon | Chaque écriture marquée comme venant de l'assistant |
| Action avec validation | Envoyer un devis, modifier une échéance, relancer un client | L'outil crée une demande, une personne approuve |
| Hors périmètre | Paiements, virements, changement de RIB, suppressions, envois en masse, gestion des droits, export complet | Aucun outil MCP |
Pour le troisième niveau, je déconseille de faire attendre l'appel MCP pendant la décision humaine. L'outil enregistre la demande et répond "demande créée, en attente de validation", puis un workflow séparé obtient l'accord du responsable avant d'agir. Voir l'article sur la validation humaine des agents IA.
Attention aussi aux outils qui lisent du texte venu de l'extérieur (emails, notes de réunion) : il peut contenir des instructions cachées. Ne placez pas un tel outil sur le même serveur qu'un outil qui envoie quelque chose hors de l'entreprise.
Configurer le MCP Server Trigger dans n8n
Le chemin. Le noeud génère par défaut un chemin d'URL aléatoire, qui ne remplace pas l'authentification.
Les deux URL. La documentation distingue l'URL de test, active quand on écoute un événement de test dans l'éditeur, et l'URL de production, enregistrée à la publication du workflow. Ne donnez jamais l'URL de test aux utilisateurs.
Un sous-workflow publié par outil. Avec la source "Database", le sous-workflow appelé doit être publié pour les exécutions en production (le panneau de test n'est pas concerné). Sinon, selon la documentation du noeud, l'appel en production échoue avec l'erreur Workflow is not active and cannot be executed, renvoyée au modèle comme résultat de l'outil. L'utilisateur lit seulement que l'assistant n'a pas trouvé l'information.
La description. Le champ Description indique au modèle quand utiliser l'outil. Elle dit ce que fait l'outil, ce qu'il attend et ce qu'il ne fait pas : "Retrouve la fiche d'un client à partir de son nom ou de son SIREN. Renvoie le nom, le contact principal et le statut. Ne modifie rien."
Les paramètres. Les entrées du sous-workflow peuvent être fixées, calculées par une expression ou laissées au modèle, notamment avec la fonction $fromAI(). Fixez tout ce que le modèle n'a pas à choisir (pipeline, nombre maximum de résultats) et laissez-lui seulement le terme de recherche. Le sous-workflow contrôle ensuite les valeurs reçues.
Les instructions du serveur. Ce champ facultatif, envoyé aux clients à la connexion, est en général ajouté au prompt système par ceux qui le prennent en charge. Il guide le modèle mais ne protège rien : une restriction réelle se place dans le workflow ou dans les droits.
Authentification et droits d'accès
Le noeud propose quatre options :
| Option | Ce qu'elle permet | Usage conseillé |
|---|---|---|
| None | Aucun contrôle | Jamais sur une URL de production |
| Bearer auth | Un jeton partagé dans l'en-tête Authorization | Un petit groupe, un jeton par serveur |
| Header auth | Un en-tête personnalisé | Même logique que le bearer |
| n8n User Auth (OAuth2) | Chaque appelant se connecte avec son compte n8n et donne son accord | Équipes plus larges, un accès par personne |
Avec un jeton bearer ou header, quiconque possède le jeton accède à tous les outils du serveur, sans être identifié.
L'option n8n User Auth (OAuth2) est disponible à partir de la version 2 du noeud. Elle ajoute trois réglages. Require Workflow Execute Permission, activé par défaut, exige que l'utilisateur ait le droit d'exécuter le workflow dans son projet. Trusted Source Name or ID désigne le fournisseur d'identité dont les jetons sont acceptés. Include User in Output, à partir de la version 2.1, transmet l'identifiant, l'email et le nom de l'appelant dans la sortie du déclencheur et dans la requête reçue par les outils connectés.
La documentation ne dit pas que ces données arrivent jusqu'à un sous-workflow appelé par Call n8n Workflow Tool, qui reçoit ses entrées définies. Si un sous-workflow doit filtrer selon la personne ou journaliser son nom, prévoyez-le explicitement, par exemple avec un champ utilisateur parmi ses entrées. Vérifiez ensuite que ce champ contient bien l'appelant et que le modèle ne peut pas le remplir.
Je recommande aussi un serveur par population, par exemple un pour l'équipe commerciale et un pour la comptabilité, plutôt qu'un serveur unique qui expose tout à tout le monde.
Connecter Claude Desktop et claude.ai
Le MCP Server Trigger accepte deux transports, Server-Sent Events (SSE) et streamable HTTP, mais pas l'entrée/sortie standard (stdio).
Claude Desktop. La documentation n8n propose de passer par une passerelle, mcp-remote, lancée avec npx, qui relaie les messages SSE vers le format stdio. La configuration de Claude Desktop ressemble à ceci :
{
"mcpServers": {
"n8n": {
"command": "npx",
"args": ["mcp-remote", "<MCP_URL>", "--header", "Authorization: Bearer ${AUTH_TOKEN}"],
"env": { "AUTH_TOKEN": "<MCP_BEARER_TOKEN>" }
}
}
}
Le jeton est alors stocké sur chaque poste. Notez qui en possède un, et changez-le au départ d'un collaborateur.
claude.ai. Selon la documentation n8n, les connecteurs personnalisés de claude.ai demandent de se connecter à n8n même avec l'authentification réglée sur None : l'instance propose l'authentification utilisateur n8n pour d'autres déclencheurs, et claude.ai suppose que tous les points d'accès MCP du domaine l'utilisent. J'en déduis (c'est une inférence, la documentation ne le dit pas) que n8n User Auth est l'option la plus cohérente avec claude.ai. Elle suppose un compte n8n par utilisateur : vérifiez ce que votre édition et votre licence n8n prévoient pour plusieurs utilisateurs.
Autre conséquence, selon l'aide de Claude, Claude joint les connecteurs personnalisés depuis l'infrastructure cloud d'Anthropic, pas depuis le poste de l'utilisateur. Le serveur doit être joignable sur l'internet public depuis les adresses IP d'Anthropic ; derrière un VPN ou sur un réseau privé, il ne se connectera pas. Une instance auto-hébergée doit donc être exposée sur internet. Je recommande alors HTTPS, une authentification sur chaque URL MCP et, si claude.ai est le seul client, un filtrage sur les adresses d'Anthropic. La même page précise les conditions d'accès selon l'offre Claude.
Le consentement. La spécification MCP (version 2026-07-28) demande aux applications hôtes d'obtenir le consentement explicite de l'utilisateur avant d'invoquer un outil. Des descriptions claires et une courte formation des équipes aident chacun à comprendre ce qu'il autorise.
Enfin, ce que renvoie un outil part chez le fournisseur du modèle : renvoyez le minimum de champs. Pour choisir un modèle selon la sensibilité des données, voir modèle d'IA ouvert ou propriétaire.
Faire tourner un serveur MCP n8n en production
Le reverse proxy. SSE et streamable HTTP reposent sur des connexions persistantes. Derrière nginx, la documentation demande de désactiver le buffering du proxy pour le point d'accès MCP, ainsi que la compression gzip (n8n s'en charge) et le chunked transfer encoding, et de vider l'en-tête Connection :
location /mcp/ {
proxy_http_version 1.1;
proxy_buffering off;
gzip off;
chunked_transfer_encoding off;
proxy_set_header Connection '';
}
Pour une installation sur Hetzner et Coolify, voir l'article sur la stack self-hosted.
Le mode queue. Avec plusieurs webhook replicas, toutes les requêtes /mcp* doivent aller vers un replica unique et dédié. Sinon, prévient la documentation, les connexions se coupent souvent ou livrent mal les événements.
Les journaux. Pour la revue hebdomadaire, chaque outil peut écrire dans une table : date, outil, paramètres, nombre de résultats, et l'utilisateur si vous l'avez transmis au sous-workflow. Vérifiez la durée de conservation des exécutions, qui contiennent des données clients.
Les alertes. Définissez un workflow d'erreur sur chaque sous-workflow, et transformez les anomalies métier en erreurs avec Stop and Error, comme décrit dans l'article sur la gestion des erreurs n8n. Une erreur renvoyée au modèle sous forme de texte ne prévient personne. Après chaque mise à jour de n8n, testez la connexion de Claude et un appel de chaque outil.
Checklist avant lancement
- La liste des outils est écrite, et le premier lot ne contient que de la lecture.
- Aucun outil ne paie, ne supprime, n'envoie en masse ni ne modifie des droits.
- Chaque sous-workflow a des identifiants dédiés aux droits minimum, et contrôle ses entrées.
- L'URL de production est protégée par une authentification, jamais None.
- Un workflow d'erreur prévient quelqu'un quand un outil échoue.
- Le reverse proxy et le routage des replicas sont configurés pour
/mcp*. - Un responsable, avec un suppléant, relit les journaux chaque semaine.
Commencer petit
Commencez par deux ou trois outils en lecture, ouverts à quelques personnes. Relisez les journaux pendant quelques semaines (appels en échec, données sorties), puis élargissez outil par outil. Chez Kirako, nous concevons des automatisations avec n8n et des agents IA, dont ce type de serveur MCP.
Sources
Consultées le 9 novembre 2026 : documentation n8n (MCP Server Trigger, Call n8n Workflow Tool), Model Context Protocol (introduction, spécification, version 2026-07-28, bonnes pratiques de sécurité), aide Claude (connecteurs personnalisés avec MCP distant).
Existe aussi : Lire en anglais