対応するアシスタントをMCPで Brew に接続すれば、既存のブランドと権限のまま、メールの作成、キャンペーンの管理、結果の確認ができます。
メールの仕事の多くは、すでにアシスタントとのやり取りから始まっています。下書き、修正、キャンペーンについての質問などです。その会話からメールのワークスペースまで操作できるよう、Brew をMCPで使えるようにしました。
この接続では、アプリと同じブランドとデータを使います。対応するアシスタントは、手作業で繰り返すための手順を渡す代わりに、Brew のツールを直接呼び出せます。
Brew のMCPツールは、メールの作成と編集、コンタクト、キャンペーン、オートメーション、レポートを扱います。利用できる操作とその入力の詳細は、get_brew_capabilities とツールの説明で確認できます。
接続したら、まずはこのディスカバリー用の呼び出しから始めましょう。稼働中のサーバーが対応している操作を説明してくれるのですから、ブログの例からツール名を推測するのはやめてください。
アシスタントは、Brew のもうひとつのクライアントです。アプリと同じ製品データと送信ルールを使います。
リモートサーバーのURLは次のとおりです。
https://brew.new/api/mcpBrew のMCPのOAuth接続に対応したクライアントでは、ログインしてブランドを選択し、許可するアクセス権を確認します。クライアントがAPIキーによる設定を使う場合は、Brew で用途に合ったブランド単位のキーを作成し、クライアントのドキュメントに記載された設定形式に従ってください。
mcpServers のJSON設定を使うクライアントでは、接続の設定は次のようになります。
{
"mcpServers": {
"brew": {
"type": "http",
"url": "https://brew.new/api/mcp",
"headers": { "Authorization": "Bearer brew_YOUR_API_KEY" }
}
}
}これはプレースホルダーのキーで、実際の認証情報ではありません。本物のキーは、クライアントが対応しているシークレットの設定に保存してください。ウェブ版の ChatGPT ではプラグインを使い、ChatGPT のデスクトップアプリと Codex はMCPの設定を共有します。ほかのクライアントでは、Cline の streamableHttp のように、異なる設定キーやトランスポート名が必要な場合があります。クライアントのセットアップガイドの手順に従ってください。
まずは、承認済みの事実だけを使って、特定のオーディエンス向けの下書きを作るようアシスタントに頼んでみましょう。プレビューを表示し、メールのIDを報告するよう求めます。本番の送信に進む前に、結果を読んで修正してください。
予約配信では、オーディエンス、差出人、日付、時刻、タイムゾーンを指定し、できあがったキャンペーンの詳細を確認します。オートメーションでは、下書きを作ることと公開することを区別しましょう。
Brew は、OAuth接続と組織全体の接続で、本番の送信に確認を求めます。ブランド単位のAPIキーを使うクライアントには、独自の承認ポリシーが必要です。MCPは、クライアントの確認の挙動を一律には定めていないため、送信の権限を与える前に、サーバー側の要件だけでなく、クライアントの設定も確認してください。
Brew と別のCRMの両方にアクセスできるアシスタントは、両者をまたいで作業を進められます。ただし、それですべてのレコードが自動的に連携されるわけではありません。どのシステムがデータを管理するのか、更新がどう届くのか、失敗をどう処理するのかを決めておきましょう。
時間をおいて送るライフサイクルのリマインダーでは、イベントトリガー型のフローで contact.<name> を使う条件が、待機のあとに Brew のコンタクトフィールドの現在の値を読み取れます。これらのフィールドは同期しておきましょう。イベントのペイロードのフィールドは、元のイベントのままです。外部の状態に左右される対象条件は、アプリケーション側でチェックします。トライアルのシーケンスのガイドで、両方の方法を説明しています。
私なら、サーバーを接続して get_brew_capabilities を呼び出し、チームがすでに必要としているメールを1通作ってみます。そうすれば、このワークフローを具体的に評価できます。
明確なブリーフを使い、結果を確認して、受信トレイでテストしましょう。操作を始めるのが人でもアシスタントでも、送信のルールは同じです。
Thomas
