n8n retiró el login básico y, por separado, hizo nativo el soporte MCP

Levantar un agente en n8n hoy no se parece a hacerlo hace un año, pero por dos motivos que no tienen relación causal entre sí. n8n retiró el login básico (N8N_BASIC_AUTH_ACTIVE ya no hace nada) e hizo obligatoria la gestión de usuarios; en paralelo, y como proyecto independiente del equipo, añadió soporte nativo para Model Context Protocol en las dos direcciones: como cliente que consume herramientas externas y como servidor que expone sus propios workflows. Tratarlos como una sola migración es el primer error al planificar una actualización.

Esta es una actualización práctica: qué cambió realmente en la plataforma, cómo levantar una instancia sin la pantalla de setup interactiva, y el workflow completo de un agente que consulta un sistema externo por MCP en vez de un nodo HTTP suelto, con la autenticación resuelta de verdad y no solo de cara al tutorial.

Qué dejó de ser cierto desde febrero

n8n pasó a su línea 2.x a lo largo de 2026, y el salto no es solo de número de versión. Cinco cambios concretos afectan a cualquiera que ya tuviera un workflow con IA montado desde antes:

• El login básico ya no existe. Desde la versión 1.0, n8n retiró el soporte de BasicAuth y JWT externo y convirtió la gestión de usuarios en obligatoria. Cualquier docker-compose que todavía use N8N_BASIC_AUTH_ACTIVE arranca la pantalla de creación de owner igual, ignorando esa variable.
• El nodo de agente se simplificó a un solo tipo. Antes de la versión 1.82.0 podías elegir entre varios tipos de agente (ReAct, Conversational, OpenAI Functions...). Ahora todos los nodos AI Agent funcionan como Tools Agent, que era la opción que casi todo el mundo usaba de todas formas. Los workflows viejos siguen funcionando igual, pero ya no hay que decidir nada ahí.
• MCP es nativo en las dos direcciones. El nodo MCP Client Tool conecta el agente a cualquier servidor MCP externo (soporta autenticación Bearer, cabeceras genéricas y OAuth2), y el MCP Server Trigger convierte tus propios workflows en herramientas que Claude Desktop, ChatGPT o Cursor pueden invocar. Desde la versión 2.22, además, puedes conectarte con un clic a servidores MCP de terceros (Notion, Linear, monday.com) sin configurar nada a mano.
• Los task runners ya no se activan con una variable. N8N_RUNNERS_ENABLED quedó obsoleta a partir de la 2.0; el modo se controla ahora con N8N_RUNNERS_MODE (internal por defecto).
• El self-hosted sigue siendo gratis, pero no todo lo es. Sin clave de licencia, la instancia corre en modo Community: sin límite de ejecuciones, sujeta solo a la restricción de uso comercial de la Sustainable Use License de siempre (no puedes revender el software como servicio competidor de n8n). Las ediciones Business y Enterprise requieren una clave de licencia incluso en self-hosted, aunque sigas gestionando tú el servidor.

La Sustainable Use License, vigente desde marzo de 2022, no es open source en sentido OSI: permite usar, modificar y redistribuir el código con una restricción concreta: no puedes usarlo para vender un servicio que compita con n8n. Para automatizar tus propios procesos, construir workflows para clientes o correr herramientas internas no impone ninguna limitación práctica.

Arrancar la instancia sin la pantalla de setup interactiva

Con la gestión de usuarios obligatoria, el primer arranque de n8n pide crear una cuenta de owner desde el navegador. Eso es un problema para despliegues automatizados: si tu pipeline de infraestructura levanta la instancia sin intervención humana, se queda esperando una pantalla que nadie va a rellenar.

La solución es pre-aprovisionar el owner por variables de entorno, disponible desde la versión 2.17.0 de n8n a través de N8N_INSTANCE_OWNER_MANAGED_BY_ENV. La contraseña debe llegar como hash bcrypt, nunca en texto plano. Genera el hash con un contenedor Node efímero:

docker run --rm node:20-alpine sh -c \
  "npm install -s bcryptjs >/dev/null 2>&1 && \
   node -e \"console.log(require('bcryptjs').hashSync(process.argv[1], 10))\" 'CambiaEstaClave2026!'"

Copia el hash que imprime (empieza por $2a$ o $2b$) y pégalo en el docker-compose. Este es el fichero completo, sin el campo version que Compose ya ignora desde hace tiempo:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - GENERIC_TIMEZONE=Europe/Madrid
      - TZ=Europe/Madrid
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - N8N_INSTANCE_OWNER_MANAGED_BY_ENV=true
      - N8N_INSTANCE_OWNER_EMAIL=admin@tudominio.com
      - N8N_INSTANCE_OWNER_FIRST_NAME=Admin
      - N8N_INSTANCE_OWNER_LAST_NAME=Ops
      - N8N_INSTANCE_OWNER_PASSWORD_HASH=${N8N_OWNER_PASSWORD_HASH}
      - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:

# Levantar el contenedor (N8N_OWNER_PASSWORD_HASH y ANTHROPIC_API_KEY en .env)
docker-compose up -d

# http://localhost:5678 entra directo, sin pantalla de creación de owner

Con N8N_INSTANCE_OWNER_MANAGED_BY_ENV=true, n8n sobrescribe los datos del owner en cada arranque y bloquea su edición desde la interfaz: útil para infraestructura reproducible, pero significa que si alguien cambia la contraseña desde la UI, el siguiente reinicio la revierte. Para un servidor con más tráfico, 2 vCPU y 4 GB de RAM gestionan sin problema el volumen de un equipo pequeño con agentes LLM; para más carga, el modo queue con Redis y workers separados existe pero añade mantenimiento.

Conectar el agente a herramientas por MCP, no por nodos sueltos

El patrón anterior para dar herramientas a un agente era encadenar nodos de n8n (HTTP Request, PostgreSQL, Code) como "herramientas" del AI Agent. Sigue funcionando y para una integración puntual sigue siendo lo más simple. La diferencia con MCP aparece cuando la misma herramienta la necesitan varios workflows, o cuando ya existe un servidor MCP para el sistema que quieres consultar: en vez de reconstruir la lógica de conexión en cada workflow, el nodo MCP Client Tool apunta a un único servidor y expone todas sus herramientas (o una selección) al agente.

La configuración pide tres cosas: el endpoint del servidor MCP (transporte SSE o HTTP Streamable; el SSE está en proceso de sustitución por Streamable HTTP como método recomendado), el método de autenticación (Bearer, cabecera genérica, múltiples cabeceras u OAuth2) y qué subconjunto de herramientas exponer. El agente decide en tiempo de ejecución cuál invocar según la pregunta del usuario, exactamente igual que con un nodo HTTP, pero sin mantener la definición de la API en el propio workflow.

La otra mitad del patrón, menos usada pero igual de relevante: el MCP Server Trigger convierte un workflow de n8n en un servidor MCP. Cualquier cliente compatible con el protocolo (Claude Desktop, Cursor, un agente propio) puede listar y llamar a las herramientas que expongas conectando nodos de workflow al trigger. La limitación real es que este trigger solo conecta a nodos herramienta, no a la lógica de trigger habitual, y en despliegues con varias réplicas del servidor web hay que enrutar todo el tráfico /mcp* a una réplica fija para mantener las conexiones persistentes.

El workflow completo: agente de soporte con MCP y memoria

Este es el JSON exportable de un agente de soporte que resuelve consultas sobre pedidos consultando un servidor MCP en vez de una conexión SQL directa. Impórtalo con "Import from File" en el editor; hay tres credenciales que crear antes de que funcione, no dos: la de Anthropic, la del servidor MCP (Bearer, vía el sistema de credenciales de HTTP Request, no un tipo de credencial propio de MCP) y la de Header Auth del propio nodo Webhook, que es la que decide quién puede llamar a este workflow desde fuera.

