n8n y MCP: agentes que usan tus herramientas sin conectores a medida

MCP (Model Context Protocol) es un estándar abierto que permite a un modelo de IA usar herramientas externas, como Shopify, Notion o tu CRM, a través de una interfaz común en lugar de un conector programado para cada caso. En n8n, la plataforma de automatización de flujos, puedes actuar como cliente MCP, es decir, tu agente consume herramientas de servidores MCP ya existentes, y como servidor MCP, exponiendo tus propios flujos como herramientas para otros agentes. Desde la release del 19 de mayo de 2026, n8n permite conectar servidores MCP directamente desde el panel de nodos, y desde el 26 de enero de 2026 puedes exigir aprobación humana antes de que el agente ejecute una herramienta (fuente: docs.n8n.io/changelog/release-notes-2.x).

Soy Oscar Álvarez, fundador de SEOscar, agencia de ecommerce en Barcelona. Llevo meses montando agentes de IA sobre tiendas reales y la pregunta que más me llega últimamente es la misma: «¿puedo hacer que el agente consulte el pedido del cliente en Shopify sin que me programes un conector a medida?». La respuesta corta es sí, y se llama n8n + MCP. En este artículo te cuento qué es MCP, cómo encaja con n8n, un ejemplo concreto de tienda y, sobre todo, dónde no lo usaría.

Aviso previo para que no te vendan humo: MCP no es magia ni sustituye al trabajo de integración. Es un estándar que reduce el pegamento que antes había que escribir a mano. Eso es mucho, pero no es todo.

Qué es MCP en una frase

MCP (Model Context Protocol) es un estándar abierto que define cómo un modelo de IA descubre y ejecuta herramientas externas, de forma que una misma interfaz sirve para Shopify, Notion, una base de datos o tu CRM. Lo publicó Anthropic a finales de 2024 y hoy lo soportan clientes y plataformas muy distintas, n8n entre ellas.

La analogía que uso con clientes es el enchufe. Antes, cada herramienta necesitaba su propio cable con su propia clavija: un conector a medida por cada API, con su autenticación, su formato de respuesta y su mantenimiento. MCP es la regleta estándar: el servidor MCP declara qué herramientas ofrece y con qué parámetros, y cualquier agente compatible puede usarlas sin que nadie programe esa integración concreta.

Dos conceptos que conviene fijar desde ya. Un servidor MCP es el que expone herramientas, por ejemplo un servidor MCP de Notion que ofrece «buscar página», «crear página», «añadir bloque». Un cliente MCP es el que las consume, normalmente un agente de IA. En n8n puedes ser las dos cosas, y ahí está la gracia.

n8n como cliente MCP y como servidor MCP

n8n funciona en los dos sentidos: como cliente MCP conecta tu agente a servidores externos para que use sus herramientas, y como servidor MCP convierte tus propios flujos de n8n en herramientas que cualquier agente compatible puede invocar. Desde la release del 19 de mayo de 2026 puedes añadir servidores MCP directamente desde el panel de nodos, sin configuración manual de endpoints (fuente: docs.n8n.io/changelog/release-notes-2.x).

n8n como cliente MCP: tu agente usa herramientas de terceros

En este modo montas un nodo de agente de IA en n8n y le conectas uno o varios servidores MCP como fuente de herramientas. El agente lee la lista de herramientas disponibles, decide cuál necesita según lo que le pida el usuario y la ejecuta con los parámetros adecuados. Tú no escribes la llamada a la API: describes el objetivo y defines qué herramientas están permitidas.

Para una tienda online esto significa que un agente puede consultar el estado de un pedido, leer el stock de una variante o buscar una ficha en Notion sin que yo tenga que mantener tres integraciones distintas. Si el servidor MCP cambia una herramienta, el agente la ve actualizada; no hay que redesplegar un conector propio.

n8n como servidor MCP: tus flujos se convierten en herramientas

