# Dein KI-Assistent kann jetzt in Brew arbeiten

Kanonische URL: https://brew.new/de/blog/brew-mcp
Autor: Thomas Park
Veröffentlicht: 2026-06-26
Aktualisiert: 2026-10-15

Viel E-Mail-Arbeit beginnt heute schon in einem Assistenten: ein Entwurf, eine Überarbeitung oder eine Frage zu einer Kampagne. Damit diese Unterhaltung auch im E-Mail-Workspace etwas bewirken kann, haben wir Brew per MCP verfügbar gemacht.

Die Verbindung nutzt dieselbe Marke und dieselben Datensätze wie die App. Ein kompatibler Assistent kann die Tools von Brew direkt aufrufen, statt dir Anweisungen zu geben, die du dann von Hand umsetzen musst.

## Was die Verbindung bietet

Die MCP-Tools von Brew decken das Erstellen und Bearbeiten von E-Mails, Kontakte, Kampagnen, Automatisierungen und Reporting ab. Welche Operationen genau verfügbar sind und welche Eingaben sie erwarten, erfährst du über `get_brew_capabilities` und die Tool-Beschreibungen.

Starte nach dem Verbinden genau mit diesem Aufruf. Rate keinen Tool-Namen anhand eines Blog-Beispiels, wenn der Live-Server die unterstützte Operation selbst beschreiben kann.

![Ein Assistent, der sich per MCP mit Brew verbindet, um mit E-Mail-Tools zu arbeiten.](/blog/brew-mcp-architecture.png)

*Der Assistent ist ein weiterer Client von Brew. Er nutzt dieselben Produktdaten und Versandregeln.*

## Per OAuth oder API-Key verbinden

Die URL des Remote-Servers lautet:

```text
https://brew.new/api/mcp
```

Wenn dein Client die OAuth-Verbindung zum MCP-Server von Brew unterstützt, meldest du dich an, wählst die Marke und prüfst, welchen Zugriff du gewährst. Nutzt dein Client eine Konfiguration mit API-Key, erstellst du in Brew einen passenden Key, der auf die Marke beschränkt ist, und hältst dich an das dokumentierte Konfigurationsformat deines Clients.

Bei Clients mit einer JSON-Konfiguration über `mcpServers` kann die Verbindung so aussehen:

```json
{
  "mcpServers": {
    "brew": {
      "type": "http",
      "url": "https://brew.new/api/mcp",
      "headers": { "Authorization": "Bearer brew_YOUR_API_KEY" }
    }
  }
}
```

Das ist ein Platzhalter, kein echter Key. Echte Keys gehören in die Secret-Konfiguration, die dein Client dafür vorsieht. Die Web-Version von ChatGPT nutzt Plugins; die Desktop-App von ChatGPT und Codex teilen sich die MCP-Konfiguration. Andere Clients verlangen unter Umständen andere Feldnamen oder Transportbezeichnungen, etwa streamableHttp bei Cline. Folge der [Anleitung zur Einrichtung der Clients](https://docs.brew.new/api-reference/mcp/connect-your-client).

## Gib ihm eine klar umrissene erste Aufgabe

Bitte den Assistenten zum Beispiel, mit freigegebenen Fakten einen Entwurf für eine bestimmte Zielgruppe zu erstellen. Lass dir die Vorschau zeigen und die ID der E-Mail nennen. Lies und überarbeite das Ergebnis, bevor du zu einem Live-Versand übergehst.

Zum Planen nennst du Zielgruppe, Absender, Datum, Uhrzeit und Zeitzone. Prüf die Kampagnendetails, die dabei herauskommen. Bei Automatisierungen unterscheide zwischen dem Erstellen eines Entwurfs und dem Veröffentlichen.

Bei OAuth- und Organisationsverbindungen verlangt Brew eine Bestätigung für Live-Versände. Ein Client, der mit einem API-Key der Marke verbunden ist, braucht eigene Freigaberegeln. MCP schreibt Clients kein einheitliches Bestätigungsverhalten vor. Prüf deshalb die Einstellungen des Clients und die Anforderungen des Servers, bevor du Versandrechte vergibst.

## Auch verbundene Tools brauchen einen Plan

Ein Assistent mit Zugriff auf Brew und ein separates CRM kann die Arbeit in beiden koordinieren. Eine automatische Integration zwischen allen Datensätzen entsteht dadurch aber nicht. Leg fest, welches System für welche Daten maßgeblich ist, wie Aktualisierungen ankommen und wie Fehler behandelt werden.

Bei verzögerten Lifecycle-Erinnerungen können Event-Bedingungen auf `contact.<name>` nach einer Wartezeit die aktuellen Kontaktfelder in Brew lesen. Halte diese Felder synchron; die Felder der Event-Payload spiegeln weiterhin das ursprüngliche Event wider. Bedingungen, die von externen Daten abhängen, prüfst du in deiner Anwendung. Der [Leitfaden zur Testphasen-Sequenz](/de/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events) erklärt beide Ansätze.

## Starte mit einem Entwurf, den du prüfen kannst

Ich würde den Server verbinden, `get_brew_capabilities` aufrufen und eine E-Mail erstellen, die dein Team ohnehin braucht. So kannst du den Workflow an etwas Konkretem beurteilen.

Schreib ein [klares Briefing](/de/blog/how-to-brief-an-email-agent), prüf das Ergebnis und teste es in einem Posteingang. Die [Versandregeln](/de/blog/agent-email-deliverability) sind dieselben, egal ob ein Mensch oder ein Assistent den Vorgang startet.

Thomas