{
  "name": "Agente de soporte con MCP",
  "nodes": [
    {
      "id": "a1b2c3d4-0001-4a1a-9e11-000000000001",
      "name": "Webhook",
      "type": "n8n-nodes-base.webhook",
      "typeVersion": 2,
      "position": [-460, 0],
      "parameters": {
        "httpMethod": "POST",
        "path": "soporte",
        "responseMode": "responseNode",
        "authentication": "headerAuth",
        "options": {}
      },
      "credentials": {
        "httpHeaderAuth": { "id": "12", "name": "Webhook soporte - header auth" }
      }
    },
    {
      "id": "a1b2c3d4-0002-4a1a-9e11-000000000002",
      "name": "AI Agent",
      "type": "@n8n/n8n-nodes-langchain.agent",
      "typeVersion": 1.7,
      "position": [-180, 0],
      "parameters": {
        "promptType": "define",
        "text": "={{ $json.body.message }}",
        "options": {
          "systemMessage": "Eres un asistente de soporte de pedidos. Usa la herramienta MCP de pedidos para consultar el estado real antes de responder. Si no encuentras el pedido, dilo explicitamente y pide el email o el ID. Nunca inventes un estado de pedido."
        }
      }
    },
    {
      "id": "a1b2c3d4-0003-4a1a-9e11-000000000003",
      "name": "Claude",
      "type": "@n8n/n8n-nodes-langchain.lmChatAnthropic",
      "typeVersion": 1,
      "position": [-280, 220],
      "parameters": {
        "model": {
          "__rl": true,
          "mode": "list",
          "value": "claude-sonnet-5",
          "cachedResultName": "Claude Sonnet 5"
        },
        "options": {}
      },
      "credentials": {
        "anthropicApi": { "id": "10", "name": "Anthropic account" }
      }
    },
    {
      "id": "a1b2c3d4-0004-4a1a-9e11-000000000004",
      "name": "Memoria de conversacion",
      "type": "@n8n/n8n-nodes-langchain.memoryBufferWindow",
      "typeVersion": 1.3,
      "position": [-100, 220],
      "parameters": {
        "sessionKey": "={{ $json.body.customerEmail }}",
        "contextWindowLength": 10
      }
    },
    {
      "id": "a1b2c3d4-0005-4a1a-9e11-000000000005",
      "name": "MCP pedidos",
      "type": "@n8n/n8n-nodes-langchain.toolMcp",
      "typeVersion": 1,
      "position": [60, 220],
      "parameters": {
        "sseEndpoint": "https://mcp.tu-erp.com/orders",
        "authentication": "bearerAuth",
        "toolsToInclude": "all"
      },
      "credentials": {
        "httpBearerAuth": { "id": "11", "name": "MCP pedidos - bearer" }
      }
    },
    {
      "id": "a1b2c3d4-0006-4a1a-9e11-000000000006",
      "name": "Respond to Webhook",
      "type": "n8n-nodes-base.respondToWebhook",
      "typeVersion": 1.1,
      "position": [100, 0],
      "parameters": {
        "respondWith": "json",
        "responseBody": "={{ { \"response\": $json.output } }}"
      }
    }
  ],
  "connections": {
    "Webhook": { "main": [[{ "node": "AI Agent", "type": "main", "index": 0 }]] },
    "AI Agent": { "main": [[{ "node": "Respond to Webhook", "type": "main", "index": 0 }]] },
    "Claude": { "ai_languageModel": [[{ "node": "AI Agent", "type": "ai_languageModel", "index": 0 }]] },
    "Memoria de conversacion": { "ai_memory": [[{ "node": "AI Agent", "type": "ai_memory", "index": 0 }]] },
    "MCP pedidos": { "ai_tool": [[{ "node": "AI Agent", "type": "ai_tool", "index": 0 }]] }
  },
  "pinData": {},
  "settings": { "executionOrder": "v1" }
}