El camino inverso es igual de interesante y menos conocido. Si ya tienes flujos en n8n que hacen cosas útiles, como calcular el plazo de entrega real por código postal, aplicar tu política de devoluciones o consultar un ERP antiguo por FTP, puedes exponerlos como servidor MCP. A partir de ahí, cualquier agente compatible los usa como si fueran herramientas nativas.

Esta es la parte que más valor aporta en ecommerce con sistemas propios. Tu lógica de negocio rara, esa que no está en ningún SaaS, se publica una vez y la consumen todos tus agentes. Si quieres entender cómo anclamos los agentes a los datos reales del cliente, lo explico en qué es RAG, que es la pieza complementaria: RAG da contexto documental, MCP da capacidad de acción.

Ejemplo: agente que consulta pedidos y crea tareas

El caso más repetido que me piden es este: un cliente escribe «¿dónde está mi pedido 10482?» y el agente debe consultar Shopify, responder con el estado real y, si hay incidencia, abrir una tarea en Notion o en el CRM para que atención al cliente la revise. Con n8n y MCP eso son tres herramientas y una política de permisos, no tres integraciones a medida.

Las piezas del flujo

• Disparador: el mensaje entra desde el widget de la tienda, WhatsApp o el correo de atención al cliente.

• Nodo de agente de IA en n8n con el modelo que uses y un prompt de sistema que define tono, límites y qué no debe responder nunca.

• Servidor MCP de Shopify conectado como cliente: herramienta de lectura de pedidos, solo lectura.

• Servidor MCP de Notion o de tu CRM: herramienta de creación de tarea, con plantilla de campos fija.

• Flujo propio de n8n expuesto como servidor MCP: por ejemplo, «calcular fecha estimada de entrega» con tus reglas de transportista.

• Registro de ejecuciones: cada llamada a herramienta queda logueada con entrada, salida y usuario.

Qué decide el agente y qué decides tú

El agente decide qué herramienta usar y en qué orden. Tú decides qué herramientas existen, qué permisos tienen y qué pasa si falla. En las tiendas que audito, el error típico es dar al agente acceso de escritura a todo «por si acaso». Eso no es un agente, es un becario con las llaves del almacén.

Mi regla práctica: lectura amplia, escritura estrecha. El agente puede consultar pedidos, stock, catálogo y documentación interna sin restricciones. Para escribir (crear tarea, aplicar descuento, modificar dirección) solo habilito las acciones concretas que el negocio necesita, cada una con sus campos acotados. Así funciona el agente de ventas IA que montamos: responde con el catálogo y los datos reales de la tienda, y actúa solo donde se le ha permitido actuar.

Seguridad: permisos mínimos y aprobación humana

La seguridad en n8n con MCP se resuelve en tres capas: credenciales con el permiso mínimo imprescindible, selección explícita de qué herramientas ve el agente y aprobación humana para las acciones sensibles. Desde el 26 de enero de 2026, n8n permite exigir que una persona apruebe la ejecución de una herramienta antes de que el agente la lance (fuente: docs.n8n.io/changelog/release-notes-2.x). Es la función que más uso en producción.

Permisos mínimos, en la credencial y en el servidor

Un servidor MCP no te protege de una credencial mal configurada. Si creas una app privada en Shopify con permisos de lectura y escritura sobre pedidos, productos, clientes y descuentos, el agente podrá hacer todo eso aunque tú solo hayas pensado en consultar pedidos. Crea una credencial dedicada al agente, con los alcances justos, y revísala cada vez que añadas una herramienta nueva.

Añade una segunda capa en n8n: en el nodo del agente, habilita solo las herramientas que vas a usar en ese flujo, aunque el servidor MCP ofrezca treinta. Cuantas menos herramientas ve el modelo, mejor elige y menos superficie de error hay.

Aprobación humana: dónde la pongo siempre

• Cualquier acción que mueva dinero: reembolsos, cupones, cambios de precio.

