Crea, prueba y publica emails de onboarding con Cursor y el MCP de Brew. Añade eventos del backend y comprueba el estado actual antes de cada recordatorio.
Un email de onboarding depende de los mismos datos de eventos que tu producto. Trabajar desde Cursor te permite revisar el código que gestiona los registros, crear el disparador de Brew correspondiente y comprobar el email en un mismo lugar. Deja en manos de una persona la publicación del flujo y la aprobación de los envíos reales.
Añade este servidor en la configuración de MCP de Cursor o en el archivo .cursor/mcp.json de tu proyecto:
{
"mcpServers": {
"brew": { "url": "https://brew.new/api/mcp" }
}
}Completa el inicio de sesión OAuth de Brew y selecciona la marca que corresponda. Pide al agente que llame a get_brew_capabilities. Si tu cliente usa otro formato de configuración, sigue la guía de configuración de clientes. No pongas claves de API en el chat ni en el repositorio.
Pide a Cursor que localice el código que guarda una cuenta nueva en la base de datos. Decide qué cuenta como activación, por ejemplo, crear un primer proyecto. Esta guía deja las comprobaciones de requisitos en la aplicación y usa dos disparadores distintos:
Usa save_trigger para definir cada payload, incluida la cadena obligatoria del email. Guarda los ID de disparador que se devuelvan realmente. Un nombre visible como user_signed_up no sustituye al identificador de la API.
Este es un primer brief útil:
Create a welcome email for a new account.
One action: create a first project at https://app.example.com/projects/new.
Use the brand already selected in Brew. Do not invent statistics or testimonials.
Create a separate setup-reminder email for recipients our app confirms have not activated.
Leave both automations as drafts for review.El agente puede usar create_email, edit_email y save_automation. Abre los resultados en Brew y revisa la maquetación, los textos, los enlaces y el dominio de envío. Usa la sintaxis de etiquetas de combinación documentada, con un valor predeterminado probado para cuando falte el nombre.
No pongas un filtro activated is false en una ruta lineal antes de un seguimiento con activated is true. Un filtro que no se cumple detiene todos los nodos que vienen después. Los campos del evento, como payload.activated, no cambian después de una espera. Como alternativa a esta receta programada desde la aplicación, define y sincroniza un campo booleano del contacto y comprueba contact.activated después de cada espera relevante. Esa condición lee el contacto actual en Brew, no la base de datos de tu aplicación. Consulta la guía de secuencias para convertir pruebas gratuitas.
Obtén el contrato de cada disparador con get_trigger_contract o genera los contratos con la CLI. Activa el disparador de registro después de que se confirme la transacción que crea la cuenta.
Este ejemplo de shell da por hecho que BREW_SIGNUP_TRIGGER_ID contiene el identificador que se devolvió al crear el disparador y que su esquema declara firstName:
curl --fail-with-body \
"https://brew.new/api/v1/automations/triggers/${BREW_SIGNUP_TRIGGER_ID}/fire" \
-H "Authorization: Bearer ${BREW_API_KEY}" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: signup-example-account-123" \
-d '{"payload":{"email":"alex@example.com","firstName":"Alex"}}'Usa una clave estable por cada evento de registro, consérvala para los reintentos y revisa las respuestas con error. Sigue el contrato de idempotencia de la API.
Cuando toca enviar un recordatorio, tu aplicación lee el estado actual de la cuenta. Si el usuario ya se activó, se eliminó o por cualquier otro motivo no cumple los requisitos, la aplicación no activa el disparador del recordatorio. Si los cumple, envía un evento nuevo con los datos actuales. Actualizar un campo del contacto no basta para cancelar la ejecución original.
Usa test_automation con destinatarios controlados. Consulta cómo funcionan ahora las pruebas y revisa el historial de ejecuciones. Prueba también el programador de tareas de la aplicación:
Revisa el propósito del dominio de envío y los requisitos de consentimiento. Después, publica de forma explícita con save_automation y published: true. Una automatización publicada puede ejecutarse con eventos reales.
Para el diseño general de la secuencia, consulta secuencias de emails de bienvenida. Para elegir la interfaz que usa tu backend, consulta MCP frente a REST.
