4. MCP para construir workflows contra entornos no-prod

Descripción

Al terminar esta lección vas a poder dejar que un asistente de IA —Claude, ChatGPT, Cursor— construya y edite workflows dentro de tu instancia de n8n, a través del servidor MCP, apuntándolo siempre a un entorno no-prod —dev, nunca producción—. Vas a entender qué es MCP, cómo se activa el servidor a nivel de instancia, y —lo más importante— el lazo seguro que hace de una IA un colaborador y no un riesgo: la IA propone en dev, Git registra el cambio, el humano revisa el diff, y solo entonces se promueve. Vas a ver por qué los entornos aislados que montaste en el Módulo 4 son exactamente la red de seguridad que hace posible todo esto.

Esto importa porque cambia cómo se construyen workflows, y el cambio ya está aquí, no en el futuro. Una IA puede armar en minutos un workflow que a mano te tomaría una hora. Es una palanca enorme de productividad, y también una forma nueva de romper producción si la usas sin disciplina. La diferencia entre las dos cosas no está en la IA —la misma herramienta puede ser un acelerador o un desastre—; está en a qué entorno la apuntas y qué proceso pones entre lo que la IA hace y lo que llega a los pedidos reales de Cumbre. Esta lección te da ese entorno y ese proceso.

Conexión con el módulo: la lección 3 te enseñó a revisar el diff de un cambio, venga de una persona o de una IA. Esta lección te muestra de dónde viene el cambio de IA: el servidor MCP de n8n. Es la pieza que faltaba para cerrar el lazo. La IA construye (esta lección), Git registra y el humano revisa el diff (lección 3), se promueve (lección 2) y, si algo sale mal, se revierte (lección 5). El principio que esta lección instala —nunca dejar que una IA construya directo en prod— se apoya entero en los entornos aislados del Módulo 4: sin ellos, no habría un dev seguro donde soltar a la IA. Todo lo que hiciste antes fue construir la red; esta lección es donde la usas.

Sobre lo que puedo confirmar y lo que tienes que verificar. El servidor MCP de n8n es una de las áreas que más rápido evoluciona de todo el producto: cambió de forma significativa entre versiones menores durante 2026. Todo lo que en esta lección presento como sintaxis concreta —nombres de variables de entorno, la URL del endpoint, la configuración de un cliente— lo confirmé contra la documentación oficial de n8n a julio de 2026, y te voy a decir cuándo. Aun así, adopta el hábito de siempre: antes de confiar en un dato concreto de MCP, verifícalo en la documentación de tu versión y en la propia interfaz de tu instancia. El principio de esta lección —la IA construye en no-prod, el humano revisa, se promueve— es estable y no va a cambiar; los detalles de configuración sí pueden moverse. Cuando algo no coincida con lo que ves en tu n8n, tu instancia manda.

Qué es MCP, en palabras simples

Empecemos por el nombre, porque suena más intimidante de lo que es.

MCP son las siglas de Model Context Protocol —protocolo de contexto de modelo—. Es un estándar abierto que define una forma común para que un asistente de IA se conecte a una herramienta externa y la use. Piénsalo como un idioma compartido: antes de MCP, cada IA hablaba con cada herramienta a su manera, y conectar una con otra era un trabajo a medida. MCP es el acuerdo de "hablemos todos el mismo idioma", de modo que cualquier IA que lo hable pueda usar cualquier herramienta que lo hable, sin traducción especial.

La analogía útil es la de un puerto estándar. Antes, cada aparato traía su propio cargador con su propia forma de enchufe, y necesitabas el cargador exacto de cada uno. Cuando la industria se puso de acuerdo en un puerto único —un mismo conector para todo—, cualquier cargador sirve para cualquier aparato. MCP es ese puerto único entre asistentes de IA y herramientas: n8n "expone un puerto MCP", y cualquier IA que hable MCP —Claude, ChatGPT, Cursor, Windsurf— puede enchufarse a él.

¿Qué le da MCP a la IA respecto de tu n8n? La capacidad de hacer cosas dentro de tu instancia, no solo hablar de ellas. Sin MCP, le puedes pedir a una IA "escríbeme el JSON de un workflow" y te lo pega en el chat, pero eres tú quien lo importa a n8n a mano. Con el servidor MCP de n8n activado, la IA puede buscar tus workflows, crearlos, editarlos y ejecutarlos directamente en tu instancia, sin que copies y pegues nada. La IA deja de ser un consejero externo y pasa a tener manos dentro de tu n8n.

Y ahí está, exactamente, tanto el poder como el peligro. Manos dentro de tu instancia es maravilloso cuando esa instancia es dev, donde romper no cuesta. Es aterrador cuando es prod, donde romper cuesta pedidos reales. Toda esta lección gira alrededor de esa distinción.

El servidor MCP de n8n a nivel de instancia

n8n 2.0 trae su propio servidor MCP, integrado en la instancia. Repasemos qué es y qué hace, con los datos confirmados a julio de 2026.

Un servidor MCP es el lado "herramienta" de la conexión: el que expone las capacidades para que una IA (el lado "cliente") las use. Cuando activas el servidor MCP de n8n, tu instancia empieza a ofrecer un conjunto de herramientas que un asistente de IA puede invocar: buscar workflows, crearlos, editarlos, ejecutarlos, leer sus datos de ejecución. La documentación de n8n confirma que, desde la versión 2.13 en adelante, ese conjunto incluye crear y editar workflows —no solo ejecutarlos, que era lo único que se podía al principio—.

Tres hechos que conviene tener claros, confirmados contra la doc oficial:

Está en todas las ediciones, gratis incluido. El servidor MCP viene integrado en Cloud, Enterprise y la Community self-hosted gratuita. No es una feature de pago. Esto encaja con el espíritu de la guía: puedes hacer todo esto a costo cero.

Se activa a nivel de instancia y por workflow. Hay dos interruptores. Primero activas el servidor en la instancia entera; después marcas cada workflow que quieres que la IA pueda ver o tocar como "disponible en MCP". Un workflow que no marcaste, la IA no lo ve. Es una decisión deliberada de n8n: la IA no tiene acceso a todo por defecto, sino solo a lo que tú expusiste.

El acceso es por usuario, no por cliente. Aquí hay un matiz de seguridad que la doc señala explícitamente y que conviene grabar: el acceso está atado a tu usuario, y no está separado por cada cliente de IA. Es decir, todos los clientes de IA que conectes a tu cuenta ven todos los workflows que marcaste como disponibles en MCP. No puedes darle a Claude acceso a un workflow y a Cursor a otro distinto; los dos ven lo mismo que tú expusiste. Esto refuerza por qué el entorno importa tanto: si conectas la IA a prod, cualquier cliente que uses ve y potencialmente toca los workflows de producción.

Cómo se activa (los detalles que debes verificar)

Aquí van los datos concretos, con la advertencia de siempre: confírmalos en tu versión, porque esta área se mueve rápido.

En la interfaz. El servidor se activa desde la configuración de la instancia, en la sección de MCP a nivel de instancia (Instance-level MCP), con un interruptor de "Enable MCP access". Requiere permisos de dueño o administrador de la instancia. Esta es la ruta recomendada para empezar, porque te muestra en pantalla lo que estás activando.

Con variables de entorno (self-hosted). Si administras tu n8n con Docker —el caso de esta guía—, puedes controlar el servidor MCP con variables de entorno, que es la forma que encaja con tu setup por entorno del Módulo 4. Confirmadas a julio de 2026:

# Activar el acceso MCP en esta instancia (desde n8n v2.20.0)
N8N_MCP_ACCESS_ENABLED=true

# Opcional: fijar el ajuste por variable de entorno y bloquear que se cambie desde la UI
N8N_MCP_MANAGED_BY_ENV=true

# Para deshabilitar por completo el módulo MCP (quita endpoints y oculta la UI)
N8N_DISABLED_MODULES=mcp

Fíjate en la joya que esto te da para tu setup por entorno: puedes activar MCP en dev y dejarlo apagado en prod, controlándolo desde el archivo de entorno de cada uno. En el docker-compose de dev, pones N8N_MCP_ACCESS_ENABLED=true; en el de prod, pones N8N_DISABLED_MODULES=mcp para que el módulo ni siquiera exista. Con eso, la IA no puede construir en producción aunque alguien lo intente por error: el endpoint no está ahí. La separación de entornos del Módulo 4 se convierte en el candado que hace imposible el peor accidente. Esto es exactamente el tipo de red que esta lección quiere que instales.

El endpoint. Cuando el servidor está activo, expone un endpoint HTTP. Confirmado a julio de 2026, tiene esta forma:

https://<tu-dominio-n8n>/mcp-server/http

