Wiele pracy nad e-mailami zaczyna się już dziś w asystencie AI: od szkicu, poprawki albo pytania o kampanię. Udostępniliśmy Brew przez MCP, żeby z poziomu tej samej rozmowy można było działać także w obszarze roboczym e-maili.

Połączenie korzysta z tej samej marki i tych samych rekordów co aplikacja. Zgodny asystent może wywoływać narzędzia Brew, zamiast podawać Ci instrukcje, które potem musisz ręcznie powtórzyć.

Co daje połączenie

Narzędzia MCP Brew obejmują tworzenie i edycję e-maili, kontakty, kampanie, automatyzacje i raporty. Dokładną listę dostępnych operacji i ich parametrów poznasz przez get_brew_capabilities i opisy narzędzi.

Po połączeniu zacznij właśnie od tego wywołania. Nie zgaduj nazwy narzędzia na podstawie przykładu z bloga, skoro działający serwer sam opisze obsługiwaną operację.

Asystent to kolejna aplikacja kliencka Brew. Korzysta z tych samych danych produktu i zasad wysyłki.

Połącz się przez OAuth lub klucz API

Adres URL zdalnego serwera:

https://brew.new/api/mcp

Jeśli Twój klient obsługuje połączenie MCP z Brew przez OAuth, zaloguj się, wybierz markę i sprawdź, jaki dostęp przyznajesz. Jeśli klient korzysta z konfiguracji z kluczem API, utwórz w Brew odpowiedni klucz przypisany do marki i postępuj zgodnie z formatem konfiguracji opisanym w dokumentacji klienta.

W klientach, które używają konfiguracji JSON mcpServers, połączenie może wyglądać tak:

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

To klucz zastępczy, a nie prawdziwe dane uwierzytelniające. Prawdziwe klucze przechowuj w mechanizmie sekretów, który obsługuje Twój klient. Wersja webowa ChatGPT korzysta z wtyczek, a aplikacja desktopowa ChatGPT i Codex współdzielą konfigurację MCP. Inne aplikacje klienckie mogą wymagać innych nazw pól albo innej nazwy transportu, np. streamableHttp w Cline. Postępuj zgodnie z instrukcją konfiguracji klienta.

Daj mu na początek zadanie o jasnych granicach

Poproś asystenta, żeby na podstawie zatwierdzonych faktów utworzył wersję roboczą e-maila dla konkretnej grupy odbiorców. Poproś go też o pokazanie podglądu i podanie identyfikatora e-maila. Przeczytaj i popraw wynik, zanim przejdziesz do rzeczywistej wysyłki.

Przy planowaniu podaj grupę odbiorców, nadawcę, datę, godzinę i strefę czasową. Potwierdź szczegóły kampanii, która z tego powstanie. W przypadku automatyzacji odróżniaj utworzenie wersji roboczej od jej opublikowania.

Brew wymaga potwierdzenia rzeczywistych wysyłek w połączeniach OAuth i połączeniach obejmujących całą organizację. Aplikacja kliencka korzystająca z klucza API marki potrzebuje własnych zasad zatwierdzania. MCP nie narzuca klientom jednego, uniwersalnego sposobu potwierdzania, więc zanim przyznasz dostęp do wysyłki, sprawdź zarówno ustawienia klienta, jak i wymagania serwera.

Połączone narzędzia nadal wymagają planu

Asystent z dostępem do Brew i osobnego CRM może koordynować pracę w obu narzędziach, ale to nie tworzy automatycznej integracji między wszystkimi rekordami. Ustal, który system jest właścicielem danych, jak docierają aktualizacje i jak obsługiwane są błędy.

W odroczonych przypomnieniach cyklu życia warunki na contact.<name> mogą po kroku oczekiwania odczytywać bieżące pola kontaktu w Brew. Dbaj o synchronizację tych pól; pola danych zdarzenia nadal odzwierciedlają pierwotne zdarzenie. Jeśli to, czy kontakt spełnia warunki, zależy od stanu poza Brew, sprawdzaj to po stronie aplikacji. Oba podejścia wyjaśnia poradnik o sekwencji e-maili w okresie próbnym.

Zacznij od wersji roboczej, którą możesz sprawdzić

Na Twoim miejscu połączyłbym serwer, wywołał get_brew_capabilities i przygotował jeden e-mail, którego Twój zespół i tak potrzebuje. To da Ci konkretną podstawę do oceny takiego sposobu pracy.

Przygotuj jasny brief, sprawdź wynik i przetestuj go w skrzynce. Zasady wysyłki są takie same niezależnie od tego, czy operację uruchamia człowiek, czy asystent.

Thomas