เมื่อไรควร (และไม่ควร) ทำ MCP server

เจ็ดบทที่ผ่านมาคอร์สนี้ขาย MCP ให้คุณ — วิธีออกแบบ primitive, tool เป็น ACL, server surface เป็นภาษาที่เผยแพร่, ความปลอดภัยเป็นสถาปัตยกรรม บทสุดท้ายนี้ทำสิ่งที่คอร์สซื่อสัตย์ต้องทำ: บอกว่าเมื่อไรอย่าเพิ่งทำ เพราะ MCP เป็นมาตรฐานที่ทรงพลังก็จริง แต่มันเป็นเครื่องมือเฉพาะทาง ไม่ใช่ค้อนที่ตอกได้ทุกตะปู (การหยิบ MCP มาตอกทุกโจทย์คือ antipattern แบบ golden hammer ชัดๆ) การรู้ว่าเมื่อไร ไม่ ควรใช้มันสำคัญพอๆ กับการรู้ว่าจะออกแบบมันยังไง

📦 code ตัวอย่าง (กำลังจัดทำ)

บทนี้ต่อยอดจาก domain เดิมที่ repo kaen-food-ordering (กำลังจัดทำ) — code ในบทเป็น ภาพร่าง ของโทโพโลยีและ decision rubric ไม่ใช่ server ที่รันได้จริง เราจะเทียบสองทางเลือกบนโจทย์เดิม: ops-copilot ที่เรียกไม่กี่ endpoint ภายในแบบตายตัว จะคุ้มกับการยก MCP stack ทั้งชุดมาไหม หรือ function-calling agent ตรงๆ ชนะ

MCP เป็นเครื่องมือผิดเมื่อไร

MCP ออกแบบมาสำหรับสถานการณ์ที่ agent ต้อง ค้นหา (discover) และเลือกเครื่องมือเองแบบ runtime ข้าม host และ server หลายตัวที่พูดมาตรฐานเดียวกัน จุดแข็งทั้งหมดของมัน — capability negotiation, tools/list, การสลับ server ได้โดยไม่แก้ host — จะกลายเป็นน้ำหนักส่วนเกินทันทีเมื่อโจทย์ไม่ต้องการความยืดหยุ่นนั้น สี่กรณีที่วงการภาคปฏิบัติเห็นตรงกันว่า MCP มัก เป็นเครื่องมือผิด:

Integration ตายตัวจุดเดียว — ถ้าคุณต่อกับปลายทางที่รู้จักไม่กี่จุดและจะไม่เปลี่ยน การเรียก REST ตรงๆ ชัดกว่า ไม่ต้องมี discovery layer ให้เปลือง
Pipeline A→B→C ที่ deterministic — ถ้าลำดับขั้นตายตัว รู้ล่วงหน้าครบ ไม่มีการตัดสินใจตอน runtime ว่าจะเรียกอะไรต่อ นั่นคือ orchestration ธรรมดา ไม่ใช่งานที่ต้องให้ model เลือก tool เอง
Batch throughput สูง — งานอย่าง sync 50,000 records ต้องการ throughput และความ deterministic ไม่ใช่การค้นหา tool แบบ runtime การยัดมันผ่านชั้น JSON-RPC + session ของ MCP มีแต่เพิ่ม overhead กับ latency
Deploy ที่ไม่มี MCP-aware client — ถ้าไม่มี host ที่พูด MCP มาเรียกใช้ (เช่นเป็น service ให้ระบบ backend อื่นเรียก) การเปิดเป็น MCP server ก็เปิดไปให้ไม่มีใครใช้ — REST endpoint หรือ library function ตรงประเด็นกว่า

ในทั้งสี่กรณี REST/function-call ตรงๆ ง่ายกว่า เร็วกว่า และรักษาความปลอดภัยกับ debug ได้ง่ายกว่า เพราะมันไม่มีชิ้นส่วนเคลื่อนไหวที่ MCP บังคับให้มี

