FlowKit

MCP dans n8n : connecter un AI Agent à des outils externes avec le Model Context Protocol

Publié le 20 juillet 2026 · 6 min de lecture

Jusqu'ici, donner un outil à un AI Agent n8n signifiait le construire soi-même : un HTTP Request Tool pointé vers une API précise, un Code Tool pour une logique maison, ou un Workflow Tool pour réutiliser un workflow existant — la trilogie que détaille notre guide sur les outils personnalisés pour AI Agent. Le Model Context Protocol (MCP) change la donne dans les deux sens : il permet à un agent n8n de consommer, sans les recoder, les outils déjà exposés par un serveur MCP tiers — et il permet à n8n lui-même de devenir ce serveur, en publiant vos workflows comme des outils que Claude Desktop, Cursor ou tout autre client MCP peuvent appeler directement.

n8n propose deux nodes natifs pour ces deux usages : MCP Client Tool (consommer) et MCP Server Trigger (exposer). Ce guide couvre les deux, avec leurs paramètres réels et les pièges à éviter.

Le MCP en une minute

Le Model Context Protocol standardise la façon dont un modèle de langage découvre et appelle des outils externes. Avant le MCP, chaque intégration d'outil se codait au cas par cas — un connecteur GitHub différent d'un connecteur Notion, différent d'un connecteur interne. Un serveur MCP expose une liste d'outils avec leurs schémas d'entrée/sortie de façon standardisée ; n'importe quel client MCP (un agent n8n, Claude Desktop, un IDE comme Cursor) peut alors découvrir et appeler ces outils sans connaître les détails d'implémentation de chacun.

Pour un AI Agent n8n, cela veut dire une chose concrète : au lieu de construire un HTTP Request Tool par endpoint d'une API tierce qui en expose vingt, vous branchez un seul MCP Client Tool sur le serveur MCP de cette API, et l'agent découvre lui-même les outils disponibles.

MCP Client Tool : consommer un serveur MCP externe

Le node MCP Client Tool se branche sur la connexion ai_tool d'un AI Agent, exactement comme un toolHttpRequest ou un toolCode. Sa configuration tient en trois éléments :

L'endpoint et le transport

Le node se connecte à un serveur MCP via une URL d'endpoint. Le protocole MCP a évolué : le transport SSE (Server-Sent Events) historique est désormais déprécié au profit du transport HTTP Streamable, plus récent. SSE reste accepté pour la compatibilité avec d'anciens serveurs, mais toute nouvelle intégration devrait viser HTTP Streamable si le serveur MCP cible le propose.

L'authentification

Le MCP Client Tool gère plusieurs méthodes d'authentification vers le serveur distant :

  • None — connexion sans authentification, pour un serveur MCP interne ou de test ;
  • Bearer — un token unique envoyé en en-tête ;
  • Header Auth ou Multiple Headers — un ou plusieurs couples nom/valeur, utile quand le serveur exige par exemple une clé d'API et un identifiant client ;
  • OAuth2 — pour les serveurs MCP qui exposent un flux d'autorisation complet.

Ces identifiants se stockent dans un credential n8n dédié, avec la même isolation que les credentials des autres nodes.

Tools to Include : limiter la surface exposée à l'agent

C'est le paramètre le plus important pour la fiabilité en production. Un serveur MCP peut exposer des dizaines d'outils ; Tools to Include propose trois modes :

  • All — tous les outils du serveur sont visibles par l'agent ;
  • Selected — vous cochez explicitement les outils autorisés ;
  • All Except — tous les outils sauf ceux que vous excluez.

Le même principe que pour la description d'un HTTP Request Tool s'applique ici : plus la liste d'outils visibles par l'agent est large et ambiguë, plus le risque de mauvaise sélection augmente. Pour un agent de support connecté à un serveur MCP GitHub, par exemple, limiter la liste aux outils de lecture (recherche d'issues, lecture de PR) évite qu'il déclenche par erreur un outil de création ou de fermeture — le même réflexe de prudence que celui recommandé dans notre guide sur les outils personnalisés pour les appels HTTP en écriture.

MCP Server Trigger : exposer un workflow n8n comme outil MCP

Dans l'autre sens, le node MCP Server Trigger transforme un workflow n8n en serveur MCP consultable par un client externe. Concrètement, il fonctionne comme n'importe quel trigger n8n, avec deux particularités :

  • Une URL de test et une URL de production — la même logique que pour un webhook n8n classique : l'URL de test s'active pendant que vous construisez le workflow dans l'éditeur, l'URL de production s'active une fois le workflow publié.
  • Un chemin d'URL généré aléatoirement par défaut, pour éviter les collisions entre plusieurs MCP Server Trigger d'une même instance — mais que vous pouvez fixer manuellement si vous avez besoin d'une URL stable, par exemple pour la documenter dans une configuration partagée avec une équipe.

Une fois le workflow publié, un client MCP compatible — Claude Desktop, Cursor, ou un agent tiers — peut pointer vers cette URL de production pour découvrir et appeler les outils que le workflow expose.

Sécuriser un MCP Server Trigger

Un MCP Server Trigger publié est, par nature, un point d'entrée exposé publiquement — la même famille de risque qu'un webhook n8n classique. Les mêmes réflexes détaillés dans notre guide sur la sécurisation d'un webhook n8n s'appliquent : activer une authentification (Bearer token au minimum) plutôt que de laisser le endpoint ouvert, ne jamais coller l'URL de production dans un canal non chiffré ou un dépôt public, et limiter ce que le workflow exécute réellement derrière le trigger — un MCP Server Trigger qui déclenche une écriture en base doit valider ses entrées avec la même rigueur qu'une API publique classique, puisque n'importe quel client MCP mal configuré (ou mal intentionné) peut techniquement l'appeler.

Un cas concret : agent support connecté à un CRM via MCP, exposé lui-même en MCP

Prenons un scénario complet pour illustrer les deux nodes ensemble :

  1. Un agent de qualification des leads (comme celui décrit dans notre guide qualifier ses leads entrants avec l'IA) a besoin de vérifier l'historique d'un contact dans un CRM. Plutôt que de construire un HTTP Request Tool par endpoint du CRM, un MCP Client Tool pointe vers le serveur MCP que ce CRM expose nativement, avec Tools to Include limité aux outils de lecture (recherche de contact, historique des échanges).
  2. Ce même workflow, une fois fiabilisé, peut être exposé à son tour comme outil via un MCP Server Trigger — pour qu'un agent Claude Desktop utilisé en interne par l'équipe commerciale puisse déclencher une qualification de lead directement depuis sa conversation, sans ouvrir n8n.

Le résultat : n8n devient à la fois consommateur et fournisseur d'outils MCP, sans code supplémentaire au-delà de la configuration de ces deux nodes.

MCP, HTTP Request Tool ou Workflow Tool : lequel choisir ?

Le MCP ne remplace pas les outils existants, il ajoute une troisième option :

Situation Outil recommandé
Une API tierce que vous appelez vous-même, sans serveur MCP disponible HTTP Request Tool
Une logique métier propre à votre activité (calcul, validation, transformation) Code Tool
Réutiliser un workflow n8n existant, y compris un sous-agent spécialisé Workflow Tool
Un service tiers qui expose déjà un serveur MCP officiel MCP Client Tool
Rendre un workflow n8n appelable depuis Claude Desktop, Cursor ou un agent externe MCP Server Trigger

La bonne pratique consiste à vérifier d'abord si le service que vous voulez intégrer expose un serveur MCP officiel avant de reconstruire un HTTP Request Tool maison endpoint par endpoint : le MCP Client Tool évite la maintenance d'une intégration qui se désynchronise de l'API au premier changement côté fournisseur.

Pour aller plus loin

Si vous découvrez tout juste l'architecture en cluster nodes de n8n avant de vous attaquer au MCP, commencez par notre guide Débuter avec les nodes IA de n8n, qui pose les bases du node AI Agent, des chaînes et de la mémoire. Le Pack Inbox IA (79 €) et le Pack Conformité & Audit (149 €) utilisent tous deux la connexion ai_tool pour agir, pas seulement répondre — la logique exacte que le MCP Client Tool vient étendre à des outils tiers déjà standardisés. Si votre pile IA combine plusieurs de ces cas d'usage (tri d'emails, RAG documentaire, conformité), le Bundle FlowKit Complet (269 €) réunit les trois packs sur cette même base d'agents outillés.

FAQ

Questions fréquentes

Le MCP remplace-t-il le HTTP Request Tool ou le Code Tool dans n8n ?

Non, ils cohabitent. Le HTTP Request Tool et le Code Tool restent la solution la plus directe pour brancher une API que vous configurez vous-même. Le MCP Client Tool devient pertinent quand l’outil que vous voulez utiliser est déjà exposé par un serveur MCP tiers (GitHub, un outil interne, un service partenaire) : vous évitez de reconstruire manuellement chaque appel, et vous héritez automatiquement des nouveaux outils que ce serveur ajoute.

Faut-il une infrastructure particulière pour exposer un workflow n8n en serveur MCP ?

Non. Le node MCP Server Trigger fonctionne comme n’importe quel trigger n8n : une fois le workflow publié, il expose une URL de production que n8n héberge lui-même, en cloud comme en self-hosted. Aucun serveur MCP séparé à déployer ni à maintenir.

SSE ou HTTP Streamable, lequel choisir pour se connecter à un serveur MCP externe ?

Le transport HTTP Streamable est la norme actuelle du protocole MCP et remplace le SSE (Server-Sent Events), déprécié mais toujours accepté pour la compatibilité avec des serveurs plus anciens. Sauf contrainte du serveur MCP que vous consommez, préférez HTTP Streamable pour toute nouvelle connexion.

Peut-on limiter les outils exposés par un MCP Client Tool à l’agent ?

Oui, c’est même recommandé. Le paramètre « Tools to Include » propose trois modes : All (tous les outils du serveur), Selected (une sélection explicite) ou All Except (tout sauf certains outils exclus). Restreindre la liste réduit le risque qu’un agent appelle un outil non prévu et améliore la fiabilité de sélection, exactement comme pour un HTTP Request Tool mal décrit.

Bundle FlowKit Complet

269 €