Desde principios de julio, mi MCP Server Trigger devuelve ‘No bridge acquired’ en cada llamada de herramienta. El endpoint SSE está activo, mcp-remote se conecta, pero el bridge nunca se inicializa. Funcionaba bien a finales de junio. Instancia en la nube, flujo de trabajo que utiliza sub-flujos de Execute Workflow como herramientas MCP. ¿Alguien ha encontrado una solución?
Hola @Munish_Gupta, mientras esperas una respuesta, aquí hay algunas cosas que podrían ayudarte:
Recursos sugeridos
Coincidencia automática con tu pregunta.
Documentación:
Foro:
@Gonzalo_Romero_Herna, @Inshal_Amir, @Patrik_Breitenmoser - ustedes han ayudado con problemas similares antes, ¿pueden echar un vistazo?
Sugerido automáticamente por el bot de comunidad de n8n. Es una prueba piloto - comparte tu opinión aquí.
¡Hola @Munish_Gupta! ¡Bienvenido!
Esa cadena proviene del evaluador de expresiones propio de n8n y solo se activa cuando el motor de expresiones vm experimental está activo. El MCP Server Trigger resuelve los parámetros de herramienta fuera de la ventana aislada que ese motor necesita, por lo que la sesión se conecta y la lista de herramientas funciona bien, pero cada llamada falla en el traspaso sin que se genere ninguna sub-ejecución. N8N_EXPRESSION_ENGINE es una variable autohospedada sin equivalente en Cloud, por lo que help@n8n.io tiene que verificar si vm está habilitado en tu instancia y volver a cambiarlo a legacy. Envíales el ID del flujo de trabajo, la cadena de error exacta y el detalle de que la llamada falla en milisegundos sin generar una ejecución secundaria.
Hasta que lo cambien, expón los subflujos de trabajo a través de MCP a nivel de instancia en lugar del nodo del trigger. Ve a Settings > Instance-level MCP, habilita el acceso, activa “Available in MCP” en cada subflujo de trabajo y apunta tu cliente a:
https://<your-n8n-domain>/mcp-server/http
El cliente los ejecuta con execute_workflow y pasa los argumentos directamente, por lo que ninguna expresión $fromAI() en un nodo de herramienta tiene que resolverse. Esa herramienta ejecuta la versión publicada del flujo de trabajo.
Hola @Munish_Gupta, la palabra «bridge» en ese error es engañosa — no tiene nada que ver con el puente de transporte MCP. Es el puente isolate V8 de n8n dentro del evaluador de expresiones, por eso cada síntoma a nivel de transporte se ve saludable: el endpoint SSE está activo, mcp-remote se conecta, las herramientas se enumeran correctamente. La capa de transporte está bien. El fallo es posterior, en la resolución de parámetros de herramientas.
Específicamente: cuando el motor de expresiones vm experimental está activo, el disparador MCP Server resuelve los parámetros de la herramienta fuera de la ventana de aislamiento que ese motor requiere, por lo que el apretón de manos y tools/list tienen éxito mientras que cada tools/call falla antes de que tu sub-flujo de trabajo comience.
Confírmalo en unos cinco minutos:
- Duplica una de tus herramientas.
- En la copia, reemplaza cada entrada
$fromAI()con un literal codificado. - Llama a ambas desde tu cliente.
- El codificado funciona,
$fromAI()falla → confirmado. Es resolución de parámetros, no tus sub-flujos de trabajo. - Ambos fallan → algo más está sucediendo; publica la ejecución.
También abre una ejecución fallida y busca esta huella digital: duración muy corta (decenas de milisegundos), salida vacía y ninguna ejecución secundaria generada. Si la ejecución del sub-flujo de trabajo nunca aparece en la lista de Ejecuciones, murió en la transferencia antes de que tu flujo de trabajo se ejecutara.
Salta estos — se ven relevantes pero no son la causa: volver a registrar el conector, cambiar SSE → HTTP Streamable, reinstalar o volver a anclar mcp-remote.
Ya que estás en Cloud, N8N_EXPRESSION_ENGINE es una variable de entorno alojada por uno mismo sin equivalente en Cloud ni alternancia de interfaz de usuario, así que no puedes revertirla tú mismo. Envía un correo a help@n8n.io con:
- tu ID de flujo de trabajo y versión exacta de Cloud
- la cadena de error exacta
- que las herramientas se enumeran correctamente pero cada llamada falla
- que las llamadas mueren en milisegundos sin ejecución secundaria generada
- tu resultado codificado-versus-
$fromAI()
Y pregúntales directamente: «¿Está N8N_EXPRESSION_ENGINE configurado en vm en mi instancia? Por favor, revierte a legacy.» Ser tan específico es lo que evita que se enrute a la solución de problemas genérica de MCP.
Solución alternativa mientras esperas: omite el disparador MCP Server completamente y expón los sub-flujos de trabajo a través de MCP a nivel de instancia. Configuración → MCP a nivel de instancia → habilitar acceso, luego activa «Available in MCP» para cada sub-flujo de trabajo, y apunta tu cliente a:
https://<tu-dominio-n8n>/mcp-server/http
El cliente los invoca a través de execute_workflow y pasa argumentos directamente, así que ninguna expresión $fromAI() tiene que resolverse en un nodo de herramienta. Dos advertencias: ejecuta la versión publicada de cada flujo de trabajo, así que guarda y publica primero; y los nombres y descripciones de herramientas provienen del nombre/descripción del flujo de trabajo en lugar de tu configuración de nodo de herramienta, así que la lista de herramientas de tu cliente se verá diferente a la que tienes ahora.
Una cosa que ayudaría a reducir esto — ¿en qué versión exacta de Cloud estás? «Bien a fines de junio, roto a principios de julio» probablemente delimita la versión que activó esto para tu instancia.
Hemos revisado esto y parece que podría estar solucionado en un lanzamiento reciente. Por favor, actualiza y comprueba si sigues teniendo el mismo problema.
Gracias chicos. El problema se resolvió al actualizar la versión n89.