Depuis début juillet, mon MCP Server Trigger retourne « No bridge acquired » à chaque appel d’outil. Le point de terminaison SSE est en ligne, mcp-remote se connecte, mais le bridge ne s’initialise jamais. Ça fonctionnait bien fin juin. Instance cloud, workflow utilisant les sous-workflows Execute Workflow comme outils MCP. Quelqu’un a-t-il trouvé une solution ?
Hé @Munish_Gupta, en attendant une réponse, voici quelques ressources qui pourraient vous aider :
Ressources suggérées
Automatiquement associées à votre question.
Documentation :
Forum :
@Gonzalo_Romero_Herna, @Inshal_Amir, @Patrik_Breitenmoser - vous avez déjà aidé avec des problèmes similaires, pouvez-vous jeter un œil ?
Suggéré automatiquement par le bot communautaire de n8n. C’est un projet pilote - partagez vos commentaires ici.
Salut @Munish_Gupta Bienvenue !
Cette chaîne provient du propre évaluateur d’expressions de n8n et ne s’active que lorsque le moteur d’expression vm expérimental est actif. Le déclencheur MCP Server résout les paramètres d’outils en dehors de la fenêtre isolée dont ce moteur a besoin, donc la session se connecte et la liste d’outils fonctionne bien tandis que chaque appel s’arrête à la transmission sans spawn de sous-exécution. N8N_EXPRESSION_ENGINE est une variable auto-hébergée sans équivalent Cloud, donc help@n8n.io doit vérifier si vm est activé sur votre instance et le remettre à la version legacy. Envoyez-leur l’ID du workflow, la chaîne d’erreur exacte, et le détail que l’appel s’arrête en millisecondes sans spawner une exécution enfant.
En attendant qu’ils le basculent, exposez les sous-workflows via le MCP au niveau de l’instance à la place du nœud de déclenchement. Allez à Paramètres > MCP au niveau de l’instance, activez l’accès, allumez « Disponible dans MCP » sur chaque sous-workflow, puis pointez votre client sur :
https://<your-n8n-domain>/mcp-server/http
Le client les exécute avec execute_workflow et transmet les arguments directement, donc aucune expression $fromAI() dans un nœud d’outil n’a besoin de résoudre. Cet outil exécute la version publiée du workflow.
Bonjour @Munish_Gupta, le mot « bridge » dans cette erreur est trompeur — il n’a rien à voir avec le bridge de transport MCP. C’est le bridge isolate V8 de n8n à l’intérieur de l’évaluateur d’expressions, c’est pourquoi chaque symptôme au niveau du transport semble sain : le point de terminaison SSE est actif, mcp-remote se connecte, les outils se listent correctement. La couche de transport fonctionne bien. L’échec se situe en aval, à la résolution des paramètres des outils.
Plus précisément : quand le moteur d’expressions expérimental vm est actif, le Trigger MCP Server résout les paramètres de l’outil en dehors de la fenêtre isolate que ce moteur exige, de sorte que la poignée de main et tools/list réussissent tandis que chaque tools/call échoue avant que votre sous-workflow ne commence.
Confirmez-le en environ cinq minutes :
- Dupliquez l’un de vos outils.
- Dans la copie, remplacez chaque entrée
$fromAI()par un littéral en dur. - Appelez les deux depuis votre client.
- Le hardcodé fonctionne,
$fromAI()échoue → confirmé. C’est la résolution des paramètres, pas vos sous-workflows. - Les deux échouent → quelque chose d’autre se passe ; postez l’exécution.
Ouvrez aussi une exécution défaillante et cherchez cette signature : durée très courte (dizaines de millisecondes), sortie vide, et aucune exécution enfant générée. Si l’exécution du sous-workflow n’apparaît jamais dans la liste des Exécutions, elle est morte à la transmission avant que votre workflow ne s’exécute.
Ignorez ceux-ci — ils semblent pertinents mais ne sont pas la cause : réenregistrer le connecteur, passer de SSE à Streamable HTTP, réinstaller ou re-épingler mcp-remote.
Comme vous êtes sur Cloud, N8N_EXPRESSION_ENGINE est une variable d’environnement auto-hébergée sans équivalent Cloud et sans bouton dans l’interface utilisateur, donc vous ne pouvez pas la revenir vous-même. Envoyez un e-mail à help@n8n.io avec :
- votre ID de workflow et votre version exacte de Cloud
- la chaîne d’erreur exacte
- que les outils se listent correctement mais que chaque appel échoue
- que les appels meurent en millisecondes sans exécution enfant générée
- votre résultat hardcodé vs
$fromAI()
Et demandez-leur directement : « N8N_EXPRESSION_ENGINE est-il défini sur vm sur mon instance ? Veuillez le revenir à legacy. » Être aussi précis est ce qui empêche que cela soit dirigé vers un dépannage générique MCP.
Contournement en attendant : contournez complètement le Trigger MCP Server et exposez les sous-workflows via MCP au niveau de l’instance. Paramètres → MCP au niveau de l’instance → activer l’accès, puis activez « Disponible dans MCP » pour chaque sous-workflow, et pointez votre client vers :
https://<your-n8n-domain>/mcp-server/http
Le client les invoque via execute_workflow et transmet les arguments directement, donc aucune expression $fromAI() n’a besoin de se résoudre dans un nœud d’outil. Deux avertissements : cela exécute la version publiée de chaque workflow, donc enregistrez et publiez d’abord ; et les noms et descriptions des outils proviennent du nom/description du workflow plutôt que de votre configuration du nœud d’outil, donc la liste des outils de votre client aura une apparence différente de ce que vous avez maintenant.
Une chose qui aiderait à affiner cela — quelle version exacte de Cloud utilisez-vous ? « Fonctionne fin juin, cassé début juillet » cerne probablement la version qui a activé cela pour votre instance.
Nous avons examiné cela et il semble que ce problème pourrait être résolu dans une version récente. Veuillez mettre à jour et vérifier si vous rencontrez toujours le même problème.
Merci les gars. Le problème a été résolu en mettant à jour la version n89.