Usa MCP para el trabajo con un asistente y la API REST para los eventos de tu app. Compara autenticación, aprobaciones, reintentos y flujos de trabajo en Brew.
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.
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 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. Brevo genera sus herramientas MCP a partir de su especificación OpenAPI.
| 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 |
Usa MCP cuando el trabajo es una conversación:
create_email, edit_email, send_email con test: true y luego a send_email con scheduledAt, y se detiene hasta que lo apruebes.search_contacts, consultas de campos y create_audience.get_email_analytics y el rendimiento de las automatizaciones.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 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 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.
Usa la API cuando el email forma parte de tu producto:
POST /v1/automations/triggers/{triggerEventId}/fire con el email y los campos del usuario. La automatización publicada se encarga del resto.POST /v1/contacts crea o actualiza hasta 1000 contactos por solicitud.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 de Brew describe todo esto.
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 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.
Así es como un equipo SaaS podría repartir el trabajo:
user_signed_up y una automatización de bienvenida, la prueba con test_automation y la publica.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.
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.
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.
Sí. La guía de integración con agentes 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.
Para probar las dos mitades, conecta el servidor 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.
