MCP en n8n: qué pieza usar y cómo conectar Claude a tus workflows

MCP en n8n son tres piezas distintas que conviene no mezclar. Hay un nodo para que n8n ofrezca herramientas, dos nodos para que n8n use las de otros y un servidor de toda la instancia para que Claude trabaje con tus workflows, y cada una se activa en un sitio distinto de n8n.

Para escribir esta guía instalamos n8n 2.42.6, la versión estable a 9 de octubre de 2026. Probamos el trigger y el servidor de la instancia con el cliente oficial de MCP, una biblioteca que mantiene el propio proyecto MCP. Primero verás qué pieza te conviene y cómo conectar Claude, y al final tienes una lista de seguridad para repasar antes de abrir nada a internet.

MCP en dos líneas

MCP (Model Context Protocol) es un protocolo abierto para que una aplicación de IA, como Claude, use herramientas y datos de otros sistemas. Un servidor MCP ofrece herramientas (en la jerga, tools) y un cliente MCP las descubre y las llama cuando el modelo lo decide.

El contexto completo está en qué es MCP y en la lección de introducción del curso. Para seguir este artículo basta con saber que siempre hay un lado que ofrece tools y otro que las usa, y que n8n puede estar en cualquiera de los dos.

Las tres piezas MCP de n8n

MCP Server Trigger: n8n ofrece las tools de un workflow

El nodo MCP Server Trigger convierte un workflow en un servidor MCP. La documentación lo presenta así: “Use the MCP Server Trigger node to allow n8n to act as a Model Context Protocol (MCP) server, making n8n tools and workflows available to MCP clients.”

Se comporta distinto de los demás triggers. En lugar de pasar datos al siguiente nodo, solo se conecta a nodos de tipo tool, y n8n los ejecuta cuando un cliente los llama. Para publicar un workflow entero como tool, le conectas un nodo Custom n8n Workflow Tool. Cada trigger es un servidor aparte y solo expone las tools conectadas a él.

Existe desde la versión 1.88.0 (abril de 2025). La versión actual del nodo atiende en la misma URL los dos transportes HTTP de MCP: el actual, Streamable HTTP, y el antiguo, SSE. Lo que no admite es stdio, el modo en que el cliente arranca el servidor como un programa en tu propio ordenador.

MCP Client Tool y MCP Client: n8n usa tools de otros

Aquí n8n hace de cliente. El MCP Client Tool es un sub-nodo del AI Agent. Le das la URL de un servidor MCP externo y tu agente puede llamar a sus tools, a todas, solo a algunas o a todas menos algunas. Para identificarse ante ese servidor admite un token Bearer, una o varias cabeceras y OAuth2. Con OAuth2, n8n puede darse de alta él solo en el servidor (Dynamic Client Registration), y esa opción viene activada.

El MCP Client llegó en la 1.122.0 (noviembre de 2025) y hace lo mismo como paso normal del workflow, sin agente. Eliges servidor, tool y argumentos, y el resultado sigue por el flujo como el de cualquier otro nodo.

En el panel de nodos hay además un registro de servidores MCP que conectas a un agente en un clic. La documentación avisa de que esa lista cambia a menudo, así que no damos nombres.

El servidor MCP de la instancia: Claude trabaja con tu n8n

Si quieres hablar con tu n8n desde Claude, esta es la pieza. n8n la llama Instance-level MCP y la sirve en la ruta /mcp-server/http de tu instancia. Según la documentación, un cliente conectado puede buscar tus workflows, usar los que hayas marcado para MCP, lanzarlos y probarlos, y crear o editar workflows y tablas de datos.

En nuestra prueba, sin licencia y con la clave del propietario, el servidor ofreció 50 tools. Entre ellas están search_workflows, execute_workflow, create_workflow_from_code, update_workflow y publish_workflow. La lista exacta cambia con la licencia, con algunas opciones internas de n8n y con los permisos que concedas.

No lo confundas con czlonkowski/n8n-mcp, que sale mucho al buscar «n8n mcp». Es un proyecto de la comunidad, ajeno a n8n, y en este artículo solo tratamos las piezas oficiales.

Cuál necesitas según lo que quieras hacer