Ese es el URL que le das a tu cliente de IA para que se conecte. Para autenticarse, n8n ofrece dos caminos: OAuth2 (autorizas el acceso desde n8n) o un token de acceso MCP personal (un Bearer token atado a tu usuario, que n8n genera cuando visitas la página de acceso MCP). De nuevo: verifica la ruta y el mecanismo exactos en tu versión.

Conectar un cliente de IA (ejemplo ilustrativo)

Para cerrar la imagen, así se ve conectar Claude Desktop al servidor MCP de tu dev, usando el token de acceso. Tómalo como ilustración del mecanismo, no como una receta a copiar sin verificar, porque la configuración exacta de cada cliente cambia con sus versiones:

{
  "mcpServers": {
    "n8n-dev": {
      "command": "npx",
      "args": [
        "-y", "supergateway", "--streamableHttp",
        "https://dev.cumbre.example/mcp-server/http",
        "--header", "Authorization:Bearer <TU_TOKEN_MCP_DE_DEV>"
      ]
    }
  }
}

Lee las piezas: el nombre n8n-dev deja explícito, desde la propia configuración, que este cliente apunta a dev —un buen hábito, nombrar el entorno para no confundirte—; el URL termina en dev.cumbre.example, la instancia de desarrollo, no la de producción; y el token es el de tu usuario en dev. Cada una de esas tres piezas es una oportunidad de apuntar a prod por error, y cada una debe apuntar a dev a propósito.

Con Claude Code, la conexión se hace por comando en vez de por archivo, con la forma claude mcp add --transport http n8n-dev https://dev.cumbre.example/mcp-server/http. Y otros clientes —ChatGPT, Cursor, Windsurf— siguen patrones parecidos: un URL de endpoint y una credencial. Lo que no cambia entre clientes es lo que importa: el URL apunta a dev.

El principio innegociable: nunca directo en prod

Todo lo anterior es mecánica. Este es el corazón de la lección, y si te llevas una sola cosa, que sea esta: una IA nunca construye ni edita directamente en producción.

La razón es una combinación de dos cosas que ya conoces, y que juntas son peligrosas.

Primero, recuerda de la lección 3 cómo trabaja la IA: en un lazo que se corrige a sí mismo. La documentación de n8n lo describe con orgullo: la IA genera el workflow, lo valida, lo ejecuta —generando datos de prueba si hace falta—, lee el error si algo falla, se corrige, y vuelve a intentar. Es autónomo: no hay un humano entre iteración e iteración. Eso es maravilloso para construir rápido. Pero léelo otra vez con ojos de producción: "lo ejecuta". Si ese lazo corre en prod, la IA está ejecutando workflows sobre datos reales como parte de su proceso de construcción —mandando pedidos de prueba al CRM real de Cumbre, disparando efectos que no se pueden deshacer— sin que nadie lo haya aprobado.

Segundo, recuerda que la IA no entiende las consecuencias de negocio. Puede producir un cambio técnicamente válido que sea un desastre para Cumbre, y su lazo de autocorrección no lo detectaría, porque para la IA "funciona" significa "el JSON es válido y ejecuta sin error", no "es una buena idea para el negocio".

Junta las dos: una IA que ejecuta como parte de construir, y que no juzga las consecuencias, corriendo en el entorno donde los efectos son reales e irreversibles. Es la receta de un accidente. Por eso el principio no admite excepción: la IA construye en dev. Ahí, su lazo de autocorrección puede ejecutar todo lo que quiera, porque dev usa datos sintéticos y credenciales de prueba (Módulo 5): si la IA manda cien pedidos de prueba al CRM sandbox, no pasa nada. En prod, esos mismos cien pedidos serían cien registros reales en el CRM de Cumbre.

Fíjate en que el lazo de autocorrección de la IA no es la revisión humana. Son dos cosas distintas y las dos hacen falta. El lazo de la IA se asegura de que el workflow funcione técnicamente; la revisión humana se asegura de que el cambio sea correcto para el negocio y no esconda sorpresas. La IA no reemplaza al humano que revisa; construye más rápido lo que el humano después revisa. El día que confundas "la IA lo validó" con "está revisado", te saltaste el paso que más importa.

El lazo seguro, completo

Pongamos junto todo el módulo en el lazo que hace de la IA un colaborador seguro. Esta es la imagen que resume las lecciones 2, 3 y 4:

  1. la IA construye        2. tú exportas         3. Git registra
     en dev  (vía MCP)  →      y commiteas    →       el cambio
     su lazo se auto-          el workflow            (una versión
     corrige, ejecuta          que la IA tocó         con fecha y motivo)
     contra datos de prueba
            │                                              │
            │                                              ▼
            │                                    4. el humano revisa
            │                                       el DIFF (lección 3):
            │                                       ¿hace lo que dice?
            │                                       ¿algo inesperado?
            │                                              │
            ▼                                              ▼
  6. corre en prod  ◄──── 5. se promueve ◄──── aprobado en un
     (Módulo 5 probó,       a staging y            pull request
      lección 2 promovió)   a prod (lección 2)

Recórrelo. La IA hace su trabajo en dev, donde su autonomía es segura porque no hay nada real que romper (1). Tú tomas lo que hizo y lo pones bajo control de versiones (2, 3), lo que convierte "la IA tocó algo" en "hay un cambio registrado con su diff". Un humano lee ese diff y lo aprueba o lo rechaza (4) —este es el punto donde el juicio de negocio entra, el que la IA no tiene—. Solo lo aprobado se promueve (5), pasando por la prueba en staging (Módulo 5) antes de llegar a prod (6).

En ese lazo, la IA es rápida y poderosa en el paso 1, y no toca ningún otro paso. No commitea sola sin que mires, no aprueba su propio diff, no promueve a producción. Cada uno de esos pasos tiene un humano o una verificación de por medio. Esa es la definición operativa de "la IA propone, el humano dispone": la IA propone en el paso 1, y el humano dispone en el paso 4. Todo lo demás es la maquinaria que conecta los dos con seguridad.

Por qué los entornos aislados del Módulo 4 son la red

Vale la pena hacer explícita una deuda de gratitud con el Módulo 4, porque sin él esta lección sería imprudente.

La razón por la que puedes soltar a una IA a construir con su lazo autónomo es que el entorno donde la sueltas —dev— está aislado de verdad. No es "otra pestaña del navegador"; es una instancia de n8n separada, con su propia base de datos, sus propias credenciales de prueba y sus propios datos sintéticos, levantada con su propio Docker Compose. Cuando la IA ejecuta un workflow ahí como parte de su autocorrección, ejecuta contra el CRM sandbox, no contra el real. El aislamiento es lo que convierte la autonomía de la IA de un peligro en una comodidad.

Piénsalo como un simulador de vuelo. Un piloto en formación puede estrellar el avión cien veces en el simulador y aprender de cada choque, porque el simulador está aislado del cielo real: nadie muere en un simulador. Ese mismo piloto, practicando maniobras arriesgadas en un avión real lleno de pasajeros, sería una imprudencia criminal. dev es el simulador de la IA: puede "estrellar" workflows todo lo que su lazo de autocorrección necesite, porque está desconectado de las consecuencias reales. prod es el cielo real con pasajeros. La IA vuela en el simulador; el humano decide qué maniobra probada pasa al avión real.

Por eso el orden de esta guía tiene sentido: primero versionar (Módulos 2-3), luego aislar entornos (Módulo 4), luego probar en sandbox (Módulo 5), y recién ahora soltar a la IA. Cada módulo anterior construyó una parte de la red. Intentar usar la IA para construir workflows antes de tener entornos aislados sería como poner al piloto novato en el avión real: la herramienta es la misma, pero sin la red, es peligrosa.

Límites y permisos: lo que conviene tener presente

Cerremos con una lista honesta de límites y cuidados, algunos confirmados en la doc y otros que son buen criterio general. Verifica los específicos en tu versión.

• El acceso no está separado por cliente. Como vimos, todos los clientes de IA que conectes ven todos los workflows que marcaste como disponibles en MCP. No hay un permiso fino "este cliente ve este workflow". Trátalo así: lo que expones en MCP, lo expones a cualquier cliente conectado a tu cuenta.
• Marca en MCP solo lo que la IA necesita tocar. No expongas todos tus workflows "por si acaso". Marca como disponibles en MCP solo los que estás construyendo o editando con IA en ese momento, en dev. Menos superficie expuesta, menos que puede salir mal.
• La ejecución tiene modos. La doc señala que la mayoría de las herramientas de MCP trabajan sobre workflows no publicados, y que la de ejecución tiene un modo por defecto y uno manual. No dependas de recordar esto de memoria: verifica en qué modo ejecuta la IA antes de conectarla a algo que te importe, y hazlo en dev donde el modo no cause daño.
• Puedes revocar el acceso. Los clientes conectados aparecen en una pestaña de la configuración, y puedes revocar el acceso de cualquiera. Si algún cliente ya no lo usas, revócalo: una conexión abierta que no usas es superficie de riesgo sin beneficio.
• El humano sigue siendo el responsable. Ningún ajuste de MCP te quita la responsabilidad de lo que llega a prod. La IA construye; tú respondes por lo que promoviste. Ese reparto no cambia con ninguna configuración.

La conclusión de todos estos límites apunta a lo mismo: la seguridad de usar IA en tu instancia no viene de los permisos finos de MCP —que hoy son gruesos—, viene del proceso que tú pones alrededor. Apuntar la IA a dev, exponer solo lo necesario, revisar cada diff, promover solo lo aprobado. El proceso es la seguridad; la configuración de MCP es apenas el primer candado.

Errores comunes

Conectar la IA a la instancia de producción (conceptual y de seguridad, el error grave). Qué pasa: alguien activa el servidor MCP en su n8n de prod —o tiene una sola instancia que hace de todo— y conecta Claude o Cursor ahí, dejando que construyan y ejecuten sobre los datos reales de Cumbre. Por qué pasa: si no montaste entornos separados, tu única instancia es producción, y conectar la IA ahí parece lo natural. Cómo detectarlo: si el URL que le diste a tu cliente de IA apunta a la instancia donde corren los pedidos reales, tienes el problema. Cómo corregirlo: la IA se conecta a dev, siempre. Y para volverlo imposible, apaga el módulo MCP en prod con N8N_DISABLED_MODULES=mcp, de modo que el endpoint ni exista ahí. La separación de entornos del Módulo 4 es lo que hace este error evitable por diseño, no solo por disciplina.

Confundir el lazo de autocorrección de la IA con la revisión humana (conceptual). Qué pasa: alguien ve que la IA "valida y ejecuta" el workflow que construyó, concluye que ya está revisado, y lo promueve sin leer el diff. Después el workflow, técnicamente correcto, resulta un desastre de negocio. Por qué pasa: el lazo de la IA es convincente —dice "validé, ejecuté, funciona"— y suena a revisión. Cómo detectarlo: si promoviste algo que la IA construyó sin haber leído su diff con ojos humanos, te saltaste la revisión. Cómo corregirlo: el lazo de la IA verifica que el workflow funcione; la revisión humana verifica que sea correcto para el negocio y no esconda sorpresas. Las dos hacen falta. La IA nunca aprueba su propio trabajo; el paso 4 del lazo seguro es un humano leyendo el diff, y no se salta.

Exponer todos los workflows en MCP "por comodidad" (práctico y de seguridad). Qué pasa: alguien marca todos sus workflows como disponibles en MCP para no tener que ir activando uno por uno, y termina con toda su automatización expuesta a cualquier cliente de IA conectado. Por qué pasa: activar cada workflow es un paso, y saltárselo se siente eficiente. Cómo detectarlo: si tu IA puede ver workflows que no estás construyendo ni editando con ella, expusiste de más. Cómo corregirlo: marca en MCP solo lo que la IA necesita tocar ahora, en dev, y quítalo cuando termines. Menos superficie expuesta es menos que puede salir mal, sobre todo porque el acceso no está separado por cliente: lo que expones, lo ve cualquiera conectado.

Copiar la configuración del cliente de esta guía sin verificar la de tu versión (práctico). Qué pasa: alguien copia el bloque JSON de configuración de Claude Desktop tal cual, no le funciona, y se frustra. Por qué pasa: la configuración exacta de cada cliente de IA y la sintaxis del endpoint de MCP cambian con las versiones, y esta guía es una foto de julio de 2026. Cómo detectarlo: si la conexión no se establece y estás usando literalmente lo que dice esta lección sin haber verificado, ese es el punto. Cómo corregirlo: usa el ejemplo de esta guía para entender el mecanismo —un URL de endpoint que apunta a dev, una credencial, un nombre que dice el entorno—, pero saca los detalles exactos de la documentación oficial de tu versión y de la página de conexión de tu propia instancia. El principio es estable; la sintaxis, no.

Ejercicios

