# MCP vs. REST-API im E-Mail-Marketing: Welcher Weg passt?

Kanonische URL: https://brew.new/de/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use
Autor: Thomas Park
Veröffentlicht: 2026-09-23
Aktualisiert: 2026-09-29

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.

## Das Wichtigste in Kürze

- MCP ist für interaktive Arbeit, die viel Urteilsvermögen verlangt: eine Kampagne entwerfen, eine Zielgruppe aufbauen, fragen, warum ein Versand hinter den Erwartungen blieb.
- Die REST-API ist für Abläufe im Produktivbetrieb: einen Trigger auslösen, wenn sich jemand registriert, Kontakte synchronisieren, Belege versenden.
- Eine CLI liegt dazwischen. Sie lässt sich wie die API in Skripte einbauen, und Coding-Agenten können ihre Ausgabe lesen.
- Der MCP-Server von Brew verlangt bei OAuth- und Organisationsverbindungen eine Bestätigung für Live-Versände. Clients, die mit einem API-Key der Marke verbunden sind, brauchen eigene Freigaberegeln. Dein API-Code muss Prüfung, Idempotenz und Wiederholungen selbst mitbringen.

## Was die beiden sind

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](https://brew.new/api/v1/llms.txt) 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](https://docs.customer.io/ai/mcp/get-started/). Brevo generiert seine MCP-Tools aus seiner [OpenAPI-Spezifikation](https://developers.brevo.com/docs/mcp-protocol).

## Der direkte Vergleich

| | 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 |

## Wann MCP die richtige Wahl ist

Nutze MCP, wenn die Arbeit ein Gespräch ist:

- Kampagnenproduktion. „Schreib aus diesem Changelog das Produkt-Update für Oktober, schick mir einen Test und plan es für Dienstag um 9 Uhr ein.“ Der Assistent ruft `create_email`, `edit_email` und `send_email` mit `test: true` auf, dann `send_email` mit `scheduledAt`, und wartet auf deine Freigabe.
- Fragen zur Zielgruppe. „Wie viele Pro-Kunden haben sich vor Juli registriert und im letzten Monat irgendetwas geöffnet?“ Der Assistent kombiniert `search_contacts`, Abfragen von Feldern und `create_audience`.
- Analyse. „Welche Automatisierung hat die schlechteste Klickrate, und was hat sich geändert?“ Der Assistent liest `get_email_analytics` und die Performance der Automatisierungen.
- Einmalige Einrichtung. Einen Trigger und eine Automatisierung einmalig anlegen, wobei ein Mensch jeden Schritt prüft.

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](/de/blog/brew-mcp).

MCP-Antworten müssen in den Kontext des Assistenten passen. Im [Beitrag zu Flows](/de/blog/email-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.

## Wann die REST-API die richtige Wahl ist

Nutze die API, wenn E-Mail Teil deines Produkts ist:

- Event-Trigger. Wenn sich jemand registriert, ruft dein Backend `POST /v1/automations/triggers/{triggerEventId}/fire` mit der E-Mail-Adresse und den Feldern der Person auf. Den Rest übernimmt die veröffentlichte Automatisierung.
- Transaktions-E-Mails. Belege und Passwort-Resets werden genauso ausgelöst, über eine Automatisierung auf einer Domain mit dem Versandzweck „Transaktional“. Siehe [Transaktions-E-Mails](/de/blog/transactional-emails).
- Kontaktsynchronisierung. `POST /v1/contacts` legt bis zu 1.000 Kontakte pro Anfrage an oder aktualisiert sie.
- Monitoring. `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](https://brew.new/api/v1/llms.txt) von Brew beschreibt all das.

## Wo die CLI ins Spiel kommt

Coding-Agenten im Terminal kommen mit einer CLI oft besser zurecht als mit den beiden anderen Optionen. Die [CLI](https://docs.brew.new/api-reference/cli/agents) 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.

## Ein kombinierter Workflow

So könnte ein SaaS-Team die Arbeit aufteilen:

1. In Cursor oder Claude legt jemand aus der Entwicklung per MCP den Trigger `user_signed_up` und eine Willkommens-Automatisierung an, testet sie mit `test_automation` und veröffentlicht sie.
2. Das Backend löst den Trigger bei jeder Registrierung über die REST-API aus, mit einem Idempotency-Key, der aus der Nutzer-ID gebildet wird.
3. Jeden Monat bittet jemand aus dem Marketing Claude per MCP, das Produkt-Update zu entwerfen und einzuplanen.
4. Ein geplanter Job der Anwendung prüft den aktuellen Aktivierungs- oder Abrechnungsstatus, bevor er ein separates Erinnerungs-Event für Kontakte auslöst, die die Bedingungen erfüllen. Das Synchronisieren von Kontaktfeldern allein aktualisiert nicht die ursprüngliche Event-Payload eines laufenden Flows.

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.

## Häufig gestellte Fragen

### Ist MCP langsamer oder weniger zuverlässig als die API?

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.

### Was ist sicherer?

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.

### Kann ein Agent in meinem eigenen Produkt die API als Tools nutzen?

Ja. Der [Leitfaden zur Integration von Agenten](https://docs.brew.new/integrations/ai-agents/use-brew-with-ai-agents) von Brew beschreibt, wie du API-Endpunkte als Tools für Function Calling einbindest. Authentifizierung und Wiederholungen übernimmt dabei das SDK.

## Nächster Schritt

Um beide Hälften auszuprobieren, verbinde den [MCP-Server](/de/mcp) in deinem Assistenten für die Kampagnenarbeit und erstelle einen API-Key für den Trigger, den dein Backend auslösen soll.