Avanzado 12 minn8n

n8n y MCP: conecta tus workflows a un LLM local

n8n y MCP se combinan en ambos sentidos: n8n puede exponer sus workflows como herramientas MCP gracias al nodo MCP Server Trigger, y un agente de n8n puede llamar a las herramientas de un servidor MCP externo gracias al nodo MCP Client Tool. Esta guía muestra ambas configuraciones, con un agente que funciona con un modelo local servido por Ollama, y después cómo proteger las URL que publica n8n. Se basa en la documentación oficial de n8n y no trata los servidores MCP de terceros escritos para controlar n8n, que son otro tema.

Por Thomas P.·Actualización 2026-10-26·Probado en Windows, macOS y Linux

#n8n y MCP: dos nodos, dos sentidos de circulación

El Model Context Protocol (MCP) es un protocolo abierto que describe cómo una aplicación de IA descubre y llama a herramientas que ofrece un servidor. Si el concepto es nuevo para ti, la guía «MCP: ¿qué es?» explica lo básico; aquí damos por sabido el vocabulario de cliente, servidor y herramienta.

En n8n, MCP aparece en forma de dos nodos de la familia de IA (paquete n8n-nodes-langchain). Responden a dos necesidades opuestas, y es fácil confundirlos al leer los tutoriales.

MCP Server Trigger: n8n se convierte en servidor
El nodo publica una URL MCP. Cada herramienta que le conectes (un subflujo de trabajo, una solicitud HTTP, una herramienta integrada) se convierte en una herramienta MCP que un cliente externo puede listar y llamar. Uso típico: darle a tu asistente local acceso a «crear un ticket», «buscar en el CRM» o «enviar un resumen», sin darle tus credenciales.
MCP Client Tool: n8n se convierte en cliente
El nodo se conecta como una herramienta bajo un nodo AI Agent. Se conecta a un servidor MCP existente, obtiene su lista de herramientas y las pone a disposición del agente. Uso típico: un workflow programado cuyo agente lee archivos, consulta una base de datos o busca en una documentación a través de un servidor MCP ya implementado.
Lo que MCP no cambia
La elección del modelo sigue siendo independiente. El agente de n8n puede ejecutarse con Ollama; el cliente que llama a tu MCP Server Trigger también puede usar un modelo local. MCP solo transporta la descripción de las herramientas y sus llamadas, no el modelo.

Ambos nodos pueden convivir en la misma instancia: un workflow «servidor» que expone algunas acciones de negocio y un workflow «agente» que consume uno o varios servidores MCP. Nada impide incluso que un agente de n8n llame al MCP Server Trigger de otro workflow de la misma instancia, lo que equivale a dividir un agente grande en bloques reutilizables.


#Prerrequisitos

El kit completo para crear tus propios agentes de IA.

Aprovecha nuestra experiencia y un recorrido guiado para ir más allá con tus agentes locales y tus automatizaciones.

  • Espacio en línea de por vida
  • PDF + archivos
  • Reembolsado 30 d
Una instancia reciente de n8n
Autoalojada, preferiblemente con Docker. Los nodos MCP aparecieron en 2025 y han evolucionado desde entonces (transportes, opciones de autenticación): actualiza n8n y fíate de lo que muestre tu editor. La instalación en sí se explica en detalle en la guía de n8n con Docker.
Ollama accesible desde n8n
Ollama escucha por defecto en http://localhost:11434. Si n8n se ejecuta en un contenedor, localhost se refiere al contenedor, no a tu máquina: necesitarás otra dirección (consulta el paso 1).
Un modelo que gestiona la llamada a herramientas
Un agente solo es útil si el modelo sabe generar llamadas a herramientas estructuradas. Elige un modelo cuya ficha en Ollama muestre la capacidad tools, por ejemplo de la familia Qwen3. En Q4_K_M, un 8B cabe en unos 5 GB de VRAM y un 14B en unos 9 GB, lo que sigue siendo holgado en una RTX 3060 de 12 GB o una RTX 4070 de 12 GB.
Para el paso 2
Un servidor MCP accesible por HTTP. Los servidores que solo se ejecutan en local mediante stdio (un comando npx o uvx) no son accesibles tal cual desde n8n: necesitas un servidor que escuche en una URL.
Para el paso 4
Un cliente MCP capaz de comunicarse con un servidor remoto: LM Studio, Open WebUI, Claude Desktop a través de una pasarela, o el inspector oficial del protocolo para hacer pruebas.

#Paso 1: un agente de n8n conectado a un modelo local

Los dos sentidos de MCP pasan por un agente, del lado de n8n o del lado del cliente. Así que empieza por comprobar que n8n sabe comunicarse con tu modelo local. La conexión básica se explica en detalle en la guía n8n + Ollama; aquí tienes lo estrictamente necesario.

