Your AI assistant can now work in Brew

A lot of email work already starts in an assistant: a draft, a revision, or a question about a campaign. We made Brew available over MCP so that conversation can act on the email workspace too.

The connection uses the same brand and records as the app. A compatible assistant can call Brew's tools instead of handing you instructions to repeat manually.

What the connection provides

Brew's MCP tools cover email creation and editing, contacts, campaigns, automations, and reporting. The exact available operations and their inputs are discoverable through get_brew_capabilities and the tool descriptions.

Start with that discovery call after connecting. Do not guess a tool name from a blog example when the live server can describe the supported operation.

The assistant is another client of Brew. It uses the same product data and sending rules.

Connect with OAuth or an API key

The remote server URL is:

https://brew.new/api/mcp

For a client that supports Brew's MCP OAuth connection, sign in, select the brand, and review the access being granted. If your client uses an API-key configuration, create a suitable brand-scoped key in Brew and follow the client's documented configuration format.

For clients using an mcpServers JSON configuration, the connection can look like this:

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

That is a placeholder key, not a credential. Keep real keys in the client's supported secret configuration. ChatGPT web uses plugins; ChatGPT desktop and Codex share MCP configuration. Other clients can require different keys or transport names, such as Cline’s streamableHttp. Follow the client setup guide.

Give it a bounded first task

Try asking the assistant to create a draft for a specific audience using approved facts. Ask it to show the preview and report the email identifier. Read and revise the result before moving to a live send.

For scheduling, specify the audience, sender, date, time, and timezone. Confirm the resulting campaign details. For automations, distinguish creating a draft from publishing it.

Brew requires live-send confirmation on OAuth and organization connections. A brand API-key client needs its own approval policy. MCP does not impose one universal client confirmation behavior, so check the client settings as well as the server requirements before granting send access.

Connected tools still need a plan

An assistant with access to Brew and a separate CRM can coordinate work across them, but that does not create an automatic integration between every record. Define which system owns the data, how updates arrive, and how failures are handled.

For delayed lifecycle reminders, event conditions on contact.<name> can read current Brew contact fields after a wait. Keep those fields synced; event payload fields still reflect the original event. Use application-side checks for eligibility that depends on external state. The trial sequence guide explains both approaches.

Start with a draft you can review

I would connect the server, call get_brew_capabilities, and make one email your team already needs. That gives you a concrete way to judge the workflow.

Use a clear brief, inspect the result, and test it in an inbox. The sending rules are the same whether a person or an assistant starts the operation.

Thomas