Erstelle, teste und veröffentliche Onboarding-E-Mails mit Cursor und dem MCP-Server von Brew, mit Backend-Events und Statusprüfungen vor jedem Follow-up.
Eine Onboarding-E-Mail hängt an denselben Event-Daten wie dein Produkt. Wenn du aus Cursor heraus arbeitest, prüfst du den Handler für die Registrierung, legst den passenden Trigger in Brew an und kontrollierst die E-Mail, alles an einem Ort. Das Veröffentlichen des Flows und die Freigabe von Live-Versänden bleiben trotzdem in der Verantwortung eines Menschen.
Füg diesen Server in den MCP-Einstellungen von Cursor oder in der Datei .cursor/mcp.json deines Projekts hinzu:
{
"mcpServers": {
"brew": { "url": "https://brew.new/api/mcp" }
}
}Schließ die OAuth-Anmeldung bei Brew ab und wähl die gewünschte Marke. Bitte den Agenten, get_brew_capabilities aufzurufen. Nutzt dein Client ein anderes Konfigurationsformat, folge der Anleitung zur Einrichtung der Clients. Halte API-Keys aus dem Chat und aus dem Repository heraus.
Lass Cursor den Code finden, der ein neues Konto in der Datenbank festschreibt. Leg fest, was als Aktivierung zählt, etwa das Anlegen eines ersten Projekts. Dieser Walkthrough lässt die Bedingungsprüfungen in der Anwendung und nutzt zwei getrennte Trigger:
Definiere mit save_trigger jede Payload, einschließlich des erforderlichen E-Mail-Strings. Speichere die tatsächlich zurückgegebenen Trigger-IDs. Ein Anzeigename wie user_signed_up ersetzt nicht die ID für die API.
Ein brauchbares erstes Briefing:
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.Der Agent kann create_email, edit_email und save_automation nutzen. Öffne die Ergebnisse in Brew und prüf Layout, Texte, Links und Versanddomain. Nutze die dokumentierte Syntax für Merge-Tags, samt einem getesteten Fallback für einen fehlenden Namen.
Setz in einem linearen Pfad keinen Filter activated is false vor ein Follow-up mit activated is true. Ein Filter, den ein Kontakt nicht besteht, beendet alle nachfolgenden Schritte. Event-Felder wie payload.activated bleiben auch nach einer Wartezeit unverändert. Als Alternative zu diesem Rezept, bei dem deine Anwendung den Zeitplan steuert, kannst du ein boolesches Kontaktfeld anlegen und synchronisieren und nach jeder relevanten Wartezeit contact.activated prüfen. Diese Bedingung liest den aktuellen Kontakt in Brew, nicht deine Anwendungsdatenbank. Mehr dazu im Leitfaden zur Testphasen-Sequenz.
Hol den Payload-Vertrag jedes Triggers mit get_trigger_contract ab oder generiere die Verträge mit der CLI. Löse den Registrierungs-Trigger aus, nachdem die Transaktion für das neue Konto abgeschlossen ist.
Dieses Shell-Beispiel setzt voraus, dass BREW_SIGNUP_TRIGGER_ID die ID enthält, die du beim Anlegen des Triggers zurückbekommen hast, und dass sein Schema firstName deklariert:
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"}}'Nutze pro Registrierungs-Event einen stabilen Key, behalte ihn für Wiederholungen und sieh dir fehlgeschlagene Antworten an. Halte dich an die Idempotenz-Regeln der API.
Wenn eine Erinnerung fällig ist, liest deine Anwendung das aktuelle Konto. Ist der Nutzer aktiviert, gelöscht oder erfüllt er die Bedingungen aus einem anderen Grund nicht, löst sie den Erinnerungs-Trigger nicht aus. Andernfalls sendet sie ein neues Event mit aktuellen Daten. Eine Aktualisierung eines Kontaktfelds allein bricht die ursprüngliche Ausführung nicht ab.
Nutze test_automation mit Empfängern, die du kontrollierst. Prüf das aktuelle Testverhalten und sieh dir den Ausführungsverlauf an. Teste auch den Scheduler deiner Anwendung:
Prüf den Versandzweck der Domain und die Anforderungen an die Einwilligung. Veröffentliche dann ausdrücklich mit save_automation und published: true. Eine veröffentlichte Automatisierung kann bei echten Events ausgeführt werden.
Zum Design der Sequenz insgesamt siehe den Beitrag zur Willkommensserie. Welche Schnittstelle dein Backend nutzen sollte, klärt MCP vs. REST.
