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.
#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
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.
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.
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.
- 01Crear el agenteEn un nuevo workflow, añade un disparador Chat Trigger (práctico para probar) y luego un nodo AI Agent.
- 02Conectar el modeloEn 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.
- 03Probar sin herramientasAbre 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.
- 01Añadir el nodoDebajo del agente creado en el paso 1, haz clic en el + de la entrada Tool y elige MCP Client Tool.
- 02Indicar el endpointPega 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.
- 03Elegir la autenticaciónNinguna, 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.
- 04Filtrar las herramientasEl 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.
- 05ProbarPide 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.
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.
- 01Crear el workflow servidorCrea 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.
- 02Conectar herramientasHaz 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.
- 03Cuidar el nombre y la descripciónEl 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.
- 04Definir los parámetros del subflujo de trabajoEn 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.
- 05Probar y luego activarLa 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.
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.
#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.
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.
#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.
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.
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.
#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.
#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.
¿Un comentario, un error, una precisión? Avísanos, eso mejora la guía para todos.