Hace unos meses armar un flujo complejo en n8n me tomaba tardes enteras: buscar el nodo correcto, adivinar la expresión, correr, ver que se rompía, volver a empezar. Hoy le pido a Claude Code que revise un flujo, lo compare contra la documentación oficial y me proponga el arreglo, y él lo hace sobre mi instancia real, no en un chat aparte. La pieza que cambió todo se llama MCP, y en este artículo te cuento cómo la uso para construir y mantener un chatbot que hoy atiende a un cliente de verdad.
Si vienes de cero, te sirven dos lecturas previas: qué es n8n y cómo automaticé mi negocio con él y qué es Claude Code y por qué no es solo para programadores. Acá no repito nada de eso. Voy directo a la combinación.
Qué cambia cuando el agente toca tu instancia y no te pega un JSON
Un chat te devuelve un archivo para que lo pegues; un agente conectado por MCP lee tu instancia, consulta la documentación, valida, escribe y revisa la ejecución. Esa es toda la diferencia, y es enorme. MCP (Model Context Protocol) es el estándar que le permite a un modelo de IA usar herramientas externas de forma ordenada. En el caso de n8n, esas herramientas son “listar mis flujos”, “leer este nodo”, “buscar en la documentación”, “validar este flujo”, “actualizarlo” y “ver la última ejecución”.
Antes de esto, el camino habitual era pedirle a ChatGPT un flujo de n8n, recibir un JSON, importarlo y descubrir que traía nodos de una versión que no existe. La comunidad de n8n tiene hilos enteros con ese título: “los flujos generados por IA siempre se rompen”. El modelo no era tonto: trabajaba a ciegas, sin ver qué nodos tienes ni qué pasó en la última ejecución.
Con MCP el agente deja de adivinar. Es la misma lógica que expliqué cuando conté cómo Claude Code configura al agente que vive en mi servidor: un agente que sabe razonar opera a otro sistema que sabe ejecutar. Aquí el sistema que ejecuta es n8n.
Mi puesto de trabajo: dos MCP, siete skills y la documentación a mano
No conecté una cosa, conecté tres: el acceso a la instancia, el conocimiento de n8n y mi propia documentación. Cada una resuelve un problema distinto y, juntas, es cuando el agente empieza a rendir.
| Pieza | Qué le da al agente |
|---|---|
| MCP oficial de n8n | Acceso a mi instancia en vivo: leer, crear, actualizar y ejecutar flujos. Es el que n8n activa desde su propia configuración y se conecta con Claude Code con un solo comando |
| MCP comunitario n8n-mcp | Conocimiento: la documentación de cada nodo, miles de plantillas de referencia y herramientas para validar un flujo antes de guardarlo |
| Siete skills de n8n | Instrucciones de oficio: cómo escribir expresiones, cómo configurar nodos, los errores típicos de los nodos de código |
| Mi vault de Obsidian | La documentación oficial de n8n guardada en mis notas, para que el agente la lea antes de afirmar cómo funciona algo |
El MCP oficial es el más nuevo y el que más me entusiasma: n8n lo sacó de vista previa este año y, desde su versión 2.32, deja elegir qué puede tocar el cliente (todo, solo lectura o un recorte a medida). El comunitario, en cambio, es el que trae el conocimiento. En la comunidad se discute cuál de los dos conviene, como si fueran excluyentes. No lo son. Uno le da manos, el otro le da memoria de oficio.
Todo eso vive en una carpeta de mi computador que funciona como el “puesto del especialista en n8n”. Cuando abro Claude Code ahí, ya sabe qué instancia es, qué reglas rigen y dónde buscar antes de proponer. Es la misma idea de mi equipo de agentes de contenido: el valor está en lo que el agente tiene cargado antes de trabajar.
La regla que le escribí antes de dejarlo proponer nada
Antes de tocar un flujo, el agente consulta en este orden: la documentación oficial, después las plantillas probadas, y al final mis propios flujos en producción. Y tiene que decirme qué consultó y qué artículo respalda la decisión. Esa regla está escrita en el archivo de instrucciones de la carpeta, y es la que más rinde de todo el montaje.
La razón es simple: un modelo de IA “recuerda” cómo funcionaba un nodo hace un año, y n8n cambia cada semana. Sin esa regla, el agente propone con seguridad cosas que ya no son así. Con ella, primero lee y después opina.
La segunda regla es de alcance. Una cosa pedida, una cosa entregada. Si le pido revisar un flujo, revisa ese flujo: no “optimiza” otros de paso, no activa ni desactiva nada, no crea credenciales que nadie pidió. Si se le ocurre algo mejor, lo propone en una línea y espera mi respuesta. En una instancia con clientes, eso es seguridad, no cortesía.
El sistema que construí para un cliente: tres flujos y una base
Con ese puesto armado, construí el chatbot del sitio web de un cliente, un instituto de formación con cursos, diplomados y una biblioteca de publicaciones. No es un flujo, son tres que trabajan juntos sobre una base de datos en Supabase:
- El agente conversacional. Recibe la pregunta del visitante, clasifica la intención, arma el contexto y responde. Hoy tiene 25 nodos y memoria de conversación en Postgres.
- El sincronizador del catálogo. Todas las madrugadas lee los cursos de la tienda del cliente, los cruza con la vitrina del sitio y actualiza la tabla: cuáles se venden ya, cuáles se mencionan como consulta.
- La biblioteca semántica. Media hora después, revisa qué publicaciones nuevas hay, procesa solo lo que cambió y las deja buscables. Hoy son 752 fragmentos de 210 documentos, cada uno etiquetado con la rama del menú del sitio a la que pertenece.
El agente, además, tiene tres herramientas propias: listar publicaciones por autor o tipo, consultar el catálogo de cursos y buscar en la biblioteca por su cuenta cuando le falta información. Antes recibía un contexto pre-armado de una sola pasada; ahora, si le preguntan “todas las columnas de tal autor”, va y las busca. Y cuando una consulta exige a una persona, deriva la conversación por WhatsApp al equipo del cliente, con el criterio que conté en cuándo un chatbot debe callarse y pasar a una persona.
Qué hizo el agente solo y qué hizo conmigo mirando
Claude Code hizo el trabajo pesado de diagnóstico y construcción; yo decidí cada cambio que tocaba producción. Esa división no es modestia, es diseño. Ejemplos concretos de lo que hizo por el MCP:
- Auditó los cuatro flujos de ingesta y encontró que la biblioteca llevaba semanas congelada sin que nadie lo notara.
- Leyó el historial de ejecuciones para diagnosticar causas reales, en vez de suponerlas. Un fallo que yo atribuía al modelo resultó ser mitad culpa nuestra, mitad del proveedor.
- Buscó en la documentación y en el código fuente de n8n por qué unos parámetros marcados como opcionales se comportaban como obligatorios, y encontró el bug abierto en el repositorio oficial.
- Escribió los nodos de código, los aplicó sobre una copia del flujo y corrió las pruebas antes de proponerme pasarlo a producción.
Lo que no hizo solo: escribir en el flujo productivo. Cada cambio pasó por un respaldo del flujo a disco, una explicación de una línea y mi “ok”. Hubo una vez en que el propio agente abortó una escritura porque detectó que el flujo había cambiado bajo la sesión mientras yo lo editaba desde la interfaz. Si hubiera seguido, habría pisado mi trabajo sin darse cuenta. Ese freno lo defiendo más que cualquier función nueva.
Las fallas que ningún tutorial cuenta
Todo lo que sigue apareció operando de verdad, y ninguno de los videos de “conéctalo en un minuto” lo menciona.
| La falla | Qué pasaba | El arreglo |
|---|---|---|
| El modelo no sabe comparar fechas | Afirmó con total aplomo que el 14 de abril de 2026 era anterior al 9 de febrero de 2026 y mandó dos cursos al año 2027 | El año lo calcula código, no el modelo. A la IA se le pide texto, nunca aritmética de calendario |
| El filtro que no filtraba | Un nodo de condición tenía la constante “verdadero”: hasta un “hola” pagaba búsqueda semántica y reordenamiento | Clasificador por intención con una tabla de qué fuente consulta cada tipo de pregunta |
| Parámetros “opcionales” que no lo eran | En n8n, todo parámetro que llena la IA sin valor por defecto queda obligatorio; escribir “opcional” en la descripción no hace nada. Tres de seis respuestas mudas venían de ahí | Valor por defecto en los ocho parámetros y salida de error en el nodo del agente, con una respuesta de cortesía que deriva a WhatsApp |
| Un signo perdido al migrar el nodo | Al pasar el prompt a una versión nueva del nodo del agente se perdió el signo que marca una expresión. El flujo corrió “en verde” 21 minutos mandando texto literal en vez del catálogo | Se comprueba en una ejecución real, no se confía en que “corrió bien” |
| Un 200 con cuerpo vacío | El visitante veía la pantalla en blanco y ningún sistema avisaba, porque el código HTTP era correcto | Se mide el cuerpo de la respuesta, no solo el código |
Fíjate en el patrón: ninguna de estas fallas era de “no saber n8n”. Eran de operar un sistema con IA adentro, donde el modelo hace cosas que parecen correctas y no lo son. La herramienta no reemplaza el criterio; te da tiempo para ejercerlo.
Cómo pruebo antes de decir “listo”
Un chatbot no está listo cuando responde bien a la pregunta que le hiciste tú; está listo cuando responde bien a las que le van a hacer los demás. Así que armé una batería de 17 preguntas, una por cada rama del menú del sitio del cliente, y la corro completa contra el flujo cada vez que algo cambia.
La primera pasada dio 11 de 17. Las otras seis devolvían un 200 vacío. Después de los arreglos de la tabla anterior, 17 de 17, cero pantallas en blanco y todas las ejecuciones en estado correcto. Ese número es el que le muestro al cliente, no una captura de una conversación bonita.
Con el mismo método decidí el “cerebro” del agente. En producción, una consulta de cursos tardaba 69,9 segundos con el modelo original; la copia de prueba con otro modelo respondía la misma consulta en 14. Se cambió con el dato en la mano, igual que cuando probé cuatro modelos como cerebro de mi agente. Sin medir, habría seguido culpando a n8n de una lentitud que era del modelo.
Dónde le puse los frenos
El agente opera en modo lectura por defecto; toda escritura en la instancia necesita respaldo previo y mi autorización explícita. Son cuatro frenos y los cuatro están escritos, no en mi cabeza:
- Lectura por defecto. Listar, leer, buscar y validar no piden permiso. Crear, actualizar, activar o borrar, sí.
- Respaldo antes de tocar. El JSON del flujo se guarda a disco con fecha antes de cualquier cambio. Tengo una carpeta con más de treinta respaldos de este proyecto.
- Copia primero. Los cambios grandes se hacen sobre una copia del flujo, se prueban ahí y recién después se llevan al productivo conservando la dirección pública del chat.
- Nada de credenciales en el chat. Las claves viven en la configuración de Claude Code, fuera de cualquier archivo que se sincronice, y el agente tiene prohibido citarlas.
Alguien en X lo resumió mejor que yo esta semana, hablando justamente del MCP nativo de n8n: “agrega una aprobación manual antes de que se envíe cualquier cosa importante y prueba primero con datos falsos”. Eso. La velocidad que da el agente se paga con disciplina en la puerta de salida.
Qué le pediría un dueño de PyME a esto, y qué todavía no
Si ya tienes n8n y una persona de confianza que lo opere, esta combinación vale la pena hoy; si no tienes ninguna de las dos cosas, empieza por otro lado. Te lo digo con el 70 % de las PyMEs chilenas declarando que ya incorporaron IA, según el estudio de Entel Digital y el CENIA, mientras SONDA mide que solo un 15,8 % la usa de forma activa. La distancia entre esos dos números es exactamente el problema que resuelve un sistema como este: pasar de “probé una herramienta” a “algo trabaja solo y alguien lo sostiene”.
Lo que sí le pediría: que construya los flujos que antes no te atrevías a encargar por complejos, que te diga por qué falló algo leyendo la ejecución en vez de que tú abras nodo por nodo, y que mantenga vivos los flujos cuando cambia una API o una versión. Lo que todavía no: que corra sin nadie mirando. Un agente con acceso a tu instancia puede borrar un flujo con la misma facilidad con que lo crea. El propio proyecto comunitario abre su documentación con una advertencia de seguridad que dice, palabra más palabra menos, lo mismo que mis cuatro frenos.
Y una aclaración que me hacen seguido: esto no compite con tener tu propio agente tipo Jarvis. Se complementan: n8n corre lo repetitivo barato y predecible; Claude Code lo diseña, lo arregla y lo mejora conmigo.
Cómo empezar sin romper lo que ya te funciona
Empieza en modo lectura, sobre una copia, con una sola tarea concreta. Lo recomiendo después de haberlo hecho al revés más de una vez:
- Activa el MCP oficial en tu instancia de n8n y conéctalo a Claude Code con permiso de solo lectura. Pídele que te explique tus flujos actuales.
- Suma el conocimiento: el MCP comunitario y las skills de n8n. Sin eso, el agente tiene manos pero no oficio.
- Escríbele las reglas en el archivo de instrucciones de la carpeta: qué consulta primero, qué no toca, cuándo pregunta.
- Dale una tarea de mantenimiento, no una de creación: “este flujo falló ayer, dime por qué”. Ahí vas a ver la diferencia con un chat.
- Recién entonces abre la escritura, sobre una copia, con respaldo y con tu ok en cada cambio.
Suena accesible, y en parte lo es: la conexión toma minutos. Lo que no toma minutos es el sistema alrededor, las reglas, las pruebas de 17 preguntas, los frenos y el criterio de cuándo el modelo no debe decidir. Eso es lo que hace que un chatbot pase de demo bonita a atender clientes todos los días.
Recursos que menciono en este artículo
Todo lo que usé es público y gratuito; lo que cuesta es el criterio para armarlo. Estos son los tres enlaces que necesitas para replicar el puesto:
- MCP oficial de n8n: la documentación de n8n para activar el acceso MCP a nivel de instancia y conectar Claude Code, con OAuth y permisos por alcance.
- n8n-mcp, el MCP comunitario: el repositorio de código abierto que le da al agente la documentación de nodos, las plantillas y la validación de flujos. Lee su advertencia de seguridad antes de instalarlo.
- n8n-skills: las siete skills de n8n para Claude Code que complementan al MCP con instrucciones de oficio.
Si tienes n8n corriendo y quieres que un agente lo construya y lo sostenga contigo, o quieres que te monte el puesto completo, conversemos y reviso tu instancia contigo. Sin humo: te digo qué automatizar, qué dejar en manos de una persona y dónde poner los frenos desde el primer día.