flowchart TD
  START["จะตั้ง MCP server ไหม?"]
  Q1{"มี MCP-aware client<br/>มาเรียกใช้จริงไหม?"}
  Q2{"งานเป็น pipeline A→B→C<br/>ที่ลำดับตายตัวไหม?"}
  Q3{"เป็น integration จุดเดียว<br/>ปลายทางตายตัวไม่กี่จุดไหม?"}
  Q4{"เป็น batch throughput สูง<br/>เช่น sync 50k records ไหม?"}
  YES["ควรทำ MCP server<br/>agent ต้อง discover + เลือก tool เอง<br/>ข้าม host หลายตัวแบบ runtime"]
  NO["อย่าเพิ่งทำ MCP server<br/>REST/function-call ตรง ๆ<br/>ง่าย เร็ว และปลอดภัยกว่า"]
  START --> Q1
  Q1 -->|"ไม่มี"| NO
  Q1 -->|"มี"| Q2
  Q2 -->|"ใช่ ตายตัว"| NO
  Q2 -->|"ไม่ ต้องตัดสินใจตอน runtime"| Q3
  Q3 -->|"ใช่ จุดเดียว"| NO
  Q3 -->|"ไม่ หลากหลาย"| Q4
  Q4 -->|"ใช่ batch"| NO
  Q4 -->|"ไม่"| YES
  classDef no fill:#fecaca,stroke:#991b1b,color:#1a1a1f;
  classDef yes fill:#bbf7d0,stroke:#065f46,color:#1a1a1f;
  classDef q fill:#e0e7ff,stroke:#3730a3,color:#1a1a1f;
  class NO no;
  class YES yes;
  class Q1,Q2,Q3,Q4 q;

คำบรรยายภาพ: ต้นไม้ตัดสินใจ “ควรตั้ง MCP server ไหม” — ทุกทางที่นำไปสู่ ตายตัว / batch / ไม่มี client วิ่งเข้าช่อง “อย่าเพิ่งทำ” (แดง) มีเพียงทางเดียวที่ไปถึง “ควรทำ” (เขียว) คือเมื่อ agent ต้องค้นหาและเลือก tool เองแบบ runtime โดยมี MCP-aware client มาเรียกใช้จริง — สังเกตว่าเงื่อนไข “ควรทำ” แคบกว่าที่คอนเทนต์ขาย MCP ส่วนใหญ่ทำให้เข้าใจ

MCP เพิ่มต้นทุนอะไร

การตั้ง MCP server ในโปรดักชันไม่ได้ฟรี มันเพิ่ม พื้นผิว distributed-systems ที่ REST/function-call ในกระบวนการเดียวไม่มี: ตัว server เองที่ต้อง deploy/monitor, ชั้น registry/discovery (tools/list) ที่ต้องดูแล, และชั้น auth ที่ต้องจัดการ token กับ scope ทุกชิ้นเป็นของที่ต้อง deploy ให้ทำงาน ต้องเฝ้าดูเมื่อพัง และต้องรักษาความปลอดภัยเพิ่ม — ต้นทุนที่คุ้มก็ต่อเมื่อคุณได้ความยืดหยุ่นของ runtime discovery กลับมาแลกจริง

แต่ต้นทุนที่ลึกกว่าคือ ต้นทุนด้านความปลอดภัย และนี่คือเหตุผลที่ควรยับยั้งเป็นพิเศษ ในบทที่ 6 เราพูดถึง Lethal Trifecta — เงื่อนไขสามอย่างที่พออยู่พร้อมกันแล้ว agent ถูกหลอกให้ขโมยข้อมูลออกไปเองได้: (1) เข้าถึงข้อมูลลับ (2) รับเนื้อหาที่ควบคุมไม่ได้ และ (3) มีช่องส่งข้อมูลออกภายนอก การประกอบ (composition) ทวีคูณพื้นผิวการโจมตีนี้โดยตรง ยิ่งคุณเสียบ MCP server เข้ากับ agent ตัวเดียวมากเท่าไร โอกาสที่ครบสามขาพร้อมกันโดยไม่ตั้งใจก็ยิ่งสูง — server ตัวหนึ่งเปิดข้อมูลลับ อีกตัวรับ input จากภายนอก อีกตัวมีช่องส่งออก การรวมทั้งหมดเข้าด้วยกันจึงเป็นการประกอบ trifecta ให้ครบโดยที่ไม่มี server ตัวไหนตั้งใจ Simon Willison สรุปทางแก้ไว้ตรงว่า “ทางเดียวที่จะปลอดภัยคือเลี่ยงการรวม lethal trifecta นี้ให้ครบไปเลย” (Willison, “The lethal trifecta”, มิ.ย. 2025) กรณี GitHub MCP server ที่ถูกยึดผ่าน issue สาธารณะที่เป็นอันตรายเป็นตัวอย่างจริงว่าการต่อ server เพิ่มโดยไม่จำกัดสิทธิ์เปิดช่องโจมตีเชิงสถาปัตยกรรมได้อย่างไร (Invariant Labs, “MCP GitHub vulnerability”) — “ไม่ต่อ server ที่ไม่จำเป็น” จึงเป็นมาตรการความปลอดภัย ไม่ใช่แค่การประหยัด overhead

