# MCP vs. API REST para email marketing: ¿cuál usar?

URL canónica: https://brew.new/es/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use
Autoría: Thomas Park
Publicado: 2026-09-23
Actualizado: 2026-09-29

Alguien del equipo de desarrollo conecta la plataforma de email a Claude y redacta la campaña de la semana que viene en una ventana de chat. A la mañana siguiente, otra persona pregunta si el email de bienvenida tras el registro podría funcionar igual, a través del asistente. La documentación de la plataforma presenta un servidor MCP y una API REST, uno al lado del otro.

La mayoría de las plataformas de email compatibles con agentes ofrecen ya estas dos vías de acceso. Un servidor MCP permite que un asistente de IA llame a las herramientas de la plataforma durante una conversación. Una API REST expone operaciones a las que tu código puede llamar directamente. A menudo llegan por debajo a los mismos endpoints, así que la elección depende de quién hace el trabajo y cuándo.

Usa MCP cuando una persona trabaja a través de un asistente, y la API REST cuando tu producto necesita enviar emails sin que nadie lo supervise. La mayoría de los equipos acaban usando las dos.

## Puntos clave

- MCP sirve para el trabajo interactivo que exige criterio: redactar una campaña, crear una audiencia, preguntar por qué un envío ha rendido por debajo de lo esperado.
- La API REST sirve para los procesos en producción: activar un disparador cuando alguien se registra, sincronizar contactos, enviar recibos.
- Una CLI se sitúa entre las dos. Se puede automatizar con scripts, como la API, y los agentes de programación pueden leer lo que devuelve.
- El MCP de Brew exige confirmar los envíos reales en las conexiones OAuth y de organización. Los clientes con una clave de API de marca necesitan su propia política de aprobación. El código que usa la API tiene que aportar su propia revisión, idempotencia y reintentos.

## Qué es cada uno

MCP (Model Context Protocol) es un estándar abierto para exponer herramientas a clientes de IA como Claude, ChatGPT y Cursor. El cliente lee una lista de herramientas con sus descripciones y esquemas, y elige a cuál llamar según lo que le pidas. El servidor de Brew está en `https://brew.new/api/mcp` y admite OAuth, así que inicias sesión y eliges una marca en lugar de gestionar claves.

