MCP Workflows

get_brew_capabilities lists the current tools and guided workflows. Filter it by topic, such as automation, for a workflow’s full steps. Clients that support MCP prompts can invoke the named workflows below. These recipes assume a brand connection. Organization connections also pass brand_id on brand-scoped tools.

​

Configure a Brand and Domain

configure_brand works on either connection scope:

1. get_brand with include: ["emailDesign", "imageStyle"] reads the current brand, its saved name and tagline included. Wait for extraction to finish before designing or sending.
2. Use update_brand for requested identity changes. emailDesign and imageStyle replace full Markdown documents, so read them first and preserve unrelated sections.
3. list_domains to reuse the intended sendable domain. Use create_domain only when the requested marketing domain is absent.
4. Publish the returned DNS records at your registrar or DNS provider. The MCP cannot change your DNS. Then call verify_domain; pending records mean you need to allow propagation or fix the records. If campaigns are held on the domain, a passing check resumes them, so on OAuth and organization connections verify_domain first returns a confirmation request.
5. update_domain sets sender defaults. Live sends require sendable: true.

For a new brand, an organization administrator can connect All brands even before the first brand exists. The organization-only onboard_brand workflow lists existing brands, calls create_brand only for a requested new brand, then polls get_brand with the returned brandId as brand_id until ready is true (and reports a failed extraction) before following configure_brand. Brand connections configure their selected brand. To extract a different brand, reconnect with organization scope. Website extraction creates a new brand; it does not re-extract an existing one. Brand logos and transactional domain setup are managed in the app. Brand Identity and Verify Your Sending Domain cover the app steps.

​

Launch a Campaign

launch_email_campaign:

1. create_email and, if needed, edit_email. Poll get_email when generation is still running.
2. send_email with the emailId, a subject, test: true and your own address as to. Omitting domainId uses Brew’s test sender. Check the received email; acceptance by the send tool does not prove inbox delivery.
3. list_domains with sendableOnly: true and sendingPurpose: "marketing"; choose the intended sender.
4. list_audiences to choose an opted-in audience. Include ["count"] with its audienceId to review membership.
5. On OAuth or an organization connection, call send_email with emailId, subject, audienceId, domainId, and an idempotency_key.
6. Show the returned confirmation preview. After approval, repeat the exact call with confirmed: true and its confirmation_id.
7. get_email_analytics with report: { kind: "sends", sendId } to follow the send.

Add scheduledAt for a future send. Keep the same retry key for the same intended action. Brand API-key connections execute directly, so review the target before the first live call. The confirmation contract owns the full behavior.

​

Build a Segment and Send

build_segment_and_send:

1. search_contacts and list_contact_fields to inspect the available fields.
2. create_audience with a name and filters: { filters: [...], logicalOperator: "and" }.
3. Review the returned member count, then follow the send workflow above.

Saved audiences infer omitted filter types from the field registry. Date ranges need type: "date". Create Audiences owns filter semantics.

​

Import or Update Contacts Before Segmenting

import_contacts (JSON rows) and import_contacts_csv (CSV text) add missing contacts and update existing ones, up to 1,000 rows per call; inspect row errors and retry only the failed rows after fixing them. Each call is one batch in Import History: pass fileName to name it, and filter on the returned importId to list its contacts (each keeps it until a later import touches that contact). update_contact changes one existing contact; a missing contact is an error there. Register missing custom fields with create_contact_field first, then use their declared types. Import only people who opted in and pass consent (usually { "source": "import" }); an update does not restore an unsubscribed contact’s consent.

​

Set Up an Automation

set_up_automation:

1. save_trigger to define the event contract; keep the triggerEventId.
2. create_email and get_email for ready designs. Pick a verified domain with list_domains. Each send node in save_automation needs emailId, emailVersionId, domainId, and subject.
3. test_automation with the automationId and a sample payload containing email and values for every required trigger and template field. Omit testRecipient to exercise the flow without sending mail. A no-delivery test still needs recipient and content values to traverse send nodes.
4. Inspect each returned run with list_automation_runs using run: { kind: "execution", automationRunId, include: ["logs"] }. Fix failures and cover branches before publishing with save_automation and published: true. Check the returned isLive and liveVersion.
5. check_trigger to verify readiness; fire_trigger_event starts live runs.
6. list_automation_runs with run: { kind: "execution", automationId } to monitor them.

Publishing and firing require the confirmation flow on OAuth and organization connections. If you set testRecipient, the test delivers email to that address. Use the tool schemas for graph inputs and test scenarios.

​

Run an Automation for an Audience

run_audience_automation guides a one-shot launch:

1. Choose a saved audience and read its current count and build readiness with list_audiences.
2. Reuse a suitable graph with get_automation, or save a draft whose trigger config has mode: "manualAudience" and audienceId. Omit the top-level triggerEventId; pin each send node’s email version and verified domain.
3. test_automation with the automationId and a sample payload containing email and values for every required template or condition field. Omit testRecipient and inspect execution logs as above. A manual-audience launch uses the saved graph and does not require event-style publishing.
4. Call run_automation with dryRun: true to review the recipient count, send-node count, and exclusion warnings.
5. After approval, launch without dryRun, using one idempotency_key and the confirmation flow when required. A retry uses the same key and unchanged arguments.
6. Follow the returned audienceRunId with list_automation_runs using run: { kind: "audience", audienceRunId }. Use pause_audience_run, resume_audience_run, or cancel_audience_run when requested. Cancelling cannot undo already-delivered email.

Build an Automation covers the corresponding app workflow.

​

Wire a Trigger from Code

wire_trigger_from_code validates a trigger’s payload and integrates the fire into your codebase. Production code fires over the REST API, not MCP. For the steps, call get_brew_capabilities with topic: "automation".

​

Analyze Performance

analyze_campaign_performance uses get_email_analytics with report.kind set to overview, sends, or events. Pass a sendId with sends for one delivery job. Use list_automations with analytics: {} for automation performance.

​

Personalize with a CRM MCP

personalize_with_crm enriches contacts who already opted in:

1. Read their context from your CRM MCP.
2. Use create_contact_field for missing attributes, then update_contact with its fields map.
3. Build an audience, create its email, and follow the send workflow.
4. Read the results and refine the segment.

Sync a CRM into Brew over MCP owns the full workflow and field mapping. What You Can Send owns the consent rules.

​

Improve Deliverability

improve_deliverability diagnoses domain and delivery problems. For the steps, call get_brew_capabilities with topic: "domains".

​

Report an MCP Issue

report_mcp_issue files one report per failed call through report_tool_issue, and returns a flareId Brew support can look up. It includes the tool that failed, its status and error code, a Brew request id if you have one, and a short summary of what went wrong. It never includes conversation text, secrets, or names, addresses, or recipient lists. Product feedback goes to submit_feedback instead.

​

Need Help?

Our team is ready to support you at every step of your journey with Brew. Choose the option that works best for you: