7. MCP en n8n: consumir tools externas y el servidor MCP de instancia

Descripción

Al terminar esta lección vas a poder conectar tu agente a un servidor MCP que otra empresa publica —para que use tools que tú nunca construiste— eligiendo con criterio cuáles de esas tools expones y cuáles no, y vas a poder abrir el servidor MCP de tu propia instancia de n8n para que un cliente como Claude Desktop, ChatGPT, Cursor o Claude Code construya y ejecute workflows dentro de tu n8n, entendiendo exactamente qué le estás entregando cuando lo haces.

Esto importa por una razón que ya viviste en las lecciones anteriores sin nombrarla. Cada tool que le diste al agente hasta ahora la construiste tú: elegiste el nodo, escribiste la query, redactaste la descripción, mapeaste cada $fromAI(). Eso funciona perfecto mientras el sistema del otro lado sea tuyo o tenga un nodo nativo en n8n. Pero el día que el equipo te diga "el agente tiene que poder crear la incidencia en el espacio de Notion del equipo, y de paso abrir el issue en GitHub", te encuentras con un problema de escala: cada sistema externo son varias tools, cada tool son varios campos, y todas hay que mantenerlas cuando el proveedor cambie su API. MCP invierte ese trabajo. En vez de que tú construyas el adaptador para cada servicio, el servicio publica el suyo y tú solo lo enchufas.

Conexión con el módulo: la lección 6 cerró prometiendo esta lección, y con razón: ahí encapsulaste lógica que vive dentro de tu instancia de n8n, y quedó abierta la pregunta de qué haces cuando la lógica que necesitas no vive ahí en absoluto. Hoy la respondemos en las dos direcciones —consumir tools de afuera, y dejar que desde afuera trabajen sobre tu n8n—. Una honestidad por delante: MCP no es el eje de esta guía y esta lección no pretende ser un curso de protocolo. Vas a aprender el concepto durable —qué es un cliente, qué es un servidor, qué le estás confiando a cada uno— y los nodos con los que se hace en n8n, no la especificación del transporte, que además está cambiando mientras lees esto. El peso de la guía sigue estando en delegación multi-agente, canales reales y seguridad, que es lo que de verdad te preguntan en una entrevista.

El cable a la medida y el puerto estándar

Piensa en cómo era cargar dispositivos hace quince años. Cada aparato traía su propio cargador con su propio conector: uno para el teléfono, otro para la cámara, otro para el reproductor de música. Si comprabas un aparato nuevo, venía con un cable nuevo, y si perdías el cable no servía ninguno de los otros. Cada fabricante había resuelto el mismo problema —llevar corriente al aparato— de una forma incompatible con todos los demás.

Después llegó un puerto estándar. Ahora el fabricante ya no diseña un conector propio: se acomoda al que todo el mundo usa, y tú enchufas cualquier aparato en cualquier cargador sin pensarlo. El fabricante sigue decidiendo cuánta corriente acepta su aparato y qué hace con ella —eso no se estandarizó—, pero la forma de conectarse sí.

Las tools que construiste en las lecciones 3 a 6 son cables a la medida. El nodo Postgres con su query parametrizada, el nodo Gmail con su destinatario fijo, el sub-workflow de elegibilidad de reembolso: cada uno lo armaste tú, campo por campo, para un sistema específico. Funcionan muy bien y para muchos casos siguen siendo la mejor opción. Pero cada uno es trabajo tuyo de construir y trabajo tuyo de mantener.

MCP —Model Context Protocol— es el puerto estándar. Es un protocolo abierto que define cómo una aplicación que usa un modelo de lenguaje le pregunta a un servicio externo dos cosas: "¿qué herramientas tienes disponibles?" y "ejecuta esta herramienta con estos datos". Nada más. Esa es toda la idea, y es deliberadamente pequeña.

La anatomía tiene dos piezas y conviene tenerlas claras desde ya, porque el resto de la lección se apoya en distinguirlas:

• El cliente MCP es quien tiene el modelo y quiere usar herramientas. Tu agente de n8n puede ser un cliente. Claude Desktop es un cliente. Cursor es un cliente. Claude Code es un cliente.
• El servidor MCP es quien publica el catálogo de herramientas y las ejecuta cuando se lo piden. Notion tiene un servidor MCP. GitHub tiene uno. Y —esto es lo que vas a ver en la segunda mitad de esta lección— tu propia instancia de n8n también puede ser uno.

Lo importante para ti, que estás construyendo agentes y no implementando protocolos: el cliente descubre el catálogo en tiempo de ejecución. No copias la lista de tools a mano. Le das al cliente una dirección, y el cliente pregunta qué hay ahí. Si el proveedor agrega una herramienta nueva la semana que viene, aparece sola. Esa es la diferencia real frente a un cable a la medida, y es el concepto durable de esta lección —el que va a seguir siendo cierto cuando el detalle del transporte haya cambiado tres veces.

Las tres formas de MCP en n8n

Aquí es donde mucha gente se enreda, así que vale la pena fijarlo antes de tocar un solo nodo. n8n participa en MCP de tres formas distintas, y no son intercambiables:

Nota lo que cambia entre la segunda y la tercera fila, porque es el error conceptual más común de esta lección: el MCP Server Trigger expone tools de negocio que tú armaste —"consulta el estado de un pedido"—; el servidor MCP de instancia expone tools de construcción y operación de n8n —"crea un workflow", "valida esta configuración de nodo", "ejecuta este workflow"—. Uno le da a un agente externo acceso a tu lógica; el otro le da acceso a tu taller.

Esta lección se concentra en la primera y la tercera fila, que son las que el módulo te pidió. Del MCP Server Trigger vas a ver lo suficiente para reconocerlo y no confundirlo con el servidor de instancia —es la pieza natural cuando lo que quieres compartir es una capacidad de negocio y no tu instancia entera—, pero no es donde está el jugo de esta lección.

Ejemplo trabajado: el agente de TuTienda registra incidencias en Notion

El equipo de operaciones de TuTienda lleva su bitácora de incidencias en Notion —una base de datos de páginas donde cada incidencia grave queda documentada con su pedido, su cliente y qué pasó—. Hasta ahora, cuando el agente escalaba un caso, escribía la fila en Google Sheets y mandaba el correo (lección 4). Operaciones quiere que además quede la página en Notion, con el formato que ellos ya usan.

Podrías construirlo con el nodo HTTP Request contra la API de Notion: autenticación, endpoint de creación de página, el cuerpo JSON con la estructura de bloques de Notion. Es perfectamente posible y es exactamente el tipo de trabajo que MCP te ahorra. Notion publica su propio servidor MCP, alojado por ellos, y ese servidor ya sabe cómo crear una página bien formada.

Paso 1 — Agrega el nodo MCP Client Tool al puerto ai_tool del agente. Es un sub-nodo, igual que el Postgres o el Gmail de la lección 4: se conecta con la misma línea punteada al mismo puerto. Lo que cambia es que no configuras una acción — configuras una dirección:

# CONEXIÓN ai_tool -> nodo: MCP Client Tool
Endpoint         = "https://mcp.notion.com/mcp"
Authentication   = "OAuth2"
Tools to Include = "Selected"
Tools            = notion-search, notion-create-pages
Description      = "Usa esta herramienta para consultar y registrar
                    incidencias en la bitácora de operaciones de TuTienda,
                    que vive en Notion. Úsala solo cuando un caso ya fue
                    escalado a soporte humano y necesita quedar
                    documentado. No la uses para responderle al cliente
                    ni para consultar el estado de un pedido — para eso
                    existe la herramienta de la base de datos."

Antes de seguir, desarmemos cada campo, porque cada uno es una decisión y no un trámite:

Endpoint es la dirección donde vive el catálogo. Una nota de honestidad sobre este campo: en la documentación de n8n aparece como SSE Endpoint, un nombre heredado de cuando Server-Sent Events era el único transporte que MCP soportaba. Hoy el transporte recomendado es HTTP Streamable, SSE quedó como compatibilidad hacia atrás, y algunas versiones de n8n agregan un selector de transporte junto a la URL. Verifica cómo se llama exactamente el campo en tu versión antes de pegar la dirección. Lo que no cambia —y es lo que tienes que entender— es qué representa: la puerta de entrada al catálogo de tools de ese servidor.

Authentication es cómo pruebas que tienes derecho a usar ese servidor. n8n soporta None (para servidores públicos), Bearer, un header genérico, varios headers a la vez, y OAuth2. Notion, en particular, acepta únicamente OAuth2 — cuando lo configures, n8n te va a mandar a una pantalla de Notion donde autorizas qué espacio de trabajo puede tocar. Ese consentimiento es tuyo y es revocable desde Notion, no desde n8n. Vale la pena saberlo.

Tools to Include es el campo que más gente pasa por alto y el que más importa para lo que aprendiste en la lección 5. Tiene tres opciones: All expone todas las tools que publique el servidor; Selected activa una lista donde eliges cuáles; All Except activa la lista inversa, donde eliges cuáles bloquear. El servidor MCP de Notion publica del orden de dieciocho herramientas —buscar, leer, crear páginas, actualizar páginas, moverlas, duplicarlas, crear bases de datos, comentar, consultar usuarios—. Si dejas All, tu agente de atención al cliente queda con la capacidad de mover y duplicar páginas del espacio de trabajo de la empresa porque alguien escribió algo raro en el chat. Poner Selected con notion-search y notion-create-pages no es un ajuste cosmético: es exactamente el límite de confianza de la lección 5, aplicado a un catálogo que tú no escribiste.

Description es el mismo contrato de siempre. El agente no ve el catálogo de Notion como lo ves tú; ve lo que el servidor declara de cada tool, más lo que tú escribas acá sobre cuándo usar este bloque de herramientas y cuándo no. Nota que la descripción de arriba dice explícitamente qué no hacer con ella, y remite a la tool que sí corresponde para el estado de un pedido. Eso previene el problema de tools que se disputan la misma intención que viste en la lección 5.

Paso 2 — Ponlo a prueba con un caso real. Con el workflow publicado, manda un mensaje que claramente sea una incidencia grave y no una consulta rutinaria:

curl -X POST "<tu Chat URL, pestaña Production>" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "sendMessage",
    "sessionId": "tab-mcp-notion",
    "customerPhone": "+52-55-8811-2299",
    "chatInput": "El pedido #4521 llegó abierto y con la caja mojada. Ya reclamé dos veces y nadie me responde."
  }'

Qué esperar. El agente reconoce que esto no se resuelve con la tool de consulta, escala el caso —fila en Sheets, correo al equipo, como en la lección 4— y además llama a notion-create-pages a través del MCP Client Tool, con el título y el contenido que él redacta a partir del mensaje. La respuesta al cliente se ve como cualquier otra:

{ "output": "Lamento mucho lo que pasó con el pedido #4521. Ya dejé el caso documentado y avisé al equipo de operaciones para que alguien te contacte hoy mismo. Vas a recibir respuesta directa, no por este chat." }

Lo que confirma que de verdad ocurrió está en dos lugares, y conviene mirar los dos. En el panel de ejecución de n8n, el nodo MCP Client Tool aparece como un paso ejecutado, y adentro vas a ver el nombre de la tool que el modelo eligió del catálogo del servidor —notion-create-pages— junto con los argumentos exactos que le mandó. Eso es lo que hace tan distinto depurar MCP frente a depurar un nodo normal: un solo nodo en tu lienzo puede haber ejecutado cualquiera de las tools que habilitaste, y el panel te dice cuál. Lo segundo es abrir Notion y ver la página nueva en la bitácora. Como en la lección 4 con Gmail y Sheets: el sistema real vive fuera de tu Docker y la verificación honesta es mirarlo.

Fíjate en lo que no hiciste en ningún momento: no escribiste un solo campo de la estructura de bloques de Notion, no buscaste el ID de la base de datos, no armaste un cuerpo JSON. El servidor de Notion publicó una herramienta que sabe hacer eso, y tu agente la descubrió sola. Ese es el ahorro.

Una frontera vale la pena dejarla marcada: esto no es que el agente lea tus documentos. notion-search busca en el espacio de trabajo con la búsqueda que Notion ya tiene, igual que si tú escribieras en su barra de búsqueda. No hay embeddings, no hay fragmentación de documentos, no hay recuperación semántica sobre PDFs o facturas. Eso es un problema distinto y pertenece a otra guía del ecosistema. Aquí el agente actúa sobre un sistema, como lo viene haciendo desde la lección 4.

El sentido inverso: tu instancia de n8n como servidor MCP

Hasta aquí, tu n8n fue el que va a la ferretería a buscar herramientas. Ahora vamos a abrir el mostrador.

Piensa en la diferencia entre prestarle una herramienta a un vecino y darle la llave del taller. Prestar la herramienta es acotado: le das el taladro, sabes qué puede hacer con él, y te lo devuelve. Darle la llave del taller es otra categoría de decisión: puede usar cualquier herramienta, moverlas de lugar, empezar proyectos nuevos, y también dejar todo desordenado. Ninguna de las dos cosas es mala en sí. Lo grave es hacer la segunda creyendo que hiciste la primera.

Prestar la herramienta es el MCP Server Trigger: un workflow que empieza con ese nodo expone al mundo exterior las tools que le conectes, y nada más. Si le conectas la tool de consultar pedidos, un cliente MCP externo puede consultar pedidos. Es acotado por diseño. Es la opción correcta cuando lo que quieres compartir es una capacidad de negocio concreta.

Dar la llave del taller es el servidor MCP de instancia, la novedad grande de n8n 2.0 en este terreno. No es un nodo: es un ajuste de la instancia completa. Cuando lo activas, un cliente MCP puede conectarse a tu n8n y usar herramientas para trabajar sobre n8n mismo: buscar workflows, ver el detalle de uno, crear uno nuevo a partir de una descripción en lenguaje natural, actualizarlo, validarlo, probarlo con datos fijados, publicarlo, ejecutarlo, revisar ejecuciones pasadas, y administrar tablas de datos.

Dicho de otra forma: le describes a Claude Desktop lo que quieres que haga un workflow, y el workflow aparece construido en tu instancia, listo para que lo abras en el lienzo y lo revises. Ya no construyes en el lienzo y después le agregas un modelo; ahora también puedes conversar con un modelo y que él construya en el lienzo.

Qué herramientas expone el servidor de instancia

Conviene ver el catálogo, aunque sea agrupado, porque la lista misma te dice qué le estás entregando a quien conectes:

Lee esa tabla otra vez con el criterio de la lección 5 en la cabeza —reversibilidad, impacto, quién paga el error— y vas a ver por qué esto merece cuidado. create_workflow_from_code crea. update_workflow modifica lo que ya existe. publish_workflow pone algo en producción. Y execute_workflow corre la versión publicada del workflow, es decir, en modo producción: si ese workflow manda correos reales o escribe en tu base de datos de negocio, los manda y escribe de verdad. La mayoría de las otras tools trabajan sobre versiones sin publicar, que es un buen resguardo; execute_workflow es la excepción que hay que tener presente.

Ejemplo trabajado: habilitar el servidor de instancia y construir un workflow conversando

Paso 1 — Habilita MCP a nivel de instancia. En n8n, ve a Settings → Instance-level MCP y activa Enable MCP access. Necesitas ser owner o admin de la instancia; si el botón no te aparece, ese es el motivo, no un problema de versión.

Paso 2 — Habilita los workflows uno por uno. Este es el detalle que sorprende a mucha gente: activar MCP en la instancia no expone nada todavía. Cada workflow tiene además su propio interruptor Available in MCP, que puedes activar desde el menú del propio workflow o desde el botón Enable workflows en la misma pantalla de ajustes.

¿Por qué dos interruptores para lo mismo? Porque no son lo mismo. El primero decide si tu instancia acepta conexiones MCP en absoluto; el segundo decide, workflow por workflow, cuáles quedan a la vista. Es un opt-in explícito, y está bien que lo sea: si fuera un solo interruptor, activarlo pondría al alcance de un cliente externo todos los workflows de producción de tu empresa de un plumazo.

Paso 3 — Toma los datos de conexión. En esa misma pantalla, la sección de detalles de conexión te muestra la URL base de tu servidor MCP, con esta forma:

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

Para autenticarte tienes dos caminos. OAuth2 es el recomendado: pegas la URL en el cliente, el cliente te manda a n8n a autorizar, y listo — no hay ningún secreto que copiar y pegar. Token de acceso MCP es la alternativa: n8n te genera un token personal la primera vez que entras a esa pantalla, y lo pegas en el cliente junto con la URL. Trata ese token con el mismo cuidado que una contraseña de administrador, por el motivo que ya viste en la tabla de arriba.

Paso 4 — Conecta tu cliente. Depende de cuál uses:

# Claude Code — conexión por HTTP con OAuth2
claude mcp add --transport http n8n-mcp https://<tu-dominio-n8n>/mcp-server/http

# Codex CLI
codex mcp add n8n-mcp --url https://<tu-dominio-n8n>/mcp-server/http

En Claude Desktop no es un comando sino la interfaz: Settings → Connectors → Add custom connector, le pones un nombre (por ejemplo, n8n MCP) y pegas la URL base de tu instancia. El flujo de autorización se abre solo.

Una advertencia práctica que ahorra media hora de frustración: el cliente tiene que poder alcanzar esa URL por red. Si tu n8n corre en Docker en tu laptop, en http://localhost:5678, un cliente que también corre en tu laptop —Claude Desktop, Claude Code, Cursor— llega sin problema. Un cliente que vive en la nube, como ChatGPT en el navegador, no puede alcanzar tu localhost: para eso necesitas que tu instancia tenga una dirección pública, con HTTPS. No es una limitación de MCP, es cómo funcionan las redes — pero es el tropiezo número uno de quien prueba esto por primera vez en una instancia self-hosted.

Paso 5 — Pídele algo concreto. Con el cliente conectado, en vez de abrir el lienzo, escribes:

"En mi instancia de n8n, crea un workflow llamado Weekly Escalations Digest que corra cada lunes a las 8 de la mañana, lea la hoja 'Casos' de la planilla 'Escalaciones TuTienda' filtrando las filas de los últimos 7 días, y mande un correo con el conteo y la lista al equipo. Déjalo sin publicar."

Qué esperar. No vas a ver un workflow aparecer instantáneamente: vas a ver al cliente trabajar en varios pasos, y esos pasos son las tools de la tabla de arriba en acción. Típicamente consulta search_nodes para averiguar qué nodo corresponde a un disparador por horario y cuál a Google Sheets, pide get_sdk_reference para saber cómo se declara la configuración, arma la definición, la pasa por validate_workflow —y si algo no cuadra, corrige y vuelve a validar—, y recién entonces llama a create_workflow_from_code. Al terminar te da el ID o el nombre del workflow creado.

Ahora la parte que no debes saltarte: abre n8n y revísalo con tus propios ojos. Vas a encontrar el workflow en la lista, sin publicar, con sus nodos armados en el lienzo. Ábrelo, verifica que la credencial de Google Sheets sea la correcta, que el filtro de fechas diga lo que tú querías decir, y que el destinatario del correo sea el que corresponde. Que un modelo lo haya construido no cambia nada de lo que aprendiste en las seis lecciones anteriores sobre revisar antes de confiar — al contrario, lo hace más necesario.

Fíjate también en lo que pediste explícitamente: "déjalo sin publicar". Es un buen hábito. Publicar es lo que pone el workflow en producción, y esa decisión conviene que la tomes tú después de mirarlo, no el modelo mientras construye.

La pieza del medio: prestar una herramienta con MCP Server Trigger

Entre consumir tools de afuera y entregar la llave del taller está el caso intermedio, y conviene que lo veas aunque no sea el foco de esta lección: compartir una capacidad de negocio tuya, y solo esa.

El MCP Server Trigger es un nodo trigger, es decir, va al principio de un workflow, como el Chat Trigger que usas desde el Módulo 1. Pero se comporta distinto a cualquier otro trigger que hayas visto: en vez de recibir un evento y pasarle datos a los nodos que siguen, no tiene nodos que sigan. Lo único que se le conecta son tools, por el mismo tipo de conexión punteada con la que llenas el puerto ai_tool de un agente.

Piénsalo como una caja de herramientas con tu nombre puesto en la puerta. Adentro pones exactamente las herramientas que quieres prestar —ni una más—, y quien llegue con la dirección correcta puede ver qué hay y usar lo que necesite. No puede abrir otras cajas ni entrar al taller.

# Workflow: "TuTienda Support Tools"

  ┌──────────────────────┐
  │  MCP Server Trigger  │   ← este nodo NO tiene salida hacia otros nodos
  │  Path: /tutienda     │
  │  Auth: Bearer        │
  └──────────┬───────────┘
             │ conexión de tools
      ┌──────┴───────┐
      │              │
 ┌────▼─────┐  ┌─────▼──────────┐
 │ Postgres │  │ Call n8n       │
 │ (consul- │  │ Workflow Tool  │
 │  tar     │  │ (elegibilidad  │
 │  pedido) │  │  de reembolso) │
 └──────────┘  └────────────────┘

El nodo te da dos direcciones, con la misma lógica que ya conoces del Chat Trigger: una URL de prueba, que funciona mientras el workflow no está publicado y te deja ver los datos en el lienzo, y una URL de producción, que queda registrada al publicarlo y cuyos datos se ven en la pestaña de ejecuciones. El Path viene generado al azar y puedes cambiarlo por uno estable. La autenticación admite Bearer o un header, y conviene ponerla: sin ella, cualquiera con la dirección usa tus tools.

Qué esperar. Un agente de otro equipo —o tu propio Claude Desktop— se conecta a esa URL con un MCP Client Tool, pregunta qué hay, y recibe exactamente dos herramientas: consultar un pedido y evaluar elegibilidad de reembolso. Nada de lo demás que vive en tu instancia aparece en esa lista. Si mañana el equipo de finanzas necesita también consultar reembolsos ya emitidos, agregas esa tool al mismo trigger y aparece sola del otro lado, sin que nadie reconfigure su cliente.

La comparación con lo que viene a continuación es la que te tienes que llevar: aquí decides herramienta por herramienta qué se comparte, y todo lo que no conectaste sigue siendo invisible. En el servidor de instancia no eliges herramientas, eliges workflows, y las herramientas que se exponen son las de construir y operar n8n. Son dos niveles de acceso muy distintos con nombres parecidos.

El límite de confianza del servidor de instancia

Vale la pena decir con todas las letras lo que implica dejar esto abierto, porque es una decisión de seguridad y no de configuración.

Todos los clientes que conectes ven todos los workflows que hayas habilitado. No puedes decir "Claude Desktop sí puede ver este workflow pero ChatGPT no". El interruptor Available in MCP es por workflow, no por cliente. Si habilitas el workflow de facturación para que un cliente te ayude a depurarlo, queda habilitado para cualquier cliente que tenga acceso a tu servidor MCP.

Un cliente conectado puede modificar, no solo leer. update_workflow y publish_workflow están en el catálogo. La capacidad que estás entregando no es "consultar mi n8n", es "trabajar sobre mi n8n".

De ahí un criterio práctico, en la línea de la tabla de reversibilidad de la lección 5: habilita el servidor MCP de instancia en tu entorno de desarrollo, no en el de producción, y habilita en él solo los workflows que estés construyendo activamente. Cuando termines de trabajar en uno, quítale el Available in MCP. Es el mismo hábito de higiene que aplicarías a cualquier acceso administrativo: se otorga acotado y se retira cuando ya no hace falta.

Cuándo MCP no es la respuesta

MCP es una herramienta más, no un ascenso de categoría. Un agente que consume tres servidores MCP no es mejor que uno con tres tools nativas bien construidas — es distinto, y a veces peor. Este es el criterio que te sirve para decidir, y es la parte de esta lección que más se te va a quedar:

La pregunta que resuelve casi todos los casos dudosos es simple: ¿quién es dueño de la lógica que necesito? Si es tuya, se queda en n8n. Si es de otro, MCP es el puerto por donde entra.

Errores comunes

Conectar un servidor MCP con Tools to Include = All sin leer el catálogo (conceptual). Qué pasa: alguien conecta el servidor MCP de Notion para que el agente registre incidencias, deja el campo en su valor por omisión, y sin darse cuenta le dio al agente de atención al cliente dieciocho herramientas —incluidas mover páginas, duplicarlas y crear bases de datos nuevas en el espacio de trabajo de la empresa—. Por qué pasa: el nodo se ve como un solo nodo en el lienzo, así que la intuición dice "conecté una tool"; en realidad conectaste un catálogo completo, y el tamaño de ese catálogo lo decide el proveedor, no tú. Además cada tool habilitada ocupa lugar en el contexto que el modelo recibe, así que un catálogo grande hace que el modelo elija peor entre todas las tools, no solo entre las de MCP. Cómo detectarlo: abre el nodo MCP Client Tool, cambia Tools to Include a Selected y mira la lista que se despliega — esa es la lista real de lo que tu agente puede hacer hoy con ese servidor. Cómo corregirlo: usa Selected con las tools mínimas que el caso de uso necesita, o All Except para bloquear explícitamente las destructivas; es el mismo criterio de la tabla de reversibilidad de la lección 5, aplicado a un catálogo que no escribiste tú.