Una API REST es un conjunto de endpoints HTTP a los que llama tu código. Brew publica una especificación OpenAPI, un SDK de TypeScript y una [guía para agentes](https://brew.new/api/v1/llms.txt) en texto plano sobre su API. Cada llamada lleva una clave de API, y tu código decide qué llamar y cuándo.

Otros proveedores siguen el mismo patrón. El servidor MCP de Customer.io envuelve su API en [herramientas separadas de lectura, escritura y eliminación](https://docs.customer.io/ai/mcp/get-started/). Brevo genera sus herramientas MCP a partir de su [especificación OpenAPI](https://developers.brevo.com/docs/mcp-protocol).

## Comparativa punto por punto

| | MCP | API REST |
| --- | --- | --- |
| Quién lo maneja | Una persona, a través de un asistente | Tu código |
| Tareas típicas | Redactar y revisar emails, crear audiencias, programar una campaña, leer analíticas | Activar disparadores por eventos, crear o actualizar contactos, enviar emails transaccionales, consultar periódicamente el estado de un envío |
| Autenticación | Inicio de sesión con OAuth, o una clave de API para los clientes sin OAuth | Clave de API, limitada a una marca o a una organización |
| Seguridad | En las conexiones OAuth y de organización, Brew detiene los envíos reales hasta que se confirman | Lo decide tu código; usa claves de idempotencia y tus propios pasos de revisión |
| Gestión de errores | El asistente lee el error y vuelve a intentarlo o te pregunta | Ramificas según códigos de error estables y reintentas con espera progresiva (backoff) |
| Tamaño de la respuesta | Limitado por la ventana de contexto del asistente | Limitado solo por la paginación |
| Ideal cuando | La tarea requiere criterio o iteración | La tarea tiene que ejecutarse siempre igual |

## Cuándo conviene usar MCP

Usa MCP cuando el trabajo es una conversación:

- Producción de campañas. “Escribe el email de novedades del producto de octubre a partir de este registro de cambios, envíame una prueba y prográmalo para el martes a las 9:00”. El asistente llama a `create_email`, `edit_email`, `send_email` con `test: true` y luego a `send_email` con `scheduledAt`, y se detiene hasta que lo apruebes.
- Preguntas sobre la audiencia. “¿Cuántos clientes de Pro se registraron antes de julio y abrieron algún email el mes pasado?”. El asistente combina `search_contacts`, consultas de campos y `create_audience`.
- Análisis. “¿Qué automatización tiene la peor tasa de clics y qué ha cambiado?”. El asistente lee `get_email_analytics` y el rendimiento de las automatizaciones.
- Configuración puntual. Crear un disparador y una automatización una sola vez, con una persona que revisa cada paso.

En Brew, los emails generados por MCP usan el mismo documento de marca que los que se generan en la app. El [artículo sobre el MCP de Brew](/es/blog/brew-mcp) explica la configuración del cliente.

Las respuestas de MCP tienen que caber en el contexto del asistente. El [artículo de Brew sobre los flujos](/es/blog/email-flows) señala que, si pides el HTML completo por MCP, solo recibes el primer paso o los dos primeros de una secuencia larga, mientras que la ruta REST devuelve el cuerpo de todos los emails.

## Cuándo conviene usar la API REST

Usa la API cuando el email forma parte de tu producto:

- Disparadores por eventos. Cuando alguien se registra, tu backend llama a `POST /v1/automations/triggers/{triggerEventId}/fire` con el email y los campos del usuario. La automatización publicada se encarga del resto.
- Emails transaccionales. Los recibos y los restablecimientos de contraseña se activan del mismo modo, mediante una automatización en un dominio con propósito transaccional. Consulta [emails transaccionales](/es/blog/transactional-emails).
- Sincronización de contactos. `POST /v1/contacts` crea o actualiza hasta 1000 contactos por solicitud.
- Monitorización. `GET /v1/sends/{sendId}` devuelve el estado y las estadísticas para un panel o una alerta.

En los endpoints que lo admiten, reutiliza la misma `Idempotency-Key` y el mismo cuerpo de la solicitud en los reintentos dentro de la ventana documentada de 24 horas (las activaciones de disparadores se deduplican por la clave durante 90 días). Usa una clave distinta para cada operación lógica distinta; lee el contrato del endpoint antes de dar por hecho que una escritura está cubierta. Los encabezados de límite de solicitudes te indican cuándo debes esperar antes de reintentar. Las respuestas de error de la API incluyen un `code`, como `CONSENT_REQUIRED`, que puedes usar para ramificar. Gestiona los fallos de red por separado. La [guía de la API](https://brew.new/api/v1/llms.txt) de Brew describe todo esto.

## Dónde encaja la CLI

Los agentes de programación que trabajan en una terminal suelen funcionar mejor con una CLI que con cualquiera de las otras dos opciones. La [CLI](https://docs.brew.new/api-reference/cli/agents) de Brew devuelve la respuesta de la API como una sola línea JSON cuando no está conectada a una terminal, y usa códigos de salida con los que un agente puede actuar. El código 4 significa que hace falta una confirmación, y la CLI muestra el comando exacto que hay que volver a ejecutar con `--yes` después de la aprobación. También genera contratos de payload tipados con `brew-cli types`, lo que mantiene las llamadas de tu backend a los disparadores en sintonía con el esquema de cada disparador.

## Un flujo de trabajo combinado

Así es como un equipo SaaS podría repartir el trabajo:

1. En Cursor o en Claude, alguien de desarrollo usa MCP para crear el disparador `user_signed_up` y una automatización de bienvenida, la prueba con `test_automation` y la publica.
2. El backend activa el disparador a través de la API REST en cada registro, con una clave de idempotencia construida a partir del ID del usuario.
3. Cada mes, alguien de marketing pide a Claude por MCP que redacte y programe el email de novedades del producto.
4. Una tarea programada de la aplicación comprueba el estado actual de activación o de facturación antes de lanzar un evento aparte de recordatorio para quienes cumplan los requisitos. Sincronizar los campos de contacto no basta para actualizar el payload del evento original de un flujo en curso.

En los pasos 1 y 3, una persona revisa el trabajo del asistente. Los pasos 2 y 4 se ejecutan en cada registro o cada noche sin que nadie los supervise.

## Preguntas frecuentes

### ¿MCP es más lento o menos fiable que la API?

Añade un asistente entre tú y el endpoint, así que una solicitud requiere más pasos, y el asistente puede elegir la herramienta equivocada. Eso no es un problema en el trabajo interactivo, pero sí en un evento de registro que tiene que activarse siempre.

### ¿Cuál es más seguro?

Brew exige confirmar los envíos reales en las conexiones OAuth y de organización. Con los clientes que usan una clave de API de marca, configura tu propia política de aprobación. Con la API, protege las claves en variables de entorno, usa claves limitadas a la marca siempre que puedas y añade claves de idempotencia a cada escritura que se reintente.

### ¿Puede un agente de mi propio producto usar la API como herramientas?

Sí. La [guía de integración con agentes](https://docs.brew.new/integrations/ai-agents/use-brew-with-ai-agents) de Brew explica cómo conectar los endpoints de la API como herramientas de llamada a funciones (function calling), con el SDK encargándose de la autenticación y los reintentos.

## Siguiente paso

Para probar las dos mitades, conecta el [servidor MCP](/es/mcp) en tu asistente para el trabajo con campañas y crea una clave de API para el disparador que va a activar tu backend.