MCP Server ใช้ต่างจาก Webhook ตรงไหน เมื่อต้องต่อ Agent เข้าระบบที่ยิง Event เอง

ทีมที่มีระบบ Event Driven อยู่แล้ว เช่น เมื่อมี Order ใหม่เข้ามาจะยิง webhook ไปแจ้งระบบสต๊อกและระบบบัญชีทันที มักตั้งคำถามเวลาจะเริ่มใช้ MCP ว่า 'แล้วต้องเลิกใช้ webhook เดิมไหม' หรือ 'MCP มาแทน webhook ได้เลยหรือเปล่า' คำถามนี้มาจากความเข้าใจผิดที่พบบ่อยว่าทั้งสองอย่างเป็นเครื่องมือประเภทเดียวกันที่เลือกใช้อย่างใดอย่างหนึ่ง

ความจริงแล้ว MCP กับ webhook แก้ปัญหาคนละแบบ MCP ตอบโจทย์เวลาที่ Agent ต้องการ 'ถาม' หรือ 'สั่ง' ระบบภายนอกตามจังหวะที่มันประมวลผลบทสนทนาอยู่ ส่วน webhook ตอบโจทย์เวลาที่ระบบภายนอกมีเหตุการณ์เกิดขึ้นแล้วต้อง 'บอก' ฝั่งที่รออยู่ทันทีโดยไม่ต้องรอให้ใครมาถาม ความต่างของทิศทางการสื่อสารนี้คือหัวใจที่ต้องเข้าใจก่อนจะออกแบบระบบต่อไป

บทความนี้จะอธิบายความต่างของสองกลไกนี้แบบละเอียด พร้อมสถานการณ์ที่ควรใช้แต่ละแบบ วิธีให้สองอย่างทำงานร่วมกันในระบบเดียว และข้อผิดพลาดที่ทีมส่วนใหญ่เจอตอนพยายามผสมสองกลไกนี้เข้าด้วยกัน

ความต่างพื้นฐาน MCP คือ Pull ส่วน Webhook คือ Push

MCP ทำงานแบบ pull คือ Agent เป็นฝ่ายเริ่มการสื่อสารทุกครั้ง เมื่อผู้ใช้ถามคำถามหรือสั่งงานในบทสนทนา Agent จะตัดสินใจว่าต้องเรียก tool ตัวไหนเพื่อได้ข้อมูลหรือทำงานที่ต้องการ แล้วเรียกไปยัง MCP server ที่เปิดไว้ กระบวนการทั้งหมดเริ่มต้นจากฝั่ง Agent เสมอ ไม่มีระบบภายนอกไหนยิงอะไรเข้ามาหา Agent เองโดยที่ Agent ไม่ได้ร้องขอ

Webhook ทำงานแบบ push คือระบบต้นทางเป็นฝ่ายเริ่มการสื่อสารเมื่อมีเหตุการณ์เกิดขึ้นจริง เช่น มี Order ใหม่ มีการชำระเงินสำเร็จ หรือมีข้อความใหม่เข้ามาในระบบแชท ระบบต้นทางจะยิง HTTP request ไปยัง endpoint ที่ลงทะเบียนไว้ล่วงหน้าโดยไม่ต้องรอให้ใครมาถามก่อน ฝั่งที่รับ webhook มีหน้าที่แค่รอรับและประมวลผลเมื่อ event มาถึง

ความต่างนี้ทำให้สองกลไกเหมาะกับงานคนละแบบ MCP เหมาะกับงานที่ Agent ต้องตัดสินใจเองว่าต้องการข้อมูลอะไรตามบริบทของบทสนทนา ส่วน webhook เหมาะกับงานที่ต้องแจ้งเตือนหรือตอบสนองทันทีเมื่อมีเหตุการณ์เกิดขึ้น โดยไม่ต้องรอให้ Agent มาถามเองซึ่งอาจช้าเกินไปสำหรับบางสถานการณ์

สถานการณ์ที่ควรใช้ MCP เป็นหลัก

ใช้ MCP เมื่อ Agent ต้องการข้อมูลหรือต้องสั่งงานตามจังหวะที่ผู้ใช้ถามในบทสนทนา เช่น ผู้ใช้ถามว่า 'ยอดขายเดือนนี้เท่าไร' Agent ต้องเรียก tool ไปดึงข้อมูลตอนนั้นทันที ไม่มีทางรู้ล่วงหน้าว่าผู้ใช้จะถามคำถามนี้เมื่อไร จึงต้องเป็นกลไกที่ Agent เรียกเองตามความต้องการขณะนั้น