• Modificación de datos del cliente: dirección de envío, correo, datos fiscales.

• Cancelación o modificación de pedidos ya pagados.

• Envíos masivos: altas en listas de email, campañas, notificaciones a más de un destinatario.

• Escritura en sistemas que no controlas tú (ERP del cliente, facturación, contabilidad).

Para lo demás, registro y punto. Consultar el estado de un pedido o crear una tarea interna no necesita que nadie apruebe nada; si lo pides, acabas con un agente que todo el mundo ignora porque genera más trabajo del que quita.

Un agente sin límites no es más potente, es más caro de arreglar. Los permisos no frenan al agente, lo hacen desplegable.

Límites y cuándo no usarlo

MCP en n8n no sirve para todo. No lo usaría cuando la tarea es determinista y repetitiva, cuando la latencia importa, cuando la herramienta que necesitas no tiene servidor MCP decente o cuando el coste por llamada al modelo no compensa frente a un flujo clásico. Un agente que razona para hacer siempre lo mismo es pagar un taxi para ir a la cocina.

Cuatro situaciones en las que elijo flujo clásico

• Sincronización de stock entre tu ERP y Shopify cada quince minutos: eso es un flujo de n8n sin agente, más barato y más predecible.

• Procesos con reglas cerradas y auditoría estricta, como facturación o liquidaciones: si el resultado debe ser idéntico siempre, no metas un modelo en medio.

• Respuestas en tiempo real dentro de la ficha de producto: cada salto a una herramienta añade segundos, y en conversión los segundos se pagan.

• Integraciones con sistemas legacy sin API: ahí el trabajo sigue siendo de ingeniería, MCP no inventa un endpoint que no existe.

Los límites técnicos que te vas a encontrar

El primero es la calidad del servidor MCP. Un servidor con descripciones de herramientas vagas hace que el modelo elija mal; la descripción de cada herramienta es, en la práctica, parte del prompt. El segundo es el consumo de contexto: si conectas muchos servidores, la lista de herramientas se come tokens y empeora las decisiones. El tercero es la observabilidad: necesitas ver qué herramienta llamó el agente y con qué argumentos, o no podrás depurar nada.

Y uno que se menciona poco: la seguridad del propio ecosistema. Un servidor MCP de terceros es código que ejecuta acciones con tus credenciales. Trátalo con el mismo criterio con el que instalarías una app en tu tienda: revisa quién lo mantiene, qué permisos pide y si puedes autoalojarlo.

Qué haría yo desde SEOscar si me llega esta petición

Empezaría por mirar datos antes que herramientas. En el diagnóstico reviso las conversaciones reales de atención al cliente de los últimos noventa días y cuento qué porcentaje son consultas de pedido, dudas de talla o stock, y devoluciones. Si la mayoría de los tickets son tres o cuatro preguntas recurrentes, ya sé qué herramientas necesita el agente y cuáles sobran.

Después monto el flujo sobre tu stack actual, sin migrar nada: si vendes en Shopify trabajamos en Shopify, si vendes en WooCommerce trabajamos ahí. El flujo de n8n, las credenciales y la configuración MCP quedan en tu propiedad, documentados. Y arranca con aprobación humana en todo lo que escribe, que se va relajando cuando los registros demuestran que el agente acierta. Puedes ver cómo encaja esto en el conjunto en automatizaciones y en el método.

Por dónde empezar esta semana

• Exporta las conversaciones de atención al cliente de los últimos tres meses y clasifícalas por tipo de consulta. Sin ese dato no sabes qué agente necesitas.

• Crea una credencial dedicada de solo lectura para tu plataforma de ecommerce y prueba un agente en n8n que responda «¿dónde está mi pedido X?» en entorno de pruebas.

• Identifica una regla de negocio tuya que no esté en ningún SaaS y conviértela en un flujo de n8n expuesto como servidor MCP.