El nodo Webhook exige Header Auth: sin el valor correcto en la cabecera configurada en esa credencial, n8n devuelve 403 antes de que el workflow llegue a ejecutarse. Eso resuelve quién puede llamar a este endpoint, pero no resuelve en nombre de qué cliente actúa cada llamada, que es un problema distinto. El campo customerEmail del body sigue ahí porque el agente necesita saber de qué pedido hablar, pero no es una credencial y no debería tratarse como una: cualquier sistema que conozca el secreto de Header Auth podría escribir el email de otra persona en ese campo y, si el workflow confiara en él a ciegas, leer sus pedidos. La forma correcta de exponerlo es que el navegador del cliente nunca llame directamente a este webhook: la llamada la hace tu propio backend, después de autenticar la sesión del cliente con tu sistema de login habitual, y es ese backend -no la petición original del navegador- quien rellena customerEmail con el valor que él mismo verificó. El secreto de Header Auth protege el webhook de internet en general; la sesión verificada en tu backend es lo que protege a un cliente de otro. Por eso el sessionKey de la memoria usa ese mismo email ya verificado y no un ID fijo: para que dos conversaciones no se mezclen entre sí (el error clásico es dejar la misma clave de sesión para todo el mundo) y para que nadie pueda leer la memoria de otro cliente falsificando un email en una petición directa. Un detalle adicional, menos crítico: el modelo del nodo Anthropic se selecciona con un resource locator en modo list; en tu instancia, ese desplegable se rellena en vivo contra la API de Anthropic, así que confirma que el ID exacto sigue vigente antes de dar el workflow por cerrado.

Probarlo y qué vigilar antes de dejarlo en producción

Con el workflow activo, un curl contra el webhook debería devolver una respuesta que cita el pedido real, no una inventada:

curl -X POST https://tu-instancia.com/webhook/soporte \
  -H "Content-Type: application/json" \
  -H "X-Webhook-Secret: TU_SECRETO_DE_HEADER_AUTH" \
  -d '{"message": "¿cual es el estado de mi pedido?", "customerEmail": "cliente@ejemplo.com"}'

# Este curl simula la llamada que haría tu backend ya autenticado, con el
# email que ese backend verificó. Sin la cabecera del secreto, la respuesta es 403.
# El navegador del cliente nunca debería tener este secreto ni llamar aquí directo.

# {"response": "El pedido mas reciente de cliente@ejemplo.com esta en estado
#  'enviado', creado el 15/02/2026. Importe: 89,99€."}

Cuatro cosas que sí cambian entre esto y un despliegue real:

Autenticación y autorización, no solo timeouts. Header Auth en el nodo Webhook decide quién puede llamar al endpoint; no decide en nombre de qué cliente actúa esa llamada, y confundir esas dos cosas es exactamente el fallo que este workflow tenía antes de corregirlo. Si vas a exponer un agente como este a usuarios finales, cualquier campo de identidad que viaje en el body hay que darlo por no fiable por defecto: verifica la sesión del cliente en tu propio backend y que sea ese backend, nunca el cliente, quien decida qué identidad pasar al webhook. Añade también logging de qué identidad se usó en cada llamada; sin eso, un intento de suplantación pasa desapercibido hasta que alguien se queja.

Timeouts. Un agente que encadena varias llamadas al LLM y a la herramienta MCP puede tardar 20-40 segundos. Si el cliente que llama al webhook espera una respuesta síncrona con timeout corto, hay que pasar a un patrón asíncrono: el webhook devuelve un ID de tarea de inmediato y el resultado llega por callback o polling.

Reintentos en el nodo MCP. Si el servidor MCP externo falla intermitentemente, activa retryOnFail en el nodo MCP Client Tool con un backoff razonable; sin esto, un fallo puntual del servidor MCP tumba la respuesta completa del agente en vez de solo esa llamada.

Task runners activos por defecto. Desde la 2.0 no hace falta declarar N8N_RUNNERS_ENABLED, pero si migras una instancia vieja que lo tenía a false explícitamente para no levantar su propio sidecar en modo queue, confirma que la variable no sigue interfiriendo: quedó obsoleta y el comportamiento pasa a depender de N8N_RUNNERS_MODE.

Lo que cuesta de verdad: créditos de IA en Cloud, self-hosted sin ellos

El argumento económico de n8n frente a Zapier y Make sigue siendo el mismo que en febrero: n8n factura por ejecución completa del workflow, no por paso. Un workflow de 8 nodos que corre 2.000 veces al mes consume 2.000 créditos en n8n frente a 16.000 tareas en Zapier. Lo que cambió es que n8n Cloud introdujo un segundo contador, separado de las ejecuciones: los créditos de IA, que consume el AI Assistant (el asistente que genera o modifica workflows a partir de lenguaje natural), no los nodos de agente que tú construyes.

