Use o MCP no e-mail feito via assistente e a API REST nos eventos da aplicação. Compare autenticação, aprovações, novas tentativas e fluxos de trabalho no Brew.
Um desenvolvedor da sua equipe conecta a plataforma de e-mail ao Claude e rascunha a campanha da semana que vem em uma janela de chat. Na manhã seguinte, alguém pergunta se o e-mail de boas-vindas do cadastro poderia funcionar do mesmo jeito, pelo assistente. A documentação da plataforma lista um servidor MCP e uma API REST lado a lado.
A maioria das plataformas de e-mail compatíveis com agentes hoje oferece essas duas portas de entrada. Um servidor MCP permite que um assistente de IA chame as ferramentas da plataforma durante uma conversa. Uma API REST expõe operações que o seu código pode chamar diretamente. Por baixo, as duas muitas vezes chegam aos mesmos endpoints, então a escolha depende de quem faz o trabalho e de quando.
Use o MCP quando uma pessoa trabalha por meio de um assistente e a API REST quando o seu produto precisa enviar e-mails sem ninguém olhando. A maioria das equipes acaba usando os dois.
O MCP, ou Model Context Protocol, é um padrão aberto para expor ferramentas a clientes de IA como o Claude, o ChatGPT e o Cursor. O cliente lê uma lista de ferramentas com descrições e esquemas e escolhe quais chamar com base no seu pedido. O servidor do Brew fica em https://brew.new/api/mcp e aceita OAuth: você faz login e escolhe uma marca, em vez de lidar com chaves.
Uma API REST é um conjunto de endpoints HTTP que o seu código chama. O Brew publica uma especificação OpenAPI, um SDK em TypeScript e um guia da API para agentes em texto simples. Toda chamada leva uma chave de API, e o seu código decide o que chamar e quando.
Outros fornecedores seguem o mesmo padrão. O servidor MCP do Customer.io envolve a API em ferramentas separadas de leitura, escrita e exclusão. O Brevo gera as ferramentas MCP a partir da própria especificação OpenAPI.
| MCP | API REST | |
|---|---|---|
| Quem conduz | Uma pessoa, por meio de um assistente | O seu código |
| Tarefas típicas | Rascunhar e revisar e-mails, montar públicos, agendar uma campanha, ler análises | Disparar gatilhos de evento, criar ou atualizar contatos, enviar e-mails transacionais, consultar o status dos envios |
| Autenticação | Login com OAuth ou chave de API para clientes sem OAuth | Chave de API, com escopo de marca ou de organização |
| Segurança | O Brew pausa os envios reais para confirmação nas conexões OAuth e de organização | O seu código decide; use chaves de idempotência e as suas próprias etapas de revisão |
| Tratamento de falhas | O assistente lê o erro e tenta de novo ou pergunta a você | Você trata cada código de erro estável e tenta de novo com backoff |
| Tamanho da resposta | Limitado pela janela de contexto do assistente | Limitado só pela paginação |
| Ideal quando | A tarefa exige discernimento ou iteração | A tarefa precisa rodar sempre do mesmo jeito |
Use o MCP quando o trabalho é uma conversa:
create_email, edit_email, send_email com test: true e depois send_email com scheduledAt, e aí aguarda a sua aprovação.search_contacts, consultas de campos e create_audience.get_email_analytics e o desempenho das automações.No Brew, os e-mails gerados via MCP usam o mesmo documento de marca dos e-mails gerados no app. O post sobre o MCP do Brew explica a configuração dos clientes.
As respostas do MCP precisam caber no contexto do assistente. O post do Brew sobre fluxos observa que pedir o HTML completo via MCP retorna só a primeira ou as duas primeiras etapas de uma sequência longa, enquanto a rota REST retorna o corpo de todos os e-mails.
Use a API quando o e-mail faz parte do seu produto:
POST /v1/automations/triggers/{triggerEventId}/fire com o e-mail e os campos do usuário. A automação publicada cuida do resto.POST /v1/contacts cria ou atualiza até 1.000 contatos por requisição.GET /v1/sends/{sendId} retorna o status e as estatísticas para um painel ou um alerta.Nos endpoints que aceitam, reutilize o mesmo Idempotency-Key e o mesmo corpo da requisição nas novas tentativas dentro da janela documentada de 24 horas (nos disparos de gatilho, a deduplicação pela chave vale por 90 dias). Use uma chave diferente para uma operação lógica diferente; leia o contrato do endpoint antes de supor que uma escrita está coberta. Os cabeçalhos de limite de requisição dizem quando esperar antes de tentar de novo. As respostas de erro da API incluem um code, como CONSENT_REQUIRED, que você pode usar para decidir o que fazer. Trate as falhas de rede separadamente. O guia da API do Brew descreve tudo isso.
Agentes de programação no terminal muitas vezes se saem melhor com uma CLI do que com qualquer uma das duas opções. A CLI do Brew retorna a resposta da API como uma única linha de JSON quando não está conectada a um terminal e usa códigos de saída que um agente consegue interpretar. O código 4 significa que é preciso confirmação, e a CLI mostra o comando exato para executar de novo com --yes depois da aprovação. Ela também gera contratos de payload tipados com brew-cli types, o que mantém as chamadas de gatilho do seu back-end alinhadas com o esquema do gatilho.
Veja uma forma de uma equipe de SaaS dividir o trabalho:
user_signed_up e uma automação de boas-vindas, testa com test_automation e publica.Nos passos 1 e 3, uma pessoa revisa o trabalho do assistente. Os passos 2 e 4 rodam a cada cadastro ou toda noite, sem ninguém olhando.
Ele coloca um assistente entre você e o endpoint, então uma requisição passa por mais etapas, e o assistente pode escolher a ferramenta errada. Isso não é problema no trabalho interativo, mas é a escolha errada para um evento de cadastro que precisa disparar sempre.
O Brew exige confirmação de envios reais nas conexões OAuth e de organização. Com clientes que usam chave de API de marca, configure a sua própria política de aprovação. Com a API, proteja as chaves em variáveis de ambiente, use chaves restritas à marca sempre que puder e adicione chaves de idempotência a toda escrita que puder ser repetida.
Sim. O guia de integração com agentes do Brew descreve como ligar endpoints da API como ferramentas de function calling, com o SDK cuidando da autenticação e das novas tentativas.
Para testar as duas metades, conecte o servidor MCP ao seu assistente para o trabalho com campanhas e crie uma chave de API para o gatilho que o seu back-end vai disparar.
