MCP používej pro práci s e-maily přes asistenta a REST API pro události z aplikace. Porovnej autentizaci, schvalování, opakované pokusy a postupy v Brew.
Vývojář z tvého týmu připojí e-mailovou platformu k aplikaci Claude a v okně chatu připraví koncept kampaně na příští týden. Druhý den ráno se někdo zeptá, jestli by stejným způsobem, přes asistenta, nemohl běžet i uvítací e-mail po registraci. Dokumentace platformy uvádí MCP server a REST API vedle sebe.
Většina e-mailových platforem, které podporují agenty, dnes nabízí právě tyhle dva vstupy. MCP server umožňuje AI asistentovi volat nástroje platformy v průběhu konverzace. REST API zpřístupňuje operace, které tvůj kód může volat přímo. Pod povrchem často vedou ke stejným endpointům, takže volba závisí na tom, kdo práci dělá a kdy.
MCP používej, když člověk pracuje přes asistenta, a REST API, když tvůj produkt potřebuje posílat e-maily, aniž by na to někdo dohlížel. Většina týmů nakonec používá obojí.
MCP neboli Model Context Protocol je otevřený standard, přes který se nástroje zpřístupňují AI klientům, jako jsou Claude, ChatGPT a Cursor. Klient si přečte seznam nástrojů s popisy a schématy a podle tvého požadavku vybere, který zavolá. Server Brew běží na https://brew.new/api/mcp a podporuje OAuth, takže se jen přihlásíš a vybereš značku a klíče řešit nemusíš.
REST API je sada HTTP endpointů, které volá tvůj kód. Brew ke svému API zveřejňuje specifikaci OpenAPI, TypeScript SDK a průvodce pro agenty v prostém textu. Každé volání nese API klíč a tvůj kód rozhoduje, co a kdy zavolá.
Ostatní výrobci postupují podobně. MCP server Customer.io obaluje svoje API do samostatných nástrojů pro čtení, zápis a mazání. Brevo své MCP nástroje generuje ze specifikace OpenAPI.
| MCP | REST API | |
|---|---|---|
| Kdo to řídí | Člověk přes asistenta | Tvůj kód |
| Typické úkoly | Koncepty a úpravy e-mailů, sestavení publik, naplánování kampaně, čtení analytiky | Aktivace spouštěčů událostí, vložení nebo aktualizace kontaktů, odesílání transakčních e-mailů, zjišťování stavu rozesílky |
| Autentizace | Přihlášení přes OAuth, nebo API klíč pro klienty bez OAuth | API klíč omezený na značku nebo organizaci |
| Bezpečnost | U připojení přes OAuth a pro celou organizaci Brew ostré rozesílky pozdrží do potvrzení | Rozhoduje tvůj kód; používej idempotenční klíče a vlastní kroky kontroly |
| Řešení chyb | Asistent si chybu přečte a zkusí to znovu, nebo se tě zeptá | Větvíš podle stabilních chybových kódů a opakuješ s postupně delší prodlevou (backoff) |
| Velikost odpovědi | Omezená kontextovým oknem asistenta | Omezená jen stránkováním |
| Nejlepší, když | Úkol vyžaduje úsudek nebo opakované ladění | Úkol musí pokaždé proběhnout stejně |
MCP používej, když práce probíhá jako konverzace:
create_email, edit_email, send_email s test: true a pak send_email s scheduledAt a zastaví se, aby počkal na tvé schválení.search_contacts, vyhledávání polí a create_audience.get_email_analytics a výkon automatizací.V Brew používají e-maily vygenerované přes MCP stejný dokument značky jako e-maily vygenerované v aplikaci. Nastavení klienta popisuje článek o MCP v Brew.
Odpovědi přes MCP se musí vejít do kontextu asistenta. Článek o sekvencích od Brew upozorňuje, že když si přes MCP řekneš o celé HTML, dostaneš u dlouhé sekvence jen první jeden nebo dva kroky, zatímco cesta přes REST vrátí obsah všech e-mailů.
API používej, když jsou e-maily součástí tvého produktu:
POST /v1/automations/triggers/{triggerEventId}/fire s e-mailem a poli uživatele. O zbytek se postará publikovaná automatizace.POST /v1/contacts v jednom požadavku vloží nebo aktualizuje až 1 000 kontaktů.GET /v1/sends/{sendId} vrací stav a statistiky pro přehled nebo upozornění.U endpointů, které to podporují, při opakovaných pokusech v rámci zdokumentovaného 24hodinového okna znovu použij stejný Idempotency-Key i tělo požadavku (u spuštění spouštěčů se duplicity podle klíče rozpoznávají po dobu 90 dní). Pro jinou logickou operaci použij jiný klíč; než začneš předpokládat, že se idempotence týká i daného zápisu, přečti si popis endpointu. Hlavičky s limity požadavků ti řeknou, kdy zpomalit. Chybové odpovědi API obsahují code, například CONSENT_REQUIRED, podle kterého můžeš větvit. Výpadky sítě řeš zvlášť. To všechno popisuje průvodce API od Brew.
Programovací agenti v terminálu si často vedou líp s CLI než s kteroukoli z obou možností. CLI od Brew vrací odpověď API jako jeden řádek JSON, když není připojené k terminálu, a používá návratové kódy, podle kterých agent může jednat. Kód 4 znamená, že je potřeba potvrzení, a CLI vypíše přesný příkaz, který se po schválení spustí znovu s --yes. Pomocí brew-cli types také generuje typovaná schémata payloadu, díky kterým volání spouštěčů z tvého backendu drží krok se schématem spouštěče.
Takhle si může práci rozdělit třeba SaaS tým:
user_signed_up a uvítací automatizaci, otestuje ji pomocí test_automation a publikuje ji.V krocích 1 a 3 práci asistenta kontroluje člověk. Kroky 2 a 4 běží při každé registraci nebo každou noc, aniž by na ně kdokoli dohlížel.
MCP mezi tebe a endpoint přidává asistenta, takže požadavek potřebuje víc kroků a asistent může zvolit špatný nástroj. U interaktivní práce to nevadí, ale pro událost registrace, která se musí spustit pokaždé, je to špatná volba.
Brew u připojení přes OAuth a pro celou organizaci vyžaduje potvrzení ostré rozesílky. U klientů připojených přes API klíč značky si nastav vlastní pravidla schvalování. U API drž klíče v proměnných prostředí. Kde to jde, používej klíče omezené na značku a ke každému opakovanému zápisu přidávej idempotenční klíč.
Ano. Průvodce integrací s agenty od Brew popisuje, jak zapojit endpointy API jako nástroje pro volání funkcí (function calling), přičemž autentizaci a opakované pokusy řeší SDK.
Pokud chceš vyzkoušet obě poloviny, připoj ve svém asistentovi MCP server pro práci na kampaních a vytvoř jeden API klíč pro spouštěč, který bude aktivovat tvůj backend.
