Trasforma le email in fatturato con Brew.
Collega a Brew un assistente compatibile tramite MCP per creare email, gestire campagne e controllare i risultati con il brand e i permessi che hai già.
Molto lavoro sulle email parte già da un assistente: una bozza, una revisione o una domanda su una campagna. Abbiamo reso Brew disponibile tramite MCP perché quella conversazione possa agire anche sul workspace delle email.
Il collegamento usa lo stesso brand e gli stessi dati dell’app. Un assistente compatibile può richiamare gli strumenti di Brew invece di darti istruzioni da ripetere a mano.
Gli strumenti MCP di Brew coprono creazione e modifica delle email, contatti, campagne, automazioni e report. Le operazioni disponibili e i relativi input si possono scoprire con get_brew_capabilities e con le descrizioni degli strumenti.
Dopo il collegamento, inizia da quella chiamata di scoperta. Non dedurre il nome di uno strumento da un esempio letto su un blog, quando può essere il server stesso a descrivere l’operazione supportata.
L’assistente è un altro client di Brew. Usa gli stessi dati di prodotto e le stesse regole di invio.
L’URL del server remoto è:
https://brew.new/api/mcpCon un client che supporta il collegamento MCP di Brew tramite OAuth, accedi, seleziona il brand e controlla l’accesso che stai concedendo. Se il tuo client si configura con una chiave API, crea in Brew una chiave adatta, limitata al brand, e segui il formato di configurazione indicato nella documentazione del client.
Per i client che usano una configurazione JSON mcpServers, il collegamento può avere questo aspetto:
{
"mcpServers": {
"brew": {
"type": "http",
"url": "https://brew.new/api/mcp",
"headers": { "Authorization": "Bearer brew_YOUR_API_KEY" }
}
}
}Quella è una chiave segnaposto, non una credenziale. Conserva le chiavi reali nella configurazione dei secret supportata dal client. La versione web di ChatGPT usa i plugin; l’app desktop di ChatGPT e Codex condividono la configurazione MCP. Altri client possono richiedere nomi di campo o di trasporto diversi, come streamableHttp in Cline. Segui la guida alla configurazione dei client.
Prova a chiedere all’assistente di creare una bozza per un pubblico specifico, usando informazioni approvate. Chiedigli di mostrarti l’anteprima e di indicarti l’identificativo dell’email. Leggi e rivedi il risultato prima di passare a un invio reale.
Per programmare un invio, specifica pubblico, mittente, data, ora e fuso orario. Conferma i dettagli della campagna che ne risulta. Per le automazioni, distingui tra creare una bozza e pubblicarla.
Sui collegamenti OAuth e a livello di organizzazione, Brew richiede una conferma per gli invii reali. Un client con una chiave API di brand ha bisogno di una propria procedura di approvazione. MCP non impone ai client un comportamento di conferma universale, quindi, prima di concedere l’accesso agli invii, controlla sia le impostazioni del client sia i requisiti del server.
Un assistente con accesso a Brew e a un CRM separato può coordinare il lavoro tra i due, ma questo non crea un’integrazione automatica tra tutti i record. Stabilisci quale sistema è la fonte di riferimento per i dati, come arrivano gli aggiornamenti e come si gestiscono gli errori.
Per i promemoria differiti del ciclo di vita, le condizioni su contact.<name> possono leggere, dopo un’attesa, i valori attuali dei campi del contatto di Brew. Mantieni sincronizzati quei campi: i campi del payload dell’evento riflettono ancora l’evento originale. Per l’idoneità che dipende da uno stato esterno, usa verifiche lato applicazione. La guida alla sequenza per il periodo di prova spiega entrambi gli approcci.
Io collegherei il server, richiamerei get_brew_capabilities e creerei un’email di cui il tuo team ha già bisogno. Così hai un modo concreto per giudicare il flusso di lavoro.
Usa un brief chiaro, esamina il risultato e testalo in una casella di posta. Le regole di invio sono le stesse, che a iniziare l’operazione sia una persona o un assistente.
Thomas