Ejercicio 1 — Explica el principio con tus palabras. En tres o cuatro frases, explícale a un colega por qué una IA puede construir workflows con su lazo autónomo en dev sin problema, pero nunca debe hacerlo en prod. Usa la analogía del simulador de vuelo si te ayuda.

Ejercicio 2 — Diseña el candado por entorno. Tienes tres entornos en Docker Compose: dev, staging y prod. Quieres que la IA pueda construir en dev, y que sea imposible que construya en prod, no solo desaconsejado. ¿Qué variables de entorno pones en el archivo de cada uno, y por qué eso hace el accidente imposible en vez de solo improbable?

N8N_MCP_ACCESS_ENABLED=true

N8N_DISABLED_MODULES=mcp

Ejercicio 3 — Ordena el lazo seguro. Te dan estos seis pasos desordenados. Ponlos en el orden correcto del lazo seguro, y marca cuál es el único paso donde la IA actúa y cuál es el único donde un humano debe aprobar: (i) se promueve a staging y a prod; (ii) la IA construye el workflow en dev; (iii) el humano revisa el diff y aprueba en un pull request; (iv) corre en prod; (v) exportas y commiteas el workflow que la IA tocó; (vi) Git registra el cambio con fecha y motivo.

Resumen y siguiente paso

En esta lección abriste la puerta a construir workflows con IA, con la disciplina que lo hace seguro. Entendiste que MCP es un protocolo estándar —un "puerto único"— que deja a un asistente de IA usar herramientas externas, y que el servidor MCP de n8n le da a la IA manos dentro de tu instancia: buscar, crear, editar y ejecutar workflows directamente. Viste los datos confirmados a julio de 2026 —está en todas las ediciones incluida Community, se activa a nivel de instancia y por workflow, el acceso es por usuario y no por cliente, con el endpoint /mcp-server/http y las variables N8N_MCP_ACCESS_ENABLED y N8N_DISABLED_MODULES— y la advertencia de verificar cada detalle en tu versión, porque esta área se mueve rápido. Instalaste el principio innegociable: la IA construye en dev, nunca en prod, porque su lazo de autocorrección ejecuta como parte de construir, y en prod esa ejecución tocaría datos reales e irreversibles. Y armaste el lazo seguro completo —la IA propone en dev, Git registra, el humano revisa el diff, se promueve— apoyado en la red que el Módulo 4 construyó: los entornos aislados que son el simulador de vuelo donde la IA puede equivocarse sin consecuencias.

Antes de avanzar deberías poder: explicar qué es MCP y qué le da a la IA respecto de tu n8n; decir por qué la IA construye en dev y nunca en prod, con la analogía del simulador; ordenar los pasos del lazo seguro y señalar dónde actúa la IA y dónde aprueba el humano; y diseñar el candado por entorno con variables de Docker Compose.

La lección 5 completa la red de seguridad por el otro lado. Hasta aquí construiste el camino hacia adelante —promover— y su control de calidad —revisar—. Pero ningún sistema es seguro sin una salida de emergencia. La lección 5 es el rollback: qué haces cuando un cambio, humano o de IA, llegó a prod y rompió algo. Vas a aprender a volver al último JSON bueno del repositorio y re-importarlo al entorno afectado, y a escribir un runbook —un procedimiento numerado que otra persona pueda seguir bajo presión, a las tres de la mañana, sin pensar—. Porque el rollback se ensaya antes del incidente, no durante.

Recursos

• Set up and use the n8n MCP server — n8n Docs — la documentación oficial del servidor MCP a nivel de instancia: cómo activarlo, qué puede hacer la IA, y las versiones. La fuente que confirmé para esta lección; verifica los detalles en tu versión, porque cambian rápido.
• Connect to the n8n MCP server — n8n Docs — cómo conectar Claude Desktop, Claude Code, Cursor y ChatGPT al endpoint, con la autenticación por OAuth2 o token; de aquí salen los ejemplos de conexión.
• Model Context Protocol — sitio oficial — qué es MCP como estándar abierto, más allá de n8n; útil para entender el "puerto único" que conecta IAs con herramientas.
• Manage instance settings using environment variables — n8n Docs — la referencia de variables de entorno de n8n, incluidas las de MCP y N8N_DISABLED_MODULES, para configurar el candado por entorno.
• Release notes 2.x — n8n Docs — el historial de versiones; imprescindible para MCP, porque las capacidades de construir y editar workflows llegaron y cambiaron entre versiones menores.