• Activa la aprobación humana en toda acción de escritura y revisa los registros una semana antes de abrirlo a clientes reales.

• Mide tres cosas: tickets resueltos sin intervención humana, tiempo medio de respuesta y errores del agente por cada cien conversaciones.

Si quieres que mire tu caso con tus datos y te diga si un agente con n8n y MCP te compensa o es antes otra cosa, puedes revisar lo que hacemos en automatizaciones o reservar el diagnóstico directamente. Se hace en la primera semana, con tus datos reales, y el plan es tuyo sigas conmigo o no.

Preguntas frecuentes

¿Qué es MCP y para qué sirve en n8n?

MCP (Model Context Protocol) es un estándar abierto, publicado por Anthropic a finales de 2024, que define cómo un modelo de IA descubre y ejecuta herramientas externas a través de una interfaz común. En n8n sirve para que un agente de IA use Shopify, Notion, un CRM o tus propios flujos sin programar un conector a medida para cada uno. Reduce el trabajo de integración, aunque no elimina la configuración de permisos ni el diseño del flujo.

¿Cuál es la diferencia entre un servidor MCP y un cliente MCP en n8n?

Un servidor MCP expone herramientas, por ejemplo «consultar pedido» o «crear tarea», para que otros las usen. Un cliente MCP es el que las consume, normalmente un agente de IA. n8n puede hacer las dos cosas: conectar tu agente a servidores MCP externos y, a la vez, publicar tus propios flujos de n8n como servidor MCP para que cualquier agente compatible los invoque.

¿Se puede exigir aprobación humana antes de que un agente de n8n ejecute una acción?

Sí. Desde el 26 de enero de 2026, n8n permite configurar aprobación humana previa a la ejecución de una herramienta por parte del agente, según el changelog oficial en docs.n8n.io/changelog/release-notes-2.x. En los proyectos que llevo activo esa aprobación en reembolsos, cupones, cambios de datos del cliente y cualquier escritura en sistemas de terceros, y la dejo desactivada en consultas de solo lectura.

¿Necesito saber programar para conectar un servidor MCP en n8n?

Para conectar servidores MCP existentes no hace falta programar conectores: desde la release del 19 de mayo de 2026, n8n permite añadirlos desde el panel de nodos. Lo que sí necesitas es criterio técnico para configurar credenciales con permisos mínimos, decidir qué herramientas ve el agente y escribir un buen prompt de sistema. La parte difícil ya no es el código, es el diseño de permisos y de contexto.

¿Es seguro dar acceso a Shopify o a mi CRM a un agente de IA?

Es seguro si aplicas tres capas: una credencial dedicada con el alcance mínimo imprescindible, una selección explícita de qué herramientas habilitas en el nodo del agente y aprobación humana para las acciones sensibles. El riesgo real no suele venir del modelo, sino de credenciales con permisos de escritura amplios creadas «por si acaso». Un servidor MCP de terceros merece el mismo escrutinio que una app instalada en tu tienda.

¿Cuándo no conviene usar un agente con MCP en una tienda online?

No conviene cuando la tarea es determinista y repetitiva, como sincronizar stock cada quince minutos, porque un flujo clásico de n8n es más barato y predecible. Tampoco en procesos con auditoría estricta como facturación, ni donde la latencia penaliza la conversión, ni cuando el sistema que quieres integrar no tiene API. MCP estandariza la conexión, pero no crea endpoints que no existen.

¿Qué diferencia hay entre RAG y MCP en un agente de ecommerce?

RAG (Retrieval Augmented Generation) sirve para que el agente consulte documentación y contenido propio antes de responder, es decir, le aporta contexto. MCP sirve para que el agente ejecute acciones en herramientas externas, es decir, le aporta capacidad de actuar. En un agente de ventas IA bien montado conviven las dos: RAG para hablar con criterio de tu catálogo y tus políticas, MCP para consultar el pedido o abrir una incidencia.