ตัวอย่างฟู้ดเดลิเวอรี: 3 endpoint ตายตัว

กลับมาที่ ops-copilot สมมติมันทำงานเดียว: รับหมายเลขออเดอร์ แล้ว เรียก3 endpoint ภายในตามลำดับตายตัวเสมอ — ดึงออเดอร์ → เช็กสถานะครัว → แจ้งลูกค้า ไม่มีการตัดสินใจตอน runtime ว่าจะเรียกอะไรต่อ ไม่มี tool ให้เลือก ไม่มีอะไรให้ discover นี่คือ pipeline ตายตัวชัดๆ

ถ้ายก MCP stack ทั้งชุดมาห่อโจทย์นี้ คุณจ่ายค่า server + registry + auth เต็มราคาเพื่อความสามารถ (runtime discovery) ที่ไม่ได้ใช้เลย:

ops-copilot
  └─ MCP client ── JSON-RPC ── MCP server        (ต้อง deploy + monitor)
                                ├─ auth layer      (ต้องดูแล token/scope)
                                ├─ registry/discovery (tools/list)
                                └─ ห่อ endpoint: get_order → check_kitchen → notify
# ปลายทางตายตัว 3 จุด เรียงตายตัว → discovery ไม่ถูกใช้เลย
# แต่ต้องดูแล server + auth + registry เพิ่มมาเปล่า ๆ พร้อมพื้นผิวโจมตีที่โตขึ้น

เทียบกับ agent function-calling ธรรมดาที่เรียก3 function ตรงจากกระบวนการเดียว — ไม่มี server, registry หรือ auth layer แยกให้ดูแลหรือให้ใครโจมตี:

ops-copilot (function-calling loop ในกระบวนการเดียว)
  ├─ get_order(orderId)        → REST ภายใน
  ├─ check_kitchen(orderId)    → REST ภายใน
  └─ notify_customer(orderId)  → REST ภายใน
# 3 function ตายตัว เรียกตรง ๆ
# ไม่มีชั้น distributed-systems เพิ่ม ไม่มี trifecta ให้ประกอบโดยไม่ตั้งใจ

หลักคิดง่ายๆ: ถ้า agent ไม่ได้ตัดสินใจเองว่าจะเรียกอะไรตอน runtime และไม่มี MCP-aware client มาใช้ประโยชน์จาก discovery การตั้ง MCP server ก็เพิ่มชิ้นส่วนที่ต้องดูแลและพื้นผิวโจมตี โดยไม่ได้อะไรกลับมาแลก — function-calling agent ตรงๆ อาจเป็นคำตอบที่ดีกว่า แต่ถ้าถ้าวัน1 copilot ต้องเลือกจากเครื่องมือหลายสิบตัวแบบ dynamic หรือถูกเรียกจากหลาย host ที่พูด MCP สมการก็พลิกกลับไปฝั่ง MCP ทันที

นี่คือความเห็นภาคปฏิบัติ ไม่ใช่ spec doctrine

ต้องพูดให้ชัด: ไม่มีเอกสาร spec หรือประกาศทางการของ MCP ที่ระบุ “เมื่อไรไม่ควรใช้ MCP” คำแนะนำทั้งบทนี้เป็น ความเห็นภาคปฏิบัติ (practitioner consensus) ที่สังเคราะห์จากการเปรียบเทียบ MCP-vs-API หลายแหล่งของทั้งผู้ให้บริการและนักพัฒนาอิสระในช่วงปี 2025–2026 ประกอบกับหลักความปลอดภัยเรื่อง lethal trifecta ไม่ใช่ถ้อยคำ normative จาก spec ฉบับ 2025-11-25 และไม่ใช่คำสั่งระดับ MUST จากใคร