อีกสถานการณ์คือเมื่อ Agent ต้องสั่งให้ระบบทำอะไรบางอย่างตามคำขอของผู้ใช้ เช่น 'ช่วยอัปเดตที่อยู่จัดส่งของ Order นี้ให้หน่อย' ซึ่งเป็นการกระทำที่เกิดจากการตัดสินใจของ Agent ในบทสนทนานั้น ไม่ใช่เหตุการณ์ที่เกิดขึ้นเองจากระบบภายนอก จึงเหมาะกับการทำเป็น MCP tool มากกว่า webhook

สถานการณ์ที่ควรใช้ Webhook เป็นหลัก

ใช้ webhook เมื่อมีเหตุการณ์ที่ต้องแจ้งทันทีโดยไม่รอให้ใครมาถาม เช่น เมื่อลูกค้าชำระเงินสำเร็จ ต้องแจ้งระบบแชทให้ส่งข้อความยืนยันทันที หรือเมื่อมีสินค้าใกล้หมดสต๊อก ต้องแจ้งทีมจัดซื้อทันทีโดยไม่ต้องรอให้ Agent ถูกถามเรื่องนี้ก่อน กรณีแบบนี้ถ้าใช้ MCP อย่างเดียวจะไม่มีทางเกิดขึ้นทันเวลา เพราะ Agent ไม่มีทางรู้ว่าต้องไปเช็คเหตุการณ์นี้เมื่อไร นอกจากผู้ใช้จะถามเอง

อีกกรณีคือเมื่อต้องเชื่อมหลายระบบเข้าด้วยกันแบบ real-time เช่น ระบบ CRM ต้องอัปเดตทันทีเมื่อมีการเปลี่ยนแปลงในระบบขาย โดยไม่ต้องพึ่งพา Agent เป็นตัวกลางเลย ในกรณีนี้ webhook ที่เชื่อมตรงระหว่างสองระบบมักเร็วและเสถียรกว่าการให้ Agent คอยไปสำรวจข้อมูลเป็นระยะ

ตารางเปรียบเทียบ MCP กับ Webhook แบบเห็นภาพชัด

ตารางนี้สรุปความต่างหลักที่ใช้ตัดสินใจได้จริงเวลาต้องเลือกว่าจะใช้กลไกไหนสำหรับงานแต่ละแบบ:

ผสมสองกลไกเข้าด้วยกัน เมื่อระบบต้องการทั้งสองแบบพร้อมกัน

ระบบที่ซับซ้อนขึ้นมักต้องการทั้งสองกลไกทำงานร่วมกัน ตัวอย่างสถาปัตยกรรมที่ใช้ได้จริงคือให้ webhook เป็นตัวรับ event จากระบบภายนอกแล้วเขียนลงฐานข้อมูลกลาง จากนั้น MCP server จะมี tool สำหรับให้ Agent สืบค้นข้อมูลที่ webhook เขียนไว้ในฐานข้อมูลกลางนั้นได้ตามคำถามของผู้ใช้ วิธีนี้ทำให้ webhook รับผิดชอบแค่การ sync ข้อมูลให้ทันเวลา ส่วน MCP รับผิดชอบแค่การให้ Agent เข้าถึงข้อมูลที่ sync ไว้แล้ว ไม่ปนงานสองอย่างเข้าด้วยกัน

อีกแบบหนึ่งที่ใช้บ่อยคือให้ webhook เป็นตัวกระตุ้น (trigger) ให้ Agent เริ่มทำงานเอง เช่น เมื่อมี event 'Order ใหม่' เข้ามาผ่าน webhook ระบบจะเรียก Agent ให้เริ่มบทสนทนาอัตโนมัติเพื่อตรวจสอบความผิดปกติของ Order นั้น แล้ว Agent ค่อยใช้ MCP tool สืบค้นข้อมูลเพิ่มเติมตามที่ต้องการ ในสถาปัตยกรรมนี้ webhook คือจุดเริ่มต้นการทำงาน ส่วน MCP คือเครื่องมือที่ Agent ใช้ต่อหลังจากเริ่มทำงานแล้ว

ตัวอย่างสมมติ ระบบแจ้งเตือนสต๊อกใกล้หมดที่ผสมทั้งสองกลไก

