Nutze MCP für E-Mail-Arbeit mit einem Assistenten und die REST-API für App-Events. Authentifizierung, Freigaben, Wiederholungen und Brew-Workflows im Vergleich.

Jemand aus der Entwicklung in deinem Team verbindet die E-Mail-Plattform mit Claude und entwirft in einem Chatfenster die Kampagne für nächste Woche. Am nächsten Morgen fragt jemand, ob die Willkommens-E-Mail nach der Registrierung nicht genauso laufen könnte, über den Assistenten. In der Dokumentation der Plattform stehen ein MCP-Server und eine REST-API nebeneinander.
Die meisten E-Mail-Plattformen, die Agenten unterstützen, bieten inzwischen diese beiden Zugänge. Über einen MCP-Server ruft ein KI-Assistent die Tools der Plattform im Gespräch auf. Eine REST-API stellt Operationen bereit, die dein Code direkt aufrufen kann. Darunter landen beide oft bei denselben Endpunkten. Die Entscheidung hängt also davon ab, wer die Arbeit macht und wann.
Nutze MCP, wenn ein Mensch über einen Assistenten arbeitet, und die REST-API, wenn dein Produkt E-Mails versenden muss, ohne dass jemand zuschaut. Die meisten Teams nutzen am Ende beides.
MCP, das Model Context Protocol, ist ein offener Standard, über den KI-Clients wie Claude, ChatGPT und Cursor Tools bereitgestellt bekommen. Der Client liest eine Liste von Tools mit Beschreibungen und Schemas und wählt anhand deiner Anfrage aus, welche er aufruft. Der Server von Brew liegt unter https://brew.new/api/mcp und unterstützt OAuth: Du meldest dich an und wählst eine Marke, statt mit Keys zu hantieren.
Eine REST-API ist eine Sammlung von HTTP-Endpunkten, die dein Code aufruft. Brew veröffentlicht für seine API eine OpenAPI-Spezifikation, ein TypeScript-SDK und einen Leitfaden für Agenten als reinen Text. Jeder Aufruf trägt einen API-Key, und dein Code entscheidet, was wann aufgerufen wird.
Andere Anbieter folgen demselben Muster. Der MCP-Server von Customer.io verpackt seine API in getrennte Tools zum Lesen, Schreiben und Löschen. Brevo generiert seine MCP-Tools aus seiner OpenAPI-Spezifikation.
| MCP | REST-API | |
|---|---|---|
| Wer steuert | Ein Mensch, über einen Assistenten | Dein Code |
| Typische Aufgaben | E-Mails entwerfen und überarbeiten, Zielgruppen aufbauen, eine Kampagne planen, Analysen lesen | Event-Trigger auslösen, Kontakte anlegen oder aktualisieren, Transaktions-E-Mails senden, Versandstatus abfragen |
| Authentifizierung | Anmeldung per OAuth oder ein API-Key für Clients ohne OAuth | API-Key, beschränkt auf eine Marke oder eine Organisation |
| Sicherheit | Brew hält Live-Versände bei OAuth- und Organisationsverbindungen für eine Bestätigung an | Dein Code entscheidet; nutze Idempotency-Keys und eigene Prüfschritte |
| Umgang mit Fehlern | Der Assistent liest den Fehler und versucht es erneut oder fragt dich | Du verzweigst anhand stabiler Fehlercodes und wiederholst mit Backoff |
| Größe der Antwort | Begrenzt durch das Kontextfenster des Assistenten | Nur durch die Paginierung begrenzt |
| Ideal, wenn | die Aufgabe Urteilsvermögen oder mehrere Durchgänge braucht | die Aufgabe jedes Mal gleich ablaufen muss |
Nutze MCP, wenn die Arbeit ein Gespräch ist:
create_email, edit_email und send_email mit test: true auf, dann send_email mit scheduledAt, und wartet auf deine Freigabe.search_contacts, Abfragen von Feldern und create_audience.get_email_analytics und die Performance der Automatisierungen.In Brew nutzen E-Mails, die per MCP generiert werden, dasselbe Markendokument wie E-Mails aus der App. Wie du den Client einrichtest, steht im Beitrag zum MCP-Server von Brew.
MCP-Antworten müssen in den Kontext des Assistenten passen. Im Beitrag zu Flows steht, dass eine Anfrage nach dem vollständigen HTML per MCP bei einer langen Sequenz nur den ersten oder die ersten beiden Schritte zurückgibt, während die REST-Route jeden E-Mail-Inhalt liefert.
Nutze die API, wenn E-Mail Teil deines Produkts ist:
POST /v1/automations/triggers/{triggerEventId}/fire mit der E-Mail-Adresse und den Feldern der Person auf. Den Rest übernimmt die veröffentlichte Automatisierung.POST /v1/contacts legt bis zu 1.000 Kontakte pro Anfrage an oder aktualisiert sie.GET /v1/sends/{sendId} liefert Status und Statistiken für ein Dashboard oder eine Warnung.Bei Endpunkten, die das unterstützen, verwendest du für Wiederholungen innerhalb des dokumentierten Zeitfensters von 24 Stunden denselben Idempotency-Key und denselben Request-Body (Trigger-Auslösungen werden 90 Tage lang anhand des Keys dedupliziert). Für eine andere logische Operation nimmst du einen anderen Key; lies die Beschreibung des Endpunkts, bevor du davon ausgehst, dass ein Schreibvorgang abgedeckt ist. Rate-Limit-Header sagen dir, wann du langsamer machen solltest. Fehlerantworten der API enthalten einen code, etwa CONSENT_REQUIRED, anhand dessen du verzweigen kannst. Netzwerkfehler behandelst du separat. Der API-Leitfaden von Brew beschreibt all das.
Coding-Agenten im Terminal kommen mit einer CLI oft besser zurecht als mit den beiden anderen Optionen. Die CLI von Brew gibt die API-Antwort als eine JSON-Zeile aus, wenn sie nicht an ein Terminal angebunden ist, und nutzt Exit-Codes, auf die ein Agent reagieren kann. Code 4 bedeutet, dass eine Bestätigung nötig ist, und die CLI gibt den genauen Befehl aus, den du nach der Freigabe mit --yes erneut ausführst. Außerdem generiert sie mit brew-cli types typisierte Payload-Verträge, damit die Trigger-Aufrufe deines Backends zum Schema des Triggers passen.
So könnte ein SaaS-Team die Arbeit aufteilen:
user_signed_up und eine Willkommens-Automatisierung an, testet sie mit test_automation und veröffentlicht sie.In den Schritten 1 und 3 prüft ein Mensch die Arbeit des Assistenten. Die Schritte 2 und 4 laufen bei jeder Registrierung oder jede Nacht, ohne dass jemand zuschaut.
MCP schaltet einen Assistenten zwischen dich und den Endpunkt. Eine Anfrage braucht also mehr Schritte, und der Assistent kann das falsche Tool wählen. Für interaktive Arbeit ist das in Ordnung, für ein Registrierungs-Event, das jedes Mal ausgelöst werden muss, nicht.
Brew verlangt bei OAuth- und Organisationsverbindungen eine Bestätigung für Live-Versände. Bei Clients, die mit einem API-Key der Marke verbunden sind, richtest du eigene Freigaberegeln ein. Bei der API schützt du Keys in Umgebungsvariablen, nutzt nach Möglichkeit Keys, die auf eine Marke beschränkt sind, und gibst jedem wiederholten Schreibvorgang einen Idempotency-Key mit.
Ja. Der Leitfaden zur Integration von Agenten von Brew beschreibt, wie du API-Endpunkte als Tools für Function Calling einbindest. Authentifizierung und Wiederholungen übernimmt dabei das SDK.
Um beide Hälften auszuprobieren, verbinde den MCP-Server in deinem Assistenten für die Kampagnenarbeit und erstelle einen API-Key für den Trigger, den dein Backend auslösen soll.
