ใช้ MCP กับงานอีเมลที่ทำผ่านผู้ช่วย AI และใช้ REST API กับเหตุการณ์จากแอปพลิเคชัน เปรียบเทียบการยืนยันตัวตน การอนุมัติ การลองซ้ำ และเวิร์กโฟลว์ใน Brew
นักพัฒนาในทีมของคุณเชื่อมต่อแพลตฟอร์มอีเมลเข้ากับ Claude แล้วร่างแคมเปญของสัปดาห์หน้าในหน้าต่างแชท เช้าวันรุ่งขึ้นมีคนถามว่าอีเมลต้อนรับหลังสมัครใช้งานจะทำงานแบบเดียวกันผ่านผู้ช่วย AI ได้ไหม ขณะที่เอกสารของแพลตฟอร์มก็แสดงเซิร์ฟเวอร์ MCP และ REST API ไว้คู่กัน
แพลตฟอร์มอีเมลส่วนใหญ่ที่รองรับเอเจนต์มีช่องทางเข้าใช้งาน 2 แบบนี้แล้ว เซิร์ฟเวอร์ MCP ให้ผู้ช่วย AI เรียกใช้เครื่องมือของแพลตฟอร์มได้ระหว่างบทสนทนา ส่วน REST API เปิดให้ใช้การดำเนินการที่โค้ดของคุณเรียกได้โดยตรง ทั้งสองแบบมักเรียกเอนด์พอยต์เดียวกันอยู่เบื้องหลัง การเลือกจึงขึ้นอยู่กับว่าใครเป็นผู้ทำงานและทำเมื่อไร
ใช้ MCP เมื่อมีคนทำงานผ่านผู้ช่วย AI และใช้ REST API เมื่อผลิตภัณฑ์ของคุณต้องส่งอีเมลโดยไม่มีใครเฝ้าดู สุดท้ายแล้วทีมส่วนใหญ่ก็ใช้ทั้งสองแบบ
MCP หรือ Model Context Protocol คือมาตรฐานแบบเปิดที่ทำให้ไคลเอนต์ AI อย่าง Claude, ChatGPT และ Cursor เรียกใช้เครื่องมือต่าง ๆ ได้ ไคลเอนต์จะอ่านรายการเครื่องมือพร้อมคำอธิบายและสคีมา แล้วเลือกว่าจะเรียกเครื่องมือใดตามคำขอของคุณ เซิร์ฟเวอร์ของ Brew อยู่ที่ https://brew.new/api/mcp และรองรับ OAuth คุณจึงแค่เข้าสู่ระบบและเลือกแบรนด์ โดยไม่ต้องจัดการคีย์เอง
REST API คือชุดเอนด์พอยต์ HTTP ที่โค้ดของคุณเรียกใช้ ทั้งนี้ Brew เผยแพร่สเปก OpenAPI, TypeScript SDK และคู่มือสำหรับเอเจนต์แบบข้อความล้วนสำหรับ API ของตน ทุกการเรียกจะแนบคีย์ API ไปด้วย และโค้ดของคุณเป็นผู้ตัดสินว่าจะเรียกอะไรและเมื่อไร
ผู้ให้บริการรายอื่นก็ใช้รูปแบบเดียวกัน เซิร์ฟเวอร์ MCP ของ Customer.io ครอบ API ของตนไว้ในเครื่องมือแยกสำหรับการอ่าน การเขียน และการลบ ส่วน Brevo สร้างเครื่องมือ MCP จากสเปก OpenAPI ของตน
| MCP | REST API | |
|---|---|---|
| ใครเป็นผู้สั่งงาน | คน ผ่านผู้ช่วย AI | โค้ดของคุณ |
| งานที่พบบ่อย | ร่างและปรับแก้อีเมล สร้างกลุ่มเป้าหมาย ตั้งเวลาส่งแคมเปญ และอ่านข้อมูลการวิเคราะห์ | เรียกทริกเกอร์จากเหตุการณ์, upsert ผู้ติดต่อ, ส่งอีเมลธุรกรรม และตรวจสถานะการส่งเป็นระยะ |
| การยืนยันตัวตน | เข้าสู่ระบบด้วย OAuth หรือใช้คีย์ API สำหรับไคลเอนต์ที่ไม่รองรับ OAuth | คีย์ API ที่จำกัดขอบเขตไว้ที่แบรนด์หรือองค์กร |
| ความปลอดภัย | Brew หยุดการส่งจริงไว้รอการยืนยันบนการเชื่อมต่อผ่าน OAuth และการเชื่อมต่อระดับองค์กร | โค้ดของคุณเป็นผู้ตัดสิน ให้ใช้คีย์ idempotency และขั้นตอนตรวจทานของคุณเอง |
| การจัดการเมื่อเกิดข้อผิดพลาด | ผู้ช่วย AI อ่านข้อผิดพลาด แล้วลองใหม่หรือถามคุณ | คุณแยกเส้นทางการทำงานตามรหัสข้อผิดพลาดที่คงที่ และลองใหม่โดยเว้นระยะห่างที่เพิ่มขึ้น (backoff) |
| ขนาดของการตอบกลับ | จำกัดด้วยหน้าต่างบริบท (context window) ของผู้ช่วย AI | จำกัดด้วยการแบ่งหน้าเท่านั้น |
| เหมาะที่สุดเมื่อ | งานต้องใช้วิจารณญาณหรือต้องปรับแก้หลายรอบ | งานต้องทำงานแบบเดิมทุกครั้ง |
ใช้ MCP เมื่องานนั้นเป็นบทสนทนา:
create_email, edit_email, send_email พร้อม test: true จากนั้นเรียก send_email พร้อม scheduledAt แล้วหยุดรอการอนุมัติจากคุณsearch_contacts, การค้นหาฟิลด์ และ create_audience ร่วมกันget_email_analytics และประสิทธิภาพของระบบอัตโนมัติใน Brew อีเมลที่สร้างผ่าน MCP ใช้เอกสารแบรนด์ชุดเดียวกับอีเมลที่สร้างในแอป ส่วนบทความเรื่อง MCP ของ Brew อธิบายการตั้งค่าไคลเอนต์ไว้
การตอบกลับผ่าน MCP ต้องพอดีกับบริบทของผู้ช่วย AI บทความเรื่องโฟลว์ของ Brew ระบุว่า การขอ HTML ฉบับเต็มผ่าน MCP จะได้มาแค่หนึ่งหรือสองขั้นตอนแรกของลำดับอีเมลที่ยาว ขณะที่ช่องทาง REST จะส่งเนื้อหาของอีเมลมาครบทุกฉบับ
ใช้ API เมื่ออีเมลเป็นส่วนหนึ่งของผลิตภัณฑ์คุณ:
POST /v1/automations/triggers/{triggerEventId}/fire พร้อมอีเมลและฟิลด์ของผู้ใช้ แล้วระบบอัตโนมัติที่เผยแพร่ไว้จะจัดการส่วนที่เหลือPOST /v1/contacts upsert ผู้ติดต่อได้สูงสุด 1,000 รายต่อคำขอGET /v1/sends/{sendId} ส่งคืนสถานะและสถิติสำหรับแดชบอร์ดหรือการแจ้งเตือนบนเอนด์พอยต์ที่รองรับ ให้ใช้ Idempotency-Key และเนื้อหาคำขอชุดเดิมซ้ำเมื่อลองใหม่ภายในช่วงเวลา 24 ชั่วโมงที่ระบุไว้ในเอกสาร (ส่วนการเรียกทริกเกอร์จะกันการเรียกซ้ำที่ใช้คีย์เดียวกันได้นาน 90 วัน) และใช้คีย์ใหม่สำหรับการดำเนินการเชิงตรรกะที่ต่างกัน อ่านข้อกำหนดของเอนด์พอยต์ก่อนจะถือว่าการเขียนนั้นได้รับการป้องกันแล้ว เฮดเดอร์ขีดจำกัดอัตราจะบอกว่าเมื่อไรควรชะลอ การตอบกลับข้อผิดพลาดของ API มี code เช่น CONSENT_REQUIRED ที่คุณใช้แยกเส้นทางการทำงานได้ ส่วนความล้มเหลวของเครือข่ายให้จัดการแยกต่างหาก คู่มือ API ของ Brew อธิบายเรื่องเหล่านี้ไว้ทั้งหมด
เอเจนต์เขียนโค้ดที่ทำงานในเทอร์มินัลมักทำงานได้ดีกับ CLI มากกว่าทั้งสองตัวเลือก CLI ของ Brew จะส่งการตอบกลับจาก API ออกมาเป็น JSON บรรทัดเดียวเมื่อไม่ได้ต่อกับเทอร์มินัล และใช้รหัสออก (exit code) ที่เอเจนต์นำไปตัดสินใจต่อได้ รหัส 4 หมายความว่าต้องได้รับการยืนยัน และ CLI จะพิมพ์คำสั่งแบบตรงตัวที่ต้องเรียกใช้ซ้ำพร้อม --yes หลังได้รับการอนุมัติ นอกจากนี้ยังสร้างสคีมาเพย์โหลดแบบมีไทป์ด้วย brew-cli types ซึ่งช่วยให้การเรียกทริกเกอร์จากแบ็กเอนด์ของคุณตรงกับสคีมาของทริกเกอร์อยู่เสมอ
นี่คือวิธีหนึ่งที่ทีม SaaS อาจใช้แบ่งงาน:
user_signed_up และระบบอัตโนมัติสำหรับอีเมลต้อนรับ ทดสอบด้วย test_automation แล้วเผยแพร่ในขั้นตอนที่ 1 และ 3 มีคนตรวจทานงานของผู้ช่วย AI ส่วนขั้นตอนที่ 2 และ 4 ทำงานทุกครั้งที่มีผู้สมัครหรือทุกคืนโดยไม่มีใครเฝ้าดู
MCP เพิ่มผู้ช่วย AI เข้ามาคั่นระหว่างคุณกับเอนด์พอยต์ คำขอจึงต้องผ่านหลายขั้นตอนกว่า และผู้ช่วย AI ก็อาจเลือกเครื่องมือผิดได้ ซึ่งรับได้สำหรับงานที่ทำแบบโต้ตอบ แต่ไม่เหมาะกับเหตุการณ์สมัครใช้งานที่ต้องทำงานทุกครั้ง
Brew กำหนดให้ยืนยันก่อนการส่งจริงบนการเชื่อมต่อผ่าน OAuth และการเชื่อมต่อระดับองค์กร สำหรับไคลเอนต์ที่ใช้คีย์ API ระดับแบรนด์ ให้กำหนดนโยบายการอนุมัติของคุณเอง ส่วนเมื่อใช้ API ให้เก็บคีย์ไว้ในตัวแปรสภาพแวดล้อม ใช้คีย์ระดับแบรนด์เมื่อทำได้ และเพิ่มคีย์ idempotency ให้กับการเขียนทุกครั้งที่มีการลองซ้ำ
ได้ โดยคู่มือการใช้ Brew กับเอเจนต์ AI อธิบายวิธีต่อเอนด์พอยต์ของ API ให้เป็นเครื่องมือแบบ function calling โดยมี SDK ดูแลการยืนยันตัวตนและการลองซ้ำให้
หากต้องการลองทั้งสองแบบ ให้เชื่อมต่อเซิร์ฟเวอร์ MCP ในผู้ช่วย AI ของคุณสำหรับงานแคมเปญ และสร้างคีย์ API 1 คีย์สำหรับทริกเกอร์ที่แบ็กเอนด์ของคุณจะเรียก
