Depuis novembre 2024, les téléchargements du SDK MCP sont passés de 100 000 à plus de 97 millions par mois (MCP Anniversary Report, novembre 2025). Stripe, GitHub, Notion, AWS, Google Cloud ont tous déployé leurs propres serveurs MCP en moins d'un an. Ce n'est pas une mode : c'est le protocole qui est en train de devenir le standard de connexion entre les agents IA et les outils du monde réel.
n8n est la plateforme qui en tire le mieux parti. Pas parce qu'elle supporte MCP - beaucoup d'outils le font désormais - mais parce qu'elle joue les deux rôles à la fois. n8n peut être un serveur MCP (Claude pilote vos workflows) et un client MCP (vos agents n8n consomment des outils externes). Cette double position change ce qu'on peut construire.
MCP en pratique : pas un plugin, un protocole
La plupart des explications sur MCP partent de la théorie. Voici l'essentiel en termes concrets.
Avant MCP, connecter un agent IA à un outil métier demandait d'écrire une intégration spécifique pour chaque combinaison outil-agent. Claude + Notion ? Un code. GPT-4 + Notion ? Un autre code. Cursor + vos workflows n8n ? Encore un code. Le résultat : des centaines d'intégrations non standardisées, impossibles à maintenir à l'échelle.
MCP règle ça avec une interface unique. Un outil qui expose un serveur MCP devient accessible à n'importe quel agent compatible, quelle que soit son origine. Claude, Cursor, Windsurf, vos propres agents n8n : ils parlent tous le même langage. Construisez l'outil une fois, il fonctionne partout.
La structure est simple. Un serveur MCP expose des "tools" - des fonctions que l'agent peut appeler - et optionnellement des "resources" - des données accessibles en lecture. L'agent choisit quel outil appeler, avec quels paramètres, et reçoit le résultat. Pas de scraping, pas d'API custom : un protocole JSON standardisé sur HTTP ou stdio.
n8n comme serveur MCP : laisser Claude piloter vos workflows
Premier cas d'usage : vous avez des workflows n8n existants et vous voulez qu'un agent externe puisse les déclencher.
n8n expose nativement un serveur MCP depuis la version 1.68. La configuration prend 10 minutes. Vous créez un workflow avec le noeud MCP Server Trigger, vous lui associez les workflows à exposer via un tag (par exemple "mcp"), et n8n génère automatiquement une URL MCP que vous collez dans la config de votre client IA.
Ce qui se passe côté agent : Claude demande la liste des outils disponibles, reçoit les descriptions de vos workflows (nom, paramètres attendus, description), et peut les appeler au bon moment dans une conversation. Si vous lui dites "crée une proposition commerciale pour Acme Corp", il peut déclencher votre workflow de génération de docs sans que vous ayez rien à programmer côté Claude.
La clé est la description des workflows exposés. Le nom doit être explicite, la description doit expliquer ce que le workflow fait et dans quel contexte l'appeler. Un workflow nommé "create_proposal" avec la description "Génère une proposition commerciale PDF à partir d'un nom de client et d'un montant estimé" sera appelé au bon moment. Un workflow nommé "wf_015" ne le sera jamais.
Recommandation pratique : limitez le nombre de workflows exposés. 5 à 10 outils max par serveur MCP. Au-delà, les agents se perdent dans le choix et la qualité des appels chute. Mieux vaut exposer moins mais avec des descriptions précises.
n8n comme client MCP : consommer des outils externes dans vos agents
Deuxième cas d'usage, souvent oublié : vos agents n8n qui consomment des outils MCP exposés par d'autres systèmes.
Aujourd'hui, le registre MCP compte près de 2 000 serveurs répertoriés (MCP Anniversary Report). Stripe, GitHub, Linear, Notion, Brave Search, Google Maps - tous exposent désormais des serveurs MCP. Votre agent n8n peut les appeler directement via le noeud MCP Client Tool.
Concrètement : vous créez un AI Agent node dans n8n, vous lui attachez un ou plusieurs MCP Client Tool nodes en sous-noeuds, chacun pointant vers un serveur MCP externe. L'agent décide lui-même quand appeler quel outil selon l'instruction reçue.
Exemple réel : un agent de support client qui reçoit un ticket Zendesk peut - via MCP - interroger Linear pour voir si le bug est déjà signalé, créer une issue si elle n'existe pas, et répondre au client avec le numéro de ticket. Trois outils différents, zéro code d'intégration custom.
L'avantage par rapport aux intégrations native n8n ? Les outils MCP se découvrent dynamiquement. Quand Stripe met à jour ses capacités MCP, votre agent en bénéficie automatiquement sans redéploiement. Les intégrations natives doivent être maintenues manuellement à chaque changement d'API.
Configuration concrète : les étapes
Voici le chemin minimal pour exposer vos workflows n8n via MCP et les connecter à Claude Desktop.
Étape 1 - Préparer vos workflows : taguez chaque workflow à exposer avec le tag "mcp". Ajoutez un noeud Subworkflow Trigger en entrée avec un schéma d'entrée défini (les paramètres que l'agent peut passer). Décrivez clairement ce que fait chaque workflow dans le champ description.
Étape 2 - Créer le workflow serveur MCP : créez un nouveau workflow avec le noeud MCP Server Trigger. Configurez-le pour découvrir dynamiquement les workflows taggés "mcp". Activez le workflow en mode production (pas test - le serveur MCP doit être disponible en permanence).
Étape 3 - Récupérer l'URL MCP : n8n génère une URL de type https://votre-instance.n8n.cloud/mcp/webhook/... avec votre clé d'authentification. Notez aussi le type de transport : HTTP (pour les clients distants) ou stdio (pour les clients locaux comme Claude Desktop).
Étape 4 - Configurer Claude Desktop : éditez ~/.claude/claude_desktop_config.json, ajoutez votre serveur n8n dans la section mcpServers avec l'URL et les headers d'auth. Relancez Claude Desktop. Vos workflows apparaissent dans la liste des outils disponibles.
Étape 5 - Tester avec une vraie instruction : demandez à Claude d'utiliser un de vos workflows sans mentionner son nom. S'il l'appelle spontanément au bon moment, la description est correcte. S'il faut le nommer explicitement, retravailler la description.
Deux pièges à éviter
Le premier piège : exposer des workflows qui modifient des données critiques sans confirmation humaine. MCP permet à un agent d'appeler vos workflows de façon autonome. Un agent mal instruit peut déclencher un workflow de suppression, d'envoi d'email en masse, ou de modification de base de données sans vous demander. Ajoutez systématiquement une étape de confirmation dans les workflows destructifs, ou ne les exposez pas du tout via MCP.
Le deuxième : ignorer l'authentification. Le serveur MCP n8n est accessible via HTTP avec une URL. Sans protection, n'importe qui qui connaît l'URL peut déclencher vos workflows. n8n supporte l'auth par header Bearer token. Utilisez-la, et ne partagez jamais l'URL en clair dans votre config versionnée.
Ce que ça change vraiment
Avant MCP, construire un assistant IA connecté à vos outils internes demandait de choisir : soit vous utilisiez un agent externe (Claude, GPT) mais l'intégration à vos systèmes était compliquée, soit vous utilisiez vos workflows n8n mais le raisonnement LLM était limité.
Avec n8n + MCP, les deux se combinent sans friction. Votre agent Claude Desktop a accès à vos automatisations n8n. Vos agents n8n ont accès aux outils MCP de l'écosystème. La frontière entre "agent IA" et "workflow automatisé" disparaît - et c'est exactement l'objectif.
Les équipes qui ont adopté cette architecture en 2025 ont réduit le temps de maintenance de leurs intégrations de 30 à 60% par rapport aux solutions custom précédentes (Pento, A Year of MCP Review). Pas parce que MCP est magique, mais parce qu'il standardise ce qui était jusqu'alors du code artisanal différent pour chaque connexion.
Si vous partez de zéro sur n8n, commencez par installer n8n avec Docker avant de passer à MCP. Si vous avez déjà des workflows, le guide sur les agents n8n vous donnera le contexte nécessaire pour bien structurer les outils à exposer.
Questions fréquentes
MCP fonctionne-t-il avec n8n Cloud ou seulement en self-hosted ?
Les deux. n8n Cloud supporte le MCP Server depuis la version 1.68. En self-hosted, aucune configuration supplémentaire n'est nécessaire au-delà de l'exposition du port HTTP. La différence principale : en cloud, l'URL est publique par défaut (pensez à protéger avec un token). En self-hosted derrière un reverse proxy, vous contrôlez l'exposition réseau.
Peut-on limiter ce qu'un agent externe peut faire via MCP ?
Oui, et c'est recommandé. Le contrôle se fait à deux niveaux : au niveau du tag "mcp" (seuls les workflows explicitement taggés sont exposés) et au niveau du schéma d'entrée de chaque Subworkflow Trigger (vous définissez précisément les paramètres acceptés). Un agent ne peut appeler que ce que vous avez délibérément exposé.
Comment savoir si mon serveur MCP n8n fonctionne correctement ?
Testez avec le MCP Inspector, un outil CLI open source d'Anthropic. Il liste les outils exposés par n'importe quel serveur MCP et permet de les appeler manuellement avant de les connecter à un agent. C'est le moyen le plus rapide de valider la configuration sans dépendre du comportement d'un LLM.
Quelle différence entre le MCP Client Tool et les intégrations natives n8n (Notion, Slack, etc.) ?
Les intégrations natives sont plus stables et mieux documentées pour les cas courants. MCP est plus flexible mais dépend de la qualité du serveur MCP tiers. Pour Notion, Slack ou Google Sheets, préférez les noeuds natifs n8n. Pour des outils internes, des API peu connues, ou quand vous voulez que l'agent décide lui-même quel outil appeler en fonction du contexte, MCP apporte quelque chose que les intégrations statiques ne peuvent pas offrir.