Lo que quieres	Pieza	Dónde se configura
Que Claude ejecute o cree mis workflows	Servidor MCP de la instancia	Settings > Instance-level MCP, y cada workflow marcado como disponible
Que mi agente de n8n use un servidor MCP (Notion, GitHub, uno tuyo)	MCP Client Tool, o MCP Client si no hay agente	Dentro del workflow, con la URL del servidor y su credencial
Publicar unas tools mías para cualquier cliente MCP	MCP Server Trigger	Dentro de un workflow, con su propia URL y su autenticación

Si dudas entre la primera fila y la tercera, piensa en quién controla qué. Con el servidor de la instancia, Claude ve tus workflows como workflows y puede crearlos o cambiarlos. Con el trigger eres tú quien define cada tool y lo que hace, y el cliente solo puede llamarlas. Para dar a un equipo un par de acciones concretas («consultar un pedido», «abrir una incidencia») nos quedamos con el trigger, y con el servidor de la instancia cuando quieres que Claude te ayude a construir y mantener automatizaciones.

Conectar Claude a n8n con el servidor de la instancia

Estos son los pasos que documenta n8n, iguales para Cloud y para instalaciones propias. Nosotros probamos el servidor en una instalación propia con el cliente oficial de MCP, pero no lo conectamos desde Claude Desktop, claude.ai ni Claude Code. Los pasos 4 y 5 salen, por tanto, de la documentación de n8n.

1. Activa MCP en la instancia. En Settings > Instance-level MCP, pulsa Enable MCP access. Solo pueden hacerlo el owner o un admin. Si tu n8n es self-hosted y prefieres variables de entorno, la documentación da N8N_MCP_MANAGED_BY_ENV=true y N8N_MCP_ACCESS_ENABLED=true, que por defecto valen false.
2. Marca los workflows que Claude podrá usar. Cada workflow tiene la opción Available in MCP, y desde la 2.24.0 también puedes marcarlos por proyecto o por carpeta.
3. Copia la URL del servidor. Tiene la forma https://<your-n8n-domain>/mcp-server/http, con tu dominio en lugar de <your-n8n-domain>. La documentación insiste en que no es la dirección del editor, así que no copies la de la barra del navegador.
4. Añade el conector en Claude Desktop. Ve a Settings > Connectors > Add custom connector, ponle un nombre como «n8n MCP» y pega la URL. Según la documentación, Claude te lleva a n8n para que apruebes el acceso con OAuth, es decir, autorizas la conexión en una pantalla de n8n en lugar de copiar una clave. Desde la 2.32.0 esa pantalla te deja elegir qué permisos concedes.
5. En Claude Code, el equivalente es claude mcp add --transport http n8n https://<your-n8n-domain>/mcp-server/http. Después escribes /mcp dentro de Claude Code para autorizar.

Desde la 2.33.0, n8n incluye un diálogo Connect a client con los pasos de cada cliente, y la documentación cubre también Cursor, VS Code, Codex CLI, Gemini CLI y otros. Para claude.ai u otro cliente en la nube, la documentación pide que tu instancia sea accesible públicamente desde internet. Lo explicamos con más detalle en cómo conectar un servidor MCP a Claude.

También puedes usar una API key en lugar de OAuth. Es un token personal ligado a tu usuario que viaja en la cabecera Authorization: Bearer. Para Claude Desktop, la documentación de n8n la configura con supergateway, un paquete de terceros que se ejecuta con npx, el comando de Node que descarga un paquete y lo ejecuta en tu máquina. Preferimos OAuth, que es lo que recomienda n8n y no obliga a instalar nada.

Antes de pedirle a Claude que cree workflows, conviene saber cómo lo hace el servidor. Partir de una descripción en lenguaje natural no basta. El cliente tiene que escribir el workflow como código con el SDK de workflows de n8n, una biblioteca de TypeScript y JavaScript, y validarlo con validate_workflow antes de crearlo. Por eso la documentación sugiere usar agentes de programación como Claude Code en lugar de clientes de chat para esa tarea.

Ejecutar y consultar workflows sí resulta cómodo desde el chat. Ten en cuenta que execute_workflow lanza por defecto la versión publicada, no la que tengas a medias en el editor.