สมมติทีมหนึ่งมีระบบคลังสินค้าที่ยิง webhook ทุกครั้งที่สต๊อกสินค้าตัวใดตัวหนึ่งลดต่ำกว่าเกณฑ์ที่ตั้งไว้ ระบบฝั่งรับ webhook จะบันทึกเหตุการณ์นี้ลงตาราง `low_stock_events` แล้วส่งข้อความเข้าไปในห้องแชททีมจัดซื้อทันทีว่า 'สินค้า A เหลือ 15 ชิ้น ต่ำกว่าเกณฑ์ 20 ชิ้น' ขั้นตอนนี้ทั้งหมดเป็นการทำงานแบบ push ที่เกิดขึ้นทันทีโดยไม่ต้องมีใครถาม

ต่อมาเมื่อทีมจัดซื้อพิมพ์คุยกับ Agent ในห้องแชทนั้นว่า 'สินค้าตัวนี้เคยสั่งซัพพลายเออร์เจ้าไหนล่าสุด ราคาเท่าไร' Agent จะเรียก MCP tool เพื่อสืบค้นประวัติการสั่งซื้อจากฐานข้อมูล ซึ่งเป็นการทำงานแบบ pull ที่เกิดจากคำถามของผู้ใช้ตรง ๆ จะเห็นว่าทั้งสองกลไกทำงานเสริมกันในระบบเดียว โดยไม่มีส่วนไหนซ้ำซ้อนหรือแย่งหน้าที่กัน

ข้อควรระวังด้านความปลอดภัยที่ต่างกันของสองกลไก

webhook มีความเสี่ยงเฉพาะตัวคือ endpoint ที่เปิดรับต้องตรวจสอบว่า request ที่เข้ามาจริง ๆ มาจากระบบต้นทางที่เชื่อถือได้ ไม่ใช่ใครก็ได้ที่รู้ URL แล้วยิง payload ปลอมเข้ามา วิธีป้องกันทั่วไปคือตรวจ signature ที่แนบมากับ request หรือใช้ secret token เฉพาะที่ทั้งสองฝั่งรู้ร่วมกัน ถ้าไม่มีการตรวจสอบนี้ ระบบอาจถูกป้อนข้อมูลปลอมที่ทำให้ Agent ตัดสินใจผิดพลาดตามไปด้วย

ฝั่ง MCP มีความเสี่ยงต่างออกไปคือต้องควบคุมว่า Agent มีสิทธิ์เรียก tool อะไรได้บ้างตามที่อธิบายไว้ในบทความเรื่องออกแบบ MCP tool เพราะจุดอ่อนของ MCP ไม่ใช่ว่าใครจะปลอมข้อมูลเข้ามา แต่เป็นเรื่องที่ Agent เองอาจตัดสินใจเรียก tool ผิดหรือส่งพารามิเตอร์ผิดพลาด ซึ่งต้องแก้ด้วยการออกแบบ tool ที่รัดกุมมากกว่าการตรวจสอบ signature แบบ webhook

ออกแบบให้รับ Event ซ้ำได้โดยไม่พังซ้ำ ก่อนที่จะสายเกินแก้

ระบบ webhook แทบทุกเจ้าไม่รับประกันว่าจะยิง event มาแค่ครั้งเดียวเสมอ เพราะกลไก retry ที่มีไว้กันข้อมูลหายอาจทำให้ event เดียวกันถูกส่งซ้ำมาสองสามครั้งในบางสถานการณ์ เช่น เครือข่ายสะดุดกลางทางจน endpoint ปลายทางไม่ได้ตอบกลับยืนยันทันเวลา ถ้าฝั่งรับไม่ได้ออกแบบให้รองรับกรณีนี้ไว้ อาจเกิดผลข้างเคียงที่ไม่ควรเกิด เช่น แจ้งเตือนสต๊อกใกล้หมดซ้ำสองรอบ หรือแย่กว่านั้นคือบันทึกยอดขายซ้ำเข้าไปในระบบรายงาน

วิธีป้องกันที่ใช้ได้จริงคือให้ event ทุกตัวมี id เฉพาะตัวที่ไม่ซ้ำกัน แล้วก่อนประมวลผล event ใด ให้ตรวจสอบก่อนว่า id นี้เคยถูกประมวลผลไปแล้วหรือยังในตาราง log ที่เก็บไว้ ถ้าเคยแล้วให้ตอบกลับว่าสำเร็จทันทีโดยไม่ต้องทำงานซ้ำ วิธีนี้เรียกว่าออกแบบให้เป็น idempotent ซึ่งเป็นหลักการพื้นฐานที่ระบบ Event Driven ทุกระบบควรมี ไม่ว่าจะเชื่อมกับ Agent ผ่าน MCP หรือไม่ก็ตาม