การระบุขอบเขตของตัวเองแบบนี้ไม่ได้ทำให้คอร์สอ่อนลง — มันทำให้ น่าเชื่อถือขึ้น คอร์สที่กล้าบอกว่า “ตรงนี้เป็นวิจารณญาณเชิงวิศวกรรม ไม่ใช่กฎที่เขียนไว้ใน spec” คือคอร์สที่คุณเชื่อได้ว่าจะไม่พองข้ออ้างส่วนอื่นเกินจริง เอาความเห็นนี้ไปชั่งกับบริบทของคุณเอง อย่ารับมาเป็นกฎตายตัว — ซึ่งย้อนแย้งกันเองพอดีถ้าเราจะให้คุณท่อง “ห้ามใช้ MCP กับ pipeline ตายตัว” แบบ doctrine

ปิดคอร์ส

แปดบทนี้ไม่ใช่ทัวร์ SDK แต่เป็นคอร์สเรื่อง วิจารณญาณ: ใครควบคุม primitive ไหน (model/app/ผู้ใช้), tool ในฐานะ ACL และภาษาที่เผยแพร่ของ bounded context, ความปลอดภัยในฐานะสมบัติเชิงสถาปัตยกรรม (lethal trifecta, คำอธิบายที่ไม่ควรเชื่อโดยปริยาย, sandbox ที่จำกัดความเสียหายไม่ใช่ป้องกัน) และบทสุดท้ายนี้ — วินัยที่จะ ไม่ หยิบ MCP มาใช้เมื่อไม่จำเป็น ทั้งสามความคิดนี้อยู่ยงข้ามทุกการเปลี่ยน version ของ spec ต่างจากรายละเอียดสายส่ง/session ที่กำลังขยับ ถ้าคุณจำได้อย่างเดียวจากคอร์สนี้ ขอให้เป็นข้อนี้: server surface ที่ดีคือภาษาที่เผยแพร่ของ bounded context, tool ทุกตัวคือ ACL และความปลอดภัยที่ดีที่สุดคือการไม่ประกอบ lethal trifecta ให้ครบตั้งแต่แรก — และบางครั้งวิธีที่ดีที่สุดในการรักษาสิ่งเหล่านั้นคือไม่ตั้ง MCP server เลย

🔗 แหล่งอ้างอิงหลักของบทนี้

บทนี้พึ่งแหล่ง ทุติยภูมิ/สังเคราะห์ เป็นหลัก และระบุไว้ตรงๆ ว่าเป็นความเห็นภาคปฏิบัติ ไม่ใช่ spec doctrine (ยังไม่มีการ์ด DevIQ สำหรับหัวข้อ MCP โดยเฉพาะ):

Willison, “The lethal trifecta” (มิ.ย. 2025) — เหตุผลด้านความปลอดภัยที่ให้ยับยั้งการประกอบ server หลายตัว
Invariant Labs, “MCP GitHub vulnerability” — กรณีจริงที่การต่อ server โดยไม่จำกัดสิทธิ์เปิดช่องโจมตีเชิงสถาปัตยกรรม
การเปรียบเทียบ MCP-vs-API ของผู้ปฏิบัติหลายแหล่ง (2025–2026) — ที่มาของ “สี่กรณีที่ MCP เป็นเครื่องมือผิด” ในฐานะ practitioner consensus ไม่ใช่ถ้อยคำจาก spec

เช็กความเข้าใจ — บทที่ 8

ข้อ 1 / 3

กรณีใดต่อไปนี้ที่ MCP มักเป็นเครื่องมือผิด และควรใช้ REST/function-call ตรงๆ แทน?

เมื่อไร​ควร (และ​ไม่​ควร) ทำ MCP server

MCP เป็น​เครื่องมือ​ผิด​เมื่อไร

MCP เพิ่ม​ต้นทุน​อะไร

ตัว​อย่างฟู้ด​เดลิ​เวอรี: 3 endpoint ตายตัว

นี่​คือ​ความเห็น​ภาค​ปฏิบัติ ไม่ใช่ spec doctrine