Si conectas Claude a un MCP Server Trigger

La página del trigger solo documenta Claude Desktop, y lo hace con mcp-remote. Es un programa que corre en tu ordenador y hace de puente: Claude Desktop lo arranca como si fuera un servidor local y mcp-remote reenvía las peticiones al trigger. El ejemplo oficial lo lanza con npx mcp-remote <MCP_URL> sin fijar versión.

Importante: mcp-remote es un paquete de terceros y tuvo una vulnerabilidad crítica, la CVE-2025-6514 (aviso GHSA-6xpm-ggf7-wc3p), en las versiones desde la 0.0.5 hasta antes de la 0.1.16. Si lo usas, fija una versión corregida en lugar de dejar que npx descargue la que toque.

Con muchos clientes ya no hace falta ese puente. El trigger sirve Streamable HTTP en su URL de producción, https://<host>/mcp/<path>, y en nuestra prueba el cliente oficial se conectó a ella directamente. Por eso Claude Code con --transport http, o un conector personalizado si la URL es pública, deberían bastar. No lo hemos comprobado con esos clientes concretos contra un trigger.

La documentación de n8n recoge además una rareza que tampoco hemos probado. Si conectas claude.ai a un trigger con Authentication en None, claude.ai te pide iniciar sesión en n8n de todos modos. n8n lo explica así: tu instancia ofrece inicio de sesión con usuario de n8n para otros triggers, y claude.ai supone que todas las direcciones MCP de tu dominio lo usan. Según n8n, claude.ai es el único cliente conocido que lo hace.

Qué versión del protocolo habla cada pieza

La versión 2026-07-28 de MCP cambió mucho. Quita el saludo inicial (initialize) con el que cliente y servidor acordaban la versión, y quita también las sesiones. Lo contamos en MCP 2026-07-28: el protocolo pasa a ser sin estado. Las piezas de n8n no van todas al mismo paso.

El servidor de la instancia ya habla 2026-07-28. n8n lo pasó a la versión 2 del SDK de TypeScript de MCP en la 2.35.0 (agosto de 2026), y el modo de compatibilidad de ese SDK le permite seguir atendiendo en la misma URL a los clientes de la era 2025. Con el cliente oficial en modo automático obtuvimos esto:

modo: "auto" | era: modern | versión: 2026-07-28
servidor: {"name":"n8n MCP Server","version":"1.2.0"}

En modo antiguo (legacy), el mismo servidor respondió con 2025-11-25.

El MCP Server Trigger sigue en la era 2025. Usa la versión 1 del SDK (la 1.26.0), que llega como mucho a la versión 2025-11-25 del protocolo. Nuestro cliente, en modo automático, bajó a esa versión y funcionó sin problema. Fijado a 2026-07-28, falló:

### auto
modo: "auto" | era: legacy | versión: 2025-11-25
### pin:2026-07-28
ERROR: SdkError ERA_NEGOTIATION_FAILED Version negotiation failed: the server did not offer pinned protocol version 2026-07-28 via server/discover (no fallback in pin mode)

También probamos a mano una petición al estilo 2026-07-28, sin saludo previo, y el trigger respondió 400 con "Bad Request: Server not initialized". Cuando le enviamos un initialize pidiendo 2026-07-28, lo aceptó y contestó con "protocolVersion":"2025-11-25".

Los nodos MCP Client Tool y MCP Client usan el mismo SDK v1. Por lo que leemos en su código, se conectan con el saludo de la era 2025, así que un servidor que solo aceptara 2026-07-28, sin modo de compatibilidad, no les respondería. Esto no lo hemos probado.

Hoy todo funciona gracias a la compatibilidad entre versiones. Un cliente moderno en modo automático baja de versión para hablar con el trigger, como hizo el nuestro, y el servidor de la instancia atiende a los clientes antiguos, así que no tienes que hacer nada. Si algún día un cliente o un servidor deja de aceptar la era 2025, el trigger y los nodos cliente son las piezas que tendrán que ponerse al día.

Si pones n8n detrás de un proxy, un balanceador o un firewall que filtra cabeceras, la documentación del servidor de la instancia pide dejar pasar MCP-Protocol-Version, Mcp-Method y Mcp-Name. Sin ellas, el cliente puede no conectar o caer a una versión antigua del protocolo.

Lista de seguridad antes de abrirlo a internet

Esto es lo que revisaríamos en cualquier n8n con MCP. El trasfondo general lo tienes en seguridad en servidores MCP.

• Pon autenticación en el trigger. El nodo se crea con Authentication en None, y la única barrera por defecto es que su ruta es aleatoria. Quien tenga la URL de producción puede listar y llamar tus tools, y esas tools usan las credenciales que n8n tenga guardadas en sus nodos. Elige Bearer, Header o n8n User Auth (OAuth2). Esta última llegó en la 2.27.0 para la versión 2 del nodo y es de uso general desde la 2.36.0. En nuestra prueba con Bearer, una petición sin token o con un token incorrecto recibió 403 y Authorization data is wrong!.
• Distingue la URL de test de la de producción. La de test (/mcp-test/...) solo existe mientras escuchas desde el editor y muestra los datos en el canvas. La de producción (/mcp/...) queda activa mientras el workflow esté publicado. Si configuras un cliente con la de test, dejará de funcionar enseguida, y si publicas el workflow, la de producción queda abierta hasta que lo despublicas.
• No des por hecho que solo te llama tu cliente. Configuramos un trigger sin autenticación y le enviamos una petición con Origin: https://evil.example, la cabecera con la que el navegador indica desde qué web sale la llamada. El trigger respondió 200, abrió la sesión y devolvió Access-Control-Allow-Origin: https://evil.example, que es el permiso para que esa web lea la respuesta. La causa la encontramos leyendo el código: los webhooks de n8n devuelven el origen que reciben si no tienen una lista de orígenes permitidos, y el MCP Server Trigger no ofrece esa opción. De ahí deducimos que el JavaScript de cualquier web que abra alguien con acceso a la URL podría llamar a tus tools, aunque el trigger esté en localhost o en una red interna. La especificación de MCP pide a los servidores validar Origin, y como el trigger no lo hace, tu defensa es la autenticación.
• Usa la 2.42.1 o posterior. En los últimos meses n8n ha publicado varios avisos de seguridad que afectan a MCP. Uno de los más recientes, GHSA-5jr4-xmvf-frmj, del 30 de septiembre de 2026, permitía tomar la cuenta del owner a través del intérprete con el que el servidor MCP valida workflows. Se corrigió en la 2.42.1 y en la 2.41.4, así que si sigues en la rama 2.41 tu mínimo es la 2.41.4.
• Marca en el servidor de la instancia solo los workflows necesarios. Todos los clientes que conectes ven todos los workflows marcados, y n8n no permite reservar un workflow para un cliente concreto. La tool search_workflows devuelve además una vista previa de todos los workflows que tu usuario puede ver, estén marcados o no, y así lo vimos en la prueba. En la pantalla de OAuth, concede solo los permisos que necesites. Limita también las URL de retorno a una lista de confianza, porque por defecto n8n acepta cualquiera, y revoca en Connected clients lo que ya no uses.
• Fija la versión de las pasarelas. Con npx y sin versión, ejecutas en tu máquina lo que el autor haya publicado ese día. Vale para mcp-remote y para supergateway, que no son de n8n.

Dónde seguir

Si vienes de n8n y quieres entender lo que pasa por debajo, la lección 12, MCP sin programar, es la que más encaja con este artículo. Explica cómo conectar servidores existentes a clientes reales, cómo publicar como servidor un flujo de una plataforma de automatización y cuándo eso basta y cuándo hay que programar. La lección 5 sobre herramientas cuenta qué es una tool, cómo se define y qué forma tienen la llamada y el resultado, que es justo lo que configuras en el trigger.

Si acabas exponiendo n8n con OAuth o detrás de tu propio dominio, en el nivel Avanzado tienes la lección de APIs externas y autorización, con la autorización de MCP de extremo a extremo. La de despliegue en producción trata la validación de Host y Origin, y la de Origin es la que echamos de menos en el trigger.