Terminal
# Télécharger un modèle compatible avec l'appel d'outils
ollama pull qwen3:8b

# Vérifier qu'Ollama répond et liste le modèle
curl http://localhost:11434/api/tags

Si n8n se ejecuta en Docker y Ollama directamente en el host, añade al servicio de n8n una entrada que haga que host.docker.internal apunte a la máquina host. En Docker Desktop (macOS, Windows), ese nombre ya existe; en Linux, hay que declararlo.

docker-compose.yml (fragmento)
services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    extra_hosts:
      - "host.docker.internal:host-gateway"

En Linux, Ollama solo escucha por defecto en 127.0.0.1: un contenedor no podrá conectarse a él mediante host-gateway mientras no definas OLLAMA_HOST=0.0.0.0 en el servicio Ollama. Si ambos se ejecutan en el mismo archivo Compose, usa mejor el nombre del servicio, por ejemplo http://ollama:11434.

  1. 01
    Crear el agente
    En un nuevo workflow, añade un disparador Chat Trigger (práctico para probar) y luego un nodo AI Agent.
  2. 02
    Conectar el modelo
    En la entrada Chat Model del agente, añade Ollama Chat Model. Crea la credencial Ollama con la URL base http://host.docker.internal:11434 (o http://localhost:11434 si n8n no está en un contenedor) y luego selecciona qwen3:8b.
  3. 03
    Probar sin herramientas
    Abre el chat del workflow y haz una pregunta sencilla. Una respuesta confirma la conexión de n8n con Ollama; el resto de la guía añade herramientas encima.

#Paso 2: consumir un servidor MCP desde un agente de n8n

El nodo MCP Client Tool se conecta a la entrada Tool del AI Agent, como cualquier herramienta. Durante la ejecución, consulta el servidor MCP, obtiene la lista de herramientas con su descripción y su esquema de parámetros, y se las presenta al modelo. Es el modelo el que decide llamar a tal herramienta con tales argumentos; n8n se encarga de transmitir la llamada y devolver el resultado.

  1. 01
    Añadir el nodo
    Debajo del agente creado en el paso 1, haz clic en el + de la entrada Tool y elige MCP Client Tool.
  2. 02
    Indicar el endpoint
    Pega la URL del servidor MCP y elige el transporte que ofrezca ese servidor. La documentación de n8n menciona el flujo HTTP (streamable HTTP), el transporte actual del protocolo, y los Server-Sent Events (SSE), más antiguos y que algunos servidores aún ofrecen. Si el servidor documenta una URL que termina en /sse, normalmente se trata de SSE; si no, prueba con HTTP.
  3. 03
    Elegir la autenticación
    Ninguna, Bearer (un token enviado en el encabezado Authorization) o un encabezado personalizado, según lo que exija el servidor. Las opciones exactas dependen de tu versión de n8n; el token se guarda como una credencial de n8n, no en texto plano dentro del workflow.
  4. 04
    Filtrar las herramientas
    El parámetro Tools to Include ofrece All, Selected o All Except. Es preferible Selected: un modelo local de 8B elige mejor entre tres herramientas bien descritas que entre treinta, y además limitas lo que el agente puede activar.
  5. 05
    Probar
    Pide en el chat una acción que requiera la herramienta. En el registro de ejecución del agente verás la herramienta llamada, los argumentos generados por el modelo y la respuesta del servidor.
→
El prompt del sistema hace la mitad del trabajo
Con un modelo local, describe en el mensaje de sistema del agente cuándo usar cada herramienta y cuándo abstenerse. Los modelos pequeños tienden a ignorar las herramientas o a llamarlas para todo. Una instrucción breve y un número reducido de herramientas seleccionadas producen llamadas más fiables que un modelo más grande mal guiado.

Recordatorio práctico: n8n debe poder alcanzar el servidor MCP. Un servidor lanzado en tu equipo en la dirección localhost:3000 no es visible desde el contenedor de n8n; se aplica la misma regla de host.docker.internal o nombre del servicio Docker.


#Paso 3: exponer tus workflows con el MCP Server Trigger