อีกจุดที่ควรทำคู่กันคือมี dead letter queue หรือกลไกเก็บ event ที่ประมวลผลไม่สำเร็จซ้ำหลายครั้งแล้วยังพังอยู่ แทนที่จะปล่อยให้ระบบ retry ไม่จบไม่สิ้นจนกินทรัพยากร การแยก event ที่มีปัญหาออกมาไว้ต่างหากให้ทีมมาตรวจสอบทีหลัง ช่วยให้ระบบหลักยังทำงานต่อได้ปกติโดยไม่สะดุดเพราะ event ตัวเดียวที่ผิดปกติ

ทำแบบนี้แล้วพัง เพราะ… ข้อผิดพลาดตอนผสม MCP กับ Webhook

• พยายามเอา MCP มาแทน webhook ทั้งหมดโดยให้ Agent คอย poll เช็คข้อมูลเป็นระยะแทนการรับ event ทันที — ทำแบบนี้แล้วพัง เพราะเสียเวลาและ resource ไปกับการเช็คซ้ำ ๆ ทั้งที่ webhook แจ้งได้ทันทีตั้งแต่ event เกิดขึ้น
• ให้ webhook เขียนตรงเข้าไปในบทสนทนาของ Agent โดยไม่ผ่านฐานข้อมูลกลาง — ทำแบบนี้แล้วพัง เพราะถ้า Agent ไม่ได้ online หรือกำลังประมวลผลบทสนทนาอื่นอยู่ event นั้นอาจหายไปโดยไม่มีที่เก็บสำรอง
• ไม่ตรวจสอบ signature ของ webhook ที่รับเข้ามา — ทำแบบนี้แล้วพัง เพราะใครก็ได้ที่รู้ URL endpoint สามารถยิง event ปลอมเข้ามาหลอกให้ระบบทำงานผิดพลาดได้
• ให้ MCP tool กับ webhook handler เขียนข้อมูลลง table เดียวกันโดยไม่มีกลไกกัน race condition — ทำแบบนี้แล้วพัง เพราะถ้าทั้งสองฝั่งเขียนพร้อมกันในจังหวะใกล้เคียงกัน ข้อมูลอาจเขียนทับกันหรือขัดแย้งกันโดยไม่มีใครรู้ตัว

สรุป

MCP กับ webhook ไม่ใช่ตัวเลือกที่ต้องเลือกอย่างใดอย่างหนึ่ง แต่เป็นกลไกที่ตอบโจทย์ทิศทางการสื่อสารคนละแบบ MCP เหมาะกับตอนที่ Agent ต้องการถามหรือสั่งงานตามจังหวะบทสนทนา ส่วน webhook เหมาะกับตอนที่ระบบต้องแจ้งเหตุการณ์ทันทีโดยไม่รอให้ใครถาม

ระบบที่ซับซ้อนขึ้นมักต้องการทั้งสองกลไกทำงานร่วมกัน โดยมีฐานข้อมูลกลางหรือกลไกกระตุ้นเป็นจุดเชื่อมระหว่างสองฝั่ง การเข้าใจบทบาทของแต่ละกลไกตั้งแต่ต้นจะช่วยให้ออกแบบสถาปัตยกรรมได้ชัดเจนกว่าการพยายามยัดทุกอย่างเข้าไปในกลไกเดียว

• MCP คือ Pull ที่ Agent เรียกเข้าหาระบบ ส่วน Webhook คือ Push ที่ระบบยิงเข้ามาเอง
• ใช้ MCP กับงานที่ต้องตอบคำถามหรือสั่งงานตามบทสนทนา ใช้ Webhook กับงานที่ต้องแจ้งทันที
• ผสมสองกลไกได้ผ่านฐานข้อมูลกลางหรือกลไกกระตุ้นให้ Agent เริ่มทำงาน
• แยกความเสี่ยงด้านความปลอดภัยของสองกลไก webhook ต้องตรวจ signature ส่วน MCP ต้องคุม permission ของ tool

คำถามที่พบบ่อย