Conecte um assistente compatível ao Brew via MCP para criar e-mails, gerenciar campanhas e analisar resultados com a marca e as permissões que você já tem.
Muito do trabalho com e-mail já começa em um assistente: um rascunho, uma revisão ou uma pergunta sobre uma campanha. Disponibilizamos o Brew via MCP para que essa conversa também possa agir no seu espaço de trabalho de e-mail.
A conexão usa a mesma marca e os mesmos registros do app. Um assistente compatível pode chamar as ferramentas do Brew em vez de passar instruções para você repetir à mão.
As ferramentas MCP do Brew cobrem criação e edição de e-mails, contatos, campanhas, automações e relatórios. As operações disponíveis e as entradas de cada uma podem ser descobertas com get_brew_capabilities e com as descrições das ferramentas.
Depois de conectar, comece por essa chamada de descoberta. Não adivinhe o nome de uma ferramenta a partir de um exemplo de blog quando o próprio servidor pode descrever a operação disponível agora.
O assistente é mais um cliente do Brew. Ele usa os mesmos dados do produto e as mesmas regras de envio.
A URL do servidor remoto é:
https://brew.new/api/mcpSe o seu cliente é compatível com a conexão OAuth do MCP do Brew, faça login, selecione a marca e revise o acesso que está sendo concedido. Se o seu cliente usa configuração por chave de API, crie no Brew uma chave adequada, restrita à marca, e siga o formato de configuração documentado pelo cliente.
Em clientes que usam uma configuração JSON com mcpServers, a conexão pode ficar assim:
{
"mcpServers": {
"brew": {
"type": "http",
"url": "https://brew.new/api/mcp",
"headers": { "Authorization": "Bearer brew_YOUR_API_KEY" }
}
}
}Essa é uma chave de exemplo, não uma credencial. Guarde as chaves reais no recurso de segredos que o cliente oferece. O ChatGPT na web usa plugins; o app do ChatGPT para desktop e o Codex compartilham a configuração MCP. Outros clientes MCP podem exigir nomes de campo ou de transporte diferentes, como o streamableHttp do Cline. Siga o guia de configuração de clientes.
Experimente pedir ao assistente que crie um rascunho para um público específico, usando informações aprovadas. Peça que ele mostre a prévia e informe o identificador do e-mail. Leia e revise o resultado antes de passar para um envio real.
Para agendar, especifique o público, o remetente, a data, o horário e o fuso horário. Confirme os detalhes da campanha resultante. Nas automações, diferencie criar um rascunho de publicá-lo.
O Brew exige confirmação de envios reais nas conexões OAuth e de organização. Um cliente com chave de API de marca precisa da própria política de aprovação. O MCP não impõe um comportamento universal de confirmação nos clientes, então confira as configurações do cliente, além dos requisitos do servidor, antes de conceder acesso de envio.
Um assistente com acesso ao Brew e a um CRM separado pode coordenar o trabalho entre os dois, mas isso não cria uma integração automática entre todos os registros. Defina qual sistema é dono dos dados, como as atualizações chegam e como as falhas são tratadas.
Para lembretes de ciclo de vida enviados mais tarde, uma automação disparada por evento pode usar condições em contact.<name> para ler os campos atuais do contato no Brew depois de uma espera. Mantenha esses campos sincronizados; os campos do payload do evento continuam refletindo o evento original. Use verificações do lado da aplicação quando a elegibilidade depender de um estado externo. O guia da sequência de conversão de períodos de teste explica as duas abordagens.
Eu conectaria o servidor, chamaria get_brew_capabilities e faria um e-mail de que a sua equipe já precisa. Isso dá uma forma concreta de avaliar o fluxo de trabalho.
Use um briefing claro, analise o resultado e teste em uma caixa de entrada. As regras de envio são as mesmas, seja uma pessoa ou um assistente quem inicia a operação.
Thomas