Es el sentido más buscado detrás de la búsqueda «n8n mcp»: convertir automatizaciones existentes en herramientas que un asistente puede llamar. El MCP Server Trigger se diferencia de los disparadores clásicos: no lanza una secuencia de nodos, solo se conecta a nodos de herramientas y los publica.

  1. 01
    Crear el workflow servidor
    Crea un workflow nuevo y añade el nodo MCP Server Trigger. Muestra una URL de prueba y una URL de producción, además de un campo Path que determina el final de la URL. Si quieres, sustituye el identificador aleatorio por una ruta legible, pero procura que siga siendo difícil de adivinar.
  2. 02
    Conectar herramientas
    Haz clic en la entrada Tool del trigger y añade herramientas. La más útil es la herramienta que llama a otro flujo de trabajo de n8n (Call n8n Workflow Tool): tu automatización existente se convierte en una herramienta MCP. También puedes conectar HTTP Request Tool o herramientas de integración que ofrece n8n.
  3. 03
    Cuidar el nombre y la descripción
    El cliente solo ve el nombre de la herramienta, su descripción y el esquema de sus parámetros. Es ese texto el que lee el modelo para decidir si hace una llamada. Escribe una descripción explícita, en una o dos frases: qué hace la herramienta, qué parámetros espera y qué devuelve.
  4. 04
    Definir los parámetros del subflujo de trabajo
    En el workflow llamado, declara los campos de entrada esperados (por ejemplo, el título y la prioridad de un ticket). El cliente MCP recibirá este esquema y el modelo rellenará los valores.
  5. 05
    Probar y luego activar
    La URL de prueba solo responde mientras el editor está a la escucha de un evento de prueba; las ejecuciones se muestran entonces en el lienzo. La URL de producción solo funciona una vez activado el flujo de trabajo. Usa la URL de prueba para los ajustes y entrega la URL de producción a tus clientes.
Formato de las URL (copia las que muestra el nodo)
Test        : https://n8n.mondomaine.lan/mcp-test/<chemin>
Production  : https://n8n.mondomaine.lan/mcp/<chemin>

La dirección base es la misma que usa n8n para sus webhooks. Si n8n muestra localhost:5678 cuando accedes con otro nombre, corrige la variable WEBHOOK_URL de la instancia: es la que determina la URL que se muestra en el nodo.

!
Modo cola y varias réplicas de webhook
El transporte MCP mantiene una conexión con un proceso concreto. La documentación de n8n indica que, en modo queue con varias réplicas de webhook, todas las solicitudes a las rutas /mcp* deben enrutarse a una única réplica dedicada; de lo contrario, los intercambios fallan de forma intermitente. Una instancia simple, en un solo contenedor, no se ve afectada.

#Paso 4: conectar un cliente MCP local a n8n

Falta que un asistente que también funcione con un modelo local llame a estas herramientas. Antes de cualquier cliente «inteligente», verifica el servidor con el inspector oficial del protocolo: enumera las herramientas expuestas y permite llamarlas a mano, sin ningún modelo en el circuito.

Terminal
# Lance l'inspecteur MCP dans le navigateur (nécessite Node.js)
npx @modelcontextprotocol/inspector

En la interfaz, elige el transporte correspondiente, pega la URL de producción, añade el encabezado Authorization si activaste la autenticación y luego lista las herramientas. Si tus herramientas de n8n aparecen con su descripción, el servidor está listo.

#LM Studio y los clientes que aceptan una URL

Los clientes recientes aceptan directamente un servidor MCP remoto definido por una URL. LM Studio, por ejemplo, lee un archivo mcp.json con el formato mcpServers; una entrada remota tiene la forma que se muestra abajo. Comprueba en la documentación de tu cliente el nombre exacto de los campos, que puede variar de un programa a otro.

mcp.json
{
  "mcpServers": {
    "n8n": {
      "url": "https://n8n.mondomaine.lan/mcp/<chemin>",
      "headers": {
        "Authorization": "Bearer <votre-jeton>"
      }
    }
  }
}

#Clientes limitados a stdio: usar una pasarela

Algunos clientes solo pueden lanzar servidores locales en stdio. Para este caso, la documentación de n8n describe el uso de la pasarela mcp-remote, que se lanza como un servidor stdio y retransmite las llamadas a la URL de n8n. El token se pasa mediante una variable de entorno en lugar de escribirlo directamente en los argumentos.

Configuración del cliente (formato mcpServers)
{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://n8n.mondomaine.lan/mcp/<chemin>",
        "--header",
        "Authorization: Bearer ${AUTH_TOKEN}"
      ],
      "env": {
        "AUTH_TOKEN": "<votre-jeton>"
      }
    }
  }
}

En cuanto al modelo, se aplican las mismas reglas que en el paso 2: carga en tu cliente un modelo que admita llamadas a herramientas, mantén pocas herramientas visibles y prueba primero con una petición sin ambigüedad. La guía MCP y LLM local detalla la configuración del lado del cliente para Ollama y sus interfaces.


#Proteger los endpoints MCP de n8n

Una URL de MCP Server Trigger es un punto de entrada que activa tus workflows con las credenciales guardadas en n8n. Cualquiera que la conozca, sin autenticación, puede crear tus tickets o leer tu CRM. Trátala como una clave de API.

Activar la autenticación
El nodo ofrece autenticación mediante token Bearer o mediante encabezado. Actívala siempre, incluso en una red local. Genera un token largo y aleatorio, por ejemplo con el comando openssl de abajo, y un token distinto para cada cliente, para poder revocar solo uno.
No exponer n8n a Internet sin motivo
Para uso personal o en un equipo pequeño, mantén n8n en la red local o detrás de una VPN (WireGuard, Tailscale). Si es necesario exponerlo, usa un proxy inverso con HTTPS, con filtrado de IP si es posible.
Limitar lo que puede hacer cada herramienta
Una herramienta MCP debe hacer una tarea concreta con parámetros acotados. Evita exponer una herramienta genérica del tipo «ejecutar una consulta SQL» o «llamar a cualquier URL»: un modelo que se equivoque, o un contenido malicioso leído por el agente, puede desviarla de su uso.
Cuidado con la inyección de prompts
Si el agente lee contenido externo (correos electrónicos, páginas web, documentos) y dispone de herramientas que ejecutan acciones, un texto malicioso puede ordenarle que llame a una herramienta. Separa las herramientas de lectura de las de acción y añade una validación humana (nodo de espera o de aprobación) antes de cualquier acción irreversible.
Auditar del lado del servidor MCP de terceros
En el sentido cliente, añade a un agente solo servidores MCP cuyo editor y código conozcas. Las descripciones de herramientas que proporciona el servidor entran directamente en el contexto del modelo.
Supervisar las ejecuciones
Cada llamada a una herramienta genera una ejecución en n8n. Consulta con regularidad el historial del workflow servidor: es tu registro de auditoría.
Terminal
# Générer un jeton aléatoire de 64 caractères hexadécimaux
openssl rand -hex 32

Si hay un proxy inverso delante de n8n, debe dejar pasar una respuesta en streaming. La documentación de n8n ofrece un ejemplo de nginx que desactiva el almacenamiento en búfer para las rutas MCP; el fragmento siguiente recoge esas directivas, que debes adaptar a tu configuración y completar con la ruta /mcp-test/ si haces pruebas a través del proxy.

nginx (fragmento de server {})
location /mcp/ {
    proxy_pass http://127.0.0.1:5678;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    proxy_cache off;
    chunked_transfer_encoding off;
    gzip off;
}

#Solución de problemas de n8n MCP: los bloqueos frecuentes

El cliente no ve ninguna herramienta
Comprueba que haya herramientas conectadas a la entrada Tool del MCP Server Trigger, que estés usando la URL de producción con un workflow activado, o la URL de prueba mientras el editor está escuchando.
Error 401 o 403
El token no coincide o el cliente no envía el encabezado. Prueba con el inspector MCP, que muestra exactamente los encabezados enviados. Ojo con el espacio después de «Bearer».
Conexión que se corta o se queda bloqueada
Casi siempre se trata de un proxy que almacena el flujo en búfer, o de un transporte incorrecto elegido en el cliente (SSE frente a HTTP). Prueba directamente en el puerto 5678 para descartar el proxy.
La URL mostrada contiene localhost
La variable WEBHOOK_URL de n8n no está definida: la URL no será accesible desde otro equipo. Defínela con la dirección pública o de red de la instancia y luego reinicia n8n.
ECONNREFUSED hacia Ollama
n8n en contenedor busca Ollama dentro del contenedor. Usa host.docker.internal o el nombre del servicio de Docker, y comprueba que Ollama escucha en una interfaz accesible.
El modelo nunca llama a la herramienta
Modelo sin soporte de herramientas, descripción de herramienta demasiado vaga o demasiadas herramientas expuestas. Cambia a un modelo marcado como tools, reescribe la descripción y reduce la selección.
El modelo se inventa parámetros
El esquema del subworkflow es demasiado laxo. Declara campos tipados y describe los valores esperados; valida las entradas en el workflow antes de cualquier acción.
i
Sobre el rendimiento
Esta guía no publica ninguna medición de velocidad ni de tasa de éxito de las llamadas a herramientas. El resultado depende del modelo, de su cuantización, de la longitud de las descripciones de las herramientas y de tu hardware. Para evaluarlo, prueba tus propias herramientas con una serie de solicitudes representativas y compara los registros de ejecución.

#Para ir más allá

Esta guía trata MCP en n8n. Para los fundamentos del protocolo, la configuración de los clientes MCP en Ollama o la conexión de n8n a un modelo local, estas guías toman el relevo.

¿Esta guía te ha ayudado?

¿Un comentario, un error, una precisión? Avísanos, eso mejora la guía para todos.