Confundir el MCP Server Trigger con el servidor MCP de instancia (conceptual). Qué pasa: alguien quiere que Claude Desktop le ayude a construir workflows, agrega un MCP Server Trigger a un workflow vacío, conecta Claude Desktop a esa URL, y desde el cliente no aparece ninguna herramienta útil — no hay forma de crear un workflow desde ahí. Por qué pasa: los dos se llaman "servidor MCP" y los dos hacen que n8n sea un servidor, pero exponen cosas de naturaleza distinta. El MCP Server Trigger expone las tools que tú le conectas a ese workflow: si no le conectaste ninguna, no expone nada, y aunque le conectes varias, siguen siendo tools de negocio. El servidor MCP de instancia expone las herramientas de construcción y operación de n8n, y no se activa con un nodo sino en Settings. Cómo detectarlo: pregúntate qué quieres que el cliente externo pueda hacer — si la respuesta es "usar una capacidad que ya construí", es el trigger; si es "construir cosas nuevas en mi n8n", es el de instancia. Cómo corregirlo: para construir workflows conversando, ve a Settings → Instance-level MCP, activa Enable MCP access, y conecta el cliente a https://<tu-dominio-n8n>/mcp-server/http.

Tratar el token de acceso MCP de instancia como una llave de solo lectura (práctico). Qué pasa: alguien genera el token, lo pega en un cliente que corre en una máquina compartida —o lo manda por chat a un compañero para que "también pueda ver los workflows"—, con la idea de que a lo sumo estará leyendo configuraciones. Después aparece un workflow modificado, o publicado, sin que nadie recuerde haberlo tocado en el lienzo. Por qué pasa: el catálogo del servidor de instancia incluye update_workflow, publish_workflow y execute_workflow — quien tiene el token tiene capacidad de escritura y de ejecución en producción, no solo de consulta. Cómo detectarlo: revisa el historial de ejecuciones y de cambios de los workflows que tengas habilitados en MCP; una ejecución que nadie disparó desde el lienzo ni desde un trigger real es la señal. Cómo corregirlo: prefiere OAuth2 sobre el token cuando el cliente lo soporte —así cada persona autoriza con su propia cuenta y puedes revocar individualmente—, habilita el servidor de instancia en desarrollo y no en producción, y quítale Available in MCP a cada workflow apenas termines de trabajar en él.

Pegar la URL de un servidor MCP en un campo que espera otro transporte (práctico). Qué pasa: configuras el MCP Client Tool con la URL de un servidor moderno, y el nodo se queda colgado, falla al listar las tools, o —en el peor caso reportado— entra en un ciclo de reintentos que dispara una cantidad absurda de peticiones. Por qué pasa: MCP soporta más de un transporte. SSE fue el original y quedó como compatibilidad hacia atrás; HTTP Streamable es el recomendado hoy. Algunos servidores exponen dos direcciones distintas —una para cada transporte— y el campo de n8n conserva el nombre heredado SSE Endpoint, lo que hace fácil pegar la dirección equivocada o asumir un transporte que el servidor ya no habla. Cómo detectarlo: si el nodo no logra listar las tools del servidor, o el panel de ejecución muestra reintentos en cadena, es casi siempre esto y no un problema de autenticación. Cómo corregirlo: busca en la documentación del proveedor cuál es la dirección para cada transporte —el servidor de Notion, por ejemplo, publica una para HTTP Streamable y otra terminada en /sse— y verifica en tu versión de n8n si el nodo trae un selector de transporte; si lo trae, la URL y el selector tienen que coincidir.

Ejercicios

Ejercicio 1 — Elige el mecanismo. Para cada uno de estos cuatro encargos, decide cuál de las cuatro piezas corresponde —nodo nativo como tool, sub-workflow como tool, MCP Client Tool, o servidor MCP de instancia— y justifica en una frase:

(a) El agente debe poder escribir una fila en la planilla de escalaciones de Google Sheets. (b) El agente debe decidir si un pedido califica para reembolso aplicando la política con excepciones por categoría. (c) El agente debe poder crear un issue en el repositorio de GitHub del equipo de producto, que ya publica su propio servidor MCP. (d) Quieres pedirle a Claude Code que te arme un workflow nuevo de reportes semanales sin abrir el lienzo.

Ejercicio 2 — Acota el catálogo. Conectas el servidor MCP de Notion al agente de soporte de TuTienda. El catálogo incluye, entre otras: notion-search, notion-fetch, notion-create-pages, notion-update-page, notion-move-pages, notion-duplicate-page, notion-create-database, notion-update-database, notion-create-comment, notion-get-comments. El único trabajo del agente con Notion es dejar documentada una incidencia cuando escala un caso, y poder revisar si esa incidencia ya existía. Escribe la configuración de Tools to Include y justifica qué dejaste fuera y por qué.

Tools to Include = "Selected"
Tools            = notion-search, notion-create-pages

Ejercicio 3 — Diagnostica el acceso. En TuTienda alguien activó el servidor MCP de instancia en la instancia de producción y habilitó Available in MCP en todos los workflows para "poder revisarlos rápido desde el chat". Una persona nueva del equipo conectó su cliente MCP con el token que le compartieron y le pidió: "prueba el workflow de notificaciones para ver si funciona". Al día siguiente hay clientes que recibieron un correo de escalación que no correspondía. ¿Qué pasó, y qué tres cosas cambiarías en la configuración?

Resumen y siguiente paso

En esta lección viste MCP en sus dos direcciones. Hacia afuera, el MCP Client Tool conecta tu agente al catálogo que publica un servidor externo: le das una dirección, una forma de autenticarte y —lo más importante— acotas con Tools to Include qué parte de ese catálogo queda realmente al alcance del modelo. Hacia adentro, el servidor MCP de instancia abre tu n8n para que Claude Desktop, ChatGPT, Cursor o Claude Code busquen, construyan, validen, prueben y ejecuten workflows dentro de tu instancia, con un doble interruptor —Enable MCP access a nivel instancia, Available in MCP por workflow— que existe precisamente porque lo que se entrega ahí es la llave del taller.

Antes de avanzar deberías poder: explicar en una frase la diferencia entre un cliente y un servidor MCP, y decir cuál es n8n en cada uno de los tres casos de la tabla; distinguir el MCP Server Trigger del servidor MCP de instancia por lo que expone cada uno; acotar el catálogo de un servidor externo con criterio de reversibilidad en vez de dejarlo en All; y decidir, ante un encargo nuevo, si corresponde nodo nativo, sub-workflow o MCP, respondiendo primero de quién es la lógica.

Con esto cierras el recorrido conceptual del módulo. Tienes el mecanismo de tool calling (lección 2), el catálogo nativo (lección 3), la conexión a sistemas reales (lección 4), el contrato y los límites de confianza (lección 5), la encapsulación en sub-workflows (lección 6) y las tools que vienen de afuera (esta). Lo que falta es lo único que de verdad demuestra que lo tienes: armarlo. La próxima lección es el mini-proyecto del módulo — un agente con tres tools que buscan, crean y envían sobre sistemas reales, verificado de punta a punta, no por lo que el agente dice que hizo sino por lo que puedes comprobar que pasó.

Recursos

• MCP Client Tool node — n8n Docs — referencia del sub-nodo: el campo del endpoint, los métodos de autenticación y las tres opciones de Tools to Include.
• MCP Server Trigger node — n8n Docs — el nodo que expone las tools de un workflow como servidor MCP, con sus URLs de prueba y producción.
• Use n8n MCP server — n8n Docs — qué es el servidor MCP de instancia y qué permite hacer desde un cliente externo.
• Connect to n8n MCP server — n8n Docs — la URL /mcp-server/http, OAuth2 frente al token de acceso, y los pasos de conexión para Claude Desktop, Claude Code y Codex CLI.
• MCP server tools reference — n8n Docs — el catálogo completo de tools del servidor de instancia, incluida la nota de que execute_workflow corre en modo producción.
• Model Context Protocol — sitio oficial — la especificación del protocolo: qué es un cliente, qué es un servidor, y cómo se descubren las tools. Útil si quieres ver qué hay debajo de los nodos.
• Notion MCP server — Notion — el servidor alojado del ejemplo de esta lección: su dirección, su autenticación por OAuth y el catálogo de tools que publica.