Precios y unidades de facturación comprobados en las páginas oficiales en agosto de 2026; cambian a menudo, así que confírmalos antes de decidir.

Los créditos de IA no se acumulan de mes a mes y hoy no se pueden comprar aparte del plan; si tu equipo genera workflows con el asistente conversacional a diario, es un límite real, distinto del límite de ejecuciones. En self-hosted esa capa no existe: pagas directamente el uso de la API del modelo que elijas, sin límite de n8n de por medio, lo que en la práctica hace que el self-hosted sea más predecible en coste cuanto más se usa el AI Assistant en Cloud.

La comparación de unidades sigue siendo la trampa habitual: una tarea de Zapier, un crédito de Make y una ejecución de n8n no son la misma cosa, y ninguna cifra de esta tabla sustituye a calcular tu propio volumen antes de decidir.

Patrones de automatización con LLMs en producción

Más allá del agente de soporte del apartado anterior, estos son los patrones que más se repiten en despliegues reales de n8n con LLMs, ya sea con nodos sueltos o con MCP cuando ya existe un servidor para el sistema en cuestión:

Enriquecimiento de leads. Un webhook recibe un formulario de contacto con un campo de texto libre; el LLM extrae industria, tamaño de empresa y caso de uso probable, y el resultado se escribe en el CRM con un nodo de escritura directo o, si el CRM ya expone un servidor MCP, con el MCP Client Tool. Sustituye formularios largos por un único campo abierto procesado por IA.

Resumen de documentos con clasificación. Un Cron trigger revisa una carpeta de Google Drive, descarga los PDFs nuevos, los fragmenta y los pasa por un LLM para clasificación y resumen antes de guardarlos en Notion. Útil para equipos legales o de compliance que procesan contratos a volumen.

Alertas de infraestructura con contexto. Un webhook recibe alertas de Prometheus o Grafana; el agente LLM consulta el runbook relevante (por RAG contra un vector store, o por MCP si el sistema de documentación ya expone un servidor) y publica en Slack un resumen accionable con la causa probable y los pasos sugeridos. Reduce el tiempo de triage en incidencias repetitivas.

Errores comunes al integrar LLMs en n8n

El agente mezcla el contexto de dos clientes distintos. Causa: la memoria usa la misma clave de sesión para todo el mundo, o una clave que el propio cliente puede manipular desde el body de la petición. Solución: usa como sessionKey un identificador que tu backend ya haya verificado, nunca un valor que llegue sin comprobar (ver la sección de autenticación más arriba).

El agente falla de forma intermitente contra el servidor MCP. Causa: el servidor MCP externo tiene rate limiting o caídas puntuales, y el nodo MCP Client Tool no reintenta por defecto. Solución: activa retryOnFail con backoff en el nodo, y ten un plan B (un nodo HTTP Request directo) si el servidor MCP es crítico y no controlas su disponibilidad.

El agente elige mal entre herramientas con nombres parecidos. Causa: al exponer "todas" las herramientas de un servidor MCP con toolsToInclude: all, el agente recibe decenas de funciones con descripciones similares y confunde cuál invocar. Solución: usa el modo "Selected" o "All Except" del MCP Client Tool para limitar el conjunto de herramientas a las que realmente necesita ese workflow.

Cuándo no te conviene montar esto

Si tu caso de uso es una integración puntual entre dos SaaS sin lógica condicional, un Zap de dos pasos en el plan gratuito de Zapier resuelve el problema en diez minutos y sin mantener nada. Montar un agente con MCP para eso es sobreingeniería.

Si no tienes a nadie que pueda encargarse de backups, actualizaciones de seguridad y monitorización de un servidor, el self-hosted deja de ser gratis en la práctica: el coste se traslada de la licencia al tiempo de alguien del equipo, y ese tiempo suele salir más caro que el plan Cloud.

Y si el servidor MCP que necesitas todavía no existe para el sistema que quieres conectar, no merece la pena escribir uno desde cero solo para este workflow: un nodo HTTP Request directo, sin la capa MCP, resuelve lo mismo con menos piezas hasta que ese servidor exista o lo necesites en más de un sitio.