MCP คืออะไร แก้ปัญหาอะไร

ในคอร์ส Agent as Bounded Context เราปิดท้ายด้วยความคิดสองข้อที่คอร์สนี้จะต่อยอดตรงๆ — tool ทุกตัวคือ Anti-Corruption Layer ที่กั้นความรกของ backend ไม่ให้ไหลเข้า context ของ agent และ ชุด tool ที่ agent เปิดออกมาคือภาษาที่เผยแพร่ (published language) ของ bounded context นั้น คอร์สนั้นพูดถึง “tool” แบบลอยๆ ไม่ผูกกับมาตรฐานไหน คอร์สนี้ลงมาที่มาตรฐานจริงที่วงการ agent มาบรรจบกัน: Model Context Protocol และเปลี่ยนคำถามจาก “agent ควรถืออะไร” เป็น “เราจะออกแบบฝั่ง server ที่ยื่นของพวกนั้นให้ agent อย่างไรให้ดีและปลอดภัย”

นี่คือคอร์ส AI-engineering เชิง สังเคราะห์ เหมือนคอร์สพี่ของมัน — ไม่ใช่ทัวร์ SDK แต่เป็นการเอาวินัยเชิงกลยุทธ์ของ DDD (tool เป็น ACL, server surface เป็น ubiquitous language, ความปลอดภัยเป็น trust boundary) มาเป็นเลนส์มองงานออกแบบ MCP server ทุกข้ออ้างเชิง spec ในคอร์สจะอ้างอิงแหล่งปฐมภูมิแบบระบุวันที่กำกับ เพราะชั้นสายส่งของ MCP กำลังขยับเร็ว (อ่านกล่อง version ด้านล่าง) บทแรกนี้ตอบสองคำถามพื้นฐานก่อน: MCP คืออะไร และมันเกิดมา แก้ปัญหาอะไร

📦 code ตัวอย่าง

คอร์สนี้เป็น คอร์สออกแบบ ไม่ใช่ทัวร์ SDK — code ในคอร์สคือ ภาพร่าง ของ schema, ชุด primitive และโทโพโลยี (Thai Mermaid + pseudo-config สั้นๆ) ไม่ใช่ server ที่รันได้จริง ตัวอย่างต่อยอดจาก domain เดิมที่ repo kaen-food-ordering (กำลังจัดทำ) โดยมอง platform ฟู้ดเดลิเวอรีในมุมใหม่: ระบบภายในของ platform (ออเดอร์ ครัว การเงิน) ที่ถูกห่อเป็น MCP server ให้ ops-copilot เรียกใช้

MCP คือ “USB-C สำหรับ AI”

MCP (Model Context Protocol) คือ มาตรฐานเปิดสำหรับเชื่อม app AI เข้ากับระบบภายนอก — แหล่งข้อมูล เครื่องมือ และ workflow หน้าแนะนำอย่างเป็นทางการเปรียบมันไว้ตรงที่สุดว่า “ให้คิดถึง MCP เหมือน port USB-C สำหรับ application AI… วิธีมาตรฐานเดียวในการเชื่อม app AI เข้ากับระบบภายนอก” (MCP Introduction, modelcontextprotocol.io) ก่อนมี USB-C อุปกรณ์แต่ละชิ้นมาพร้อมสายและหัวต่อของตัวเอง MCP อยากเป็นหัวต่อมาตรฐานเดียวแบบนั้นให้กับ AI

⚠️ อ้างเครดิตให้ถูก: คำเปรียบ USB-C มาจากหน้า Introduction ไม่ใช่ประกาศเปิดตัว

คำเปรียบ “USB-C สำหรับ AI” อยู่บนหน้า Introduction ของ modelcontextprotocol.io ไม่ใช่ ในประกาศเปิดตัวของ Anthropic เมื่อ พ.ย. 2024 — แหล่งอ้างอิงของคำเปรียบนี้จึงต้องชี้ไปที่หน้า Introduction เสมอ ไม่ใช่หน้าประกาศ

ปัญหาที่ MCP เกิดมาแก้: จาก M×N เป็น M+N

ประกาศเปิดตัวเดิมของ Anthropic วางปัญหาไว้ชัด: “ทุกแหล่งข้อมูลใหม่ต้องการการต่อเชื่อมเฉพาะของตัวเอง ทำให้ระบบที่เชื่อมถึงกันจริงๆ ขยายได้ยาก” และเสนอทางแก้เป็น “โพรโทคอลเดียว” แทนที่สายเชื่อมเฉพาะกิจกองโต (Introducing the Model Context Protocol, Anthropic, พ.ย. 2024) ถ้าไม่มีมาตรฐานกลาง app AI จำนวน M ตัว ที่อยากคุยกับเครื่องมือ N ชนิด ก็ต้องเขียนตัวเชื่อมเฉพาะคู่รวม M×N ชิ้น:

Claude Desktop ─┬─ ตัวเชื่อมเฉพาะ → ระบบออเดอร์
                ├─ ตัวเชื่อมเฉพาะ → ระบบครัว
                └─ ตัวเชื่อมเฉพาะ → ระบบการเงิน
IDE ────────────┬─ ตัวเชื่อมเฉพาะ → ระบบออเดอร์   (เขียนใหม่ทั้งที่งานเดิม)
                ├─ ตัวเชื่อมเฉพาะ → ระบบครัว
                └─ ตัวเชื่อมเฉพาะ → ระบบการเงิน
# app M ตัว × เครื่องมือ N ชนิด = ต้องดูแลตัวเชื่อม M×N ชิ้น

วงการมักอธิบายคุณค่าของ MCP ผ่านกรอบ “M×N → M+N”: ถ้าทั้งสองฝั่งพูดโพรโทคอลกลางเดียวกัน app M ตัวและเครื่องมือ N ชนิดก็ต่อกันด้วยงานแค่ M+N (แต่ละฝั่งลงแรงครั้งเดียว) แทน M×N กรอบนี้เป็น คำอธิบายของระบบนิเวศ ไม่ใช่ถ้อยคำจาก spec หรือจาก Anthropic — มันสะท้อนวิธีที่ Language Server Protocol (LSP) เคยถูกขายให้วงการ editor/ภาษา และเป็นการเปรียบที่ใช้สอนได้ดีจริง ตราบใดที่เราระบุว่ามันคือ มุมมองของชุมชน ไม่ใช่คำนิยามทางการ

MCP ไม่ใช่ “โพรโทคอลของ Anthropic” อีกต่อไป

จุดที่คอนเทนต์ MCP ส่วนใหญ่ล้าสมัย: Anthropic เป็นผู้ เปิดตัว MCP (พ.ย. 2024) แต่เมื่อ 9 ธ.ค. 2025 ได้บริจาคมันให้ Agentic AI Foundation (AAIF) ซึ่งเป็นกองทุนกำกับทิศทางภายใต้ Linux Foundation (ร่วมก่อตั้งโดย Anthropic, Block และ OpenAI พร้อมแรงสนับสนุนจาก Google, Microsoft, AWS, Cloudflare และ Bloomberg) (Donating MCP to the Agentic AI Foundation, Anthropic, ธ.ค. 2025) ปัจจุบัน MCP จึงเป็น มาตรฐานที่เป็นกลางทางค่าย — เรียกมันว่า “โพรโทคอลของ Anthropic” ไม่ถูกต้องอีกต่อไป และคอร์สที่ยังเรียกแบบนั้นก็อ่านแล้วรู้ทันทีว่าเขียนก่อนเดือนธันวาคม 2025

⚠️ version spec ที่คอร์สนี้ยึด: 2025-11-25 (และฉบับ 2026-07-28 ที่กำลังจะมา)

ทุกข้ออ้างเชิง spec ในคอร์สนี้ยึดกับ spec ฉบับ 2025-11-25 ซึ่งเป็นฉบับปัจจุบัน ณ ตอนเขียน — เวลาเจอประโยคแบบ “spec บอกว่า…” ให้อ่านว่า “ณ spec 2025-11-25…” เสมอ

ขณะเขียนบทนี้ ฉบับ 2026-07-28 กำลังจะประกาศใช้ (ผู้ดูแลเรียกมันว่า “การแก้ไขครั้งใหญ่ที่สุดนับตั้งแต่เปิดตัว”) และมันจะ ถอดชั้น session ระดับโพรโทคอลออก ทำให้แกนกลางของ MCP เป็น stateless บน HTTP ธรรมดา (ตัด header Mcp-Session-Id ทิ้ง) นั่นแปลว่ารายละเอียด สายส่ง/session/การยืนยันตัวตน คือส่วนที่เปลี่ยนเร็วที่สุด และเราจะไม่สอนมันเป็น “ความจริงเหนือกาลเวลา” — สิ่งที่คอร์สนี้เน้นคือ ชั้นที่ทนต่อการเปลี่ยน version: บทบาท Host/Client/Server, ใครควบคุม primitive ไหน, tool ในฐานะ ACL และแบบจำลองความปลอดภัย ซึ่งอยู่ยงข้ามทั้งสองฉบับ

สถาปัตยกรรม: Host / Client / Server บน JSON-RPC

ณ spec 2025-11-25 หน้า Architecture นิยามไว้ว่า “MCP ใช้สถาปัตยกรรม client-host-server โดยแต่ละ host รัน client ได้หลายตัว… สร้างบน JSON-RPC และเป็นโพรโทคอล session ที่มีสถานะ (stateful session protocol)” (Architecture, MCP spec 2025-11-25) สามบทบาทนี้แบ่งหน้าที่กันชัด:

Host — app ที่ผู้ใช้เห็นและคุยด้วยตรงๆ (เช่น Claude Desktop, Claude Code, IDE ที่ผูก LLM ไว้) เป็น ตัวประสานงาน ที่ผูก LLM เข้ากับทุกอย่าง หน้าที่หลักคือ รักษาความยินยอมของผู้ใช้ (consent) และการแยกส่วน (isolation) — spec วางไว้เป็นหลักการว่า host ต้อง (must) ขอความยินยอมก่อนเปิดเผยข้อมูลผู้ใช้หรือรันเครื่องมือ และกันไม่ให้ server ตัวหนึ่งมองเห็นบริบทของอีกตัว แต่พึงระวังว่านี่เป็น หลักการ ที่ spec ไม่ได้บังคับที่ระดับโพรโทคอล — ใครจะบังคับให้เกิดจริงเป็นเรื่องของ host เอง (เจาะลึกในบทที่ 6)
Client — ส่วนประกอบ ภายใน host ที่ผูกการเชื่อมต่อ หนึ่งต่อหนึ่ง กับ server หนึ่งตัว host หนึ่งจึงถือ client ได้หลายตัว (ตัวละ server) แต่ละ client เจรจาความสามารถ (capability negotiation) ตอนเปิด session แล้วส่งต่อสิ่งที่ server มีให้ host ใช้
Server — โปรแกรมที่ห่อระบบภายนอกจริง (ฐานข้อมูล, API, file) แล้วเปิดออกมาเป็น Primitive สามแบบ (Tool, Resource, Prompt — บทที่ 2) จุดสำคัญเชิงออกแบบและความปลอดภัย: server มองไม่เห็นบทสนทนาทั้งหมด และมองไม่เห็น server ตัวอื่น มันทำงานอย่างอิสระ รู้แค่สิ่งที่ client ส่งเข้ามาใน session 1:1 ของมันเท่านั้น

ทั้งสามคุยกันด้วย JSON-RPC — spec ข้อความระดับสายส่งที่นิยาม request/response/notification เป็น JSON มาตรฐานเดียว ทำให้ client กับ server เขียนด้วยภาษาอะไรก็คุยกันได้ ความสมมาตรตรงนี้เองที่ทำให้กรอบ M+N เป็นจริง: server ที่เขียนถูกมาตรฐานครั้งเดียว ใช้ได้กับทุก host ที่พูด MCP

flowchart LR
  subgraph HOST["Host — app ที่ผู้ใช้คุยด้วย (เช่น Claude Code)"]
    LLM["LLM + ตัวประสานงาน<br/>รักษา consent + แยกส่วน server"]
    C1["Client A"]
    C2["Client B"]
    C3["Client C"]
  end
  S1["Server: ออเดอร์<br/>Tool / Resource / Prompt"]
  S2["Server: ครัว<br/>Tool / Resource / Prompt"]
  S3["Server: การเงิน<br/>Tool / Resource / Prompt"]
  LLM --- C1
  LLM --- C2
  LLM --- C3
  C1 <-->|"JSON-RPC · session 1:1"| S1
  C2 <-->|"JSON-RPC · session 1:1"| S2
  C3 <-->|"JSON-RPC · session 1:1"| S3
  classDef host fill:#c7d2fe,stroke:#3730a3,color:#1a1a1f;
  classDef srv fill:#bbf7d0,stroke:#065f46,color:#1a1a1f;
  class LLM,C1,C2,C3 host;
  class S1,S2,S3 srv;

คำบรรยายภาพ: host หนึ่งตัว (น้ำเงิน) ถือ client หลายตัว โดย client แต่ละตัวผูก session 1:1 กับ server หนึ่งตัว ผ่าน JSON-RPC — host เป็นศูนย์กลางเดียวที่เห็นบทสนทนาทั้งหมดและคุมความยินยอม ส่วน server แต่ละตัว (เขียว) เห็นแค่ session ของตัวเอง มองไม่เห็นทั้งบทสนทนาและมองไม่เห็น server เพื่อนบ้าน ในตัวอย่างฟู้ดเดลิเวอรี ระบบออเดอร์ ครัว และการเงินถูกห่อเป็นคนละ server — ทำให้ ops-copilot ต่อกับทั้งสามได้โดยไม่ต้องให้ระบบใดระบบหนึ่งรู้จักอีกระบบ

platform ฟู้ดเดลิเวอรีในฐานะ MCP server

ตลอดคอร์สนี้เราจะมองระบบภายในของ platform เดิมผ่านเลนส์ MCP: ระบบ ออเดอร์, ครัว และ การเงิน แต่ละตัวถูกห่อเป็น server หนึ่งตัวที่เปิด primitive ของตัวเองออกมา ส่วน ops-copilot (host) เชื่อมกับทั้งสามผ่าน client คนละตัว งานออกแบบที่คอร์สนี้สนใจไม่ใช่ “จะเรียก API ยังไง” แต่คือ server แต่ละตัวควรเปิดอะไรออกมา ปิดอะไรไว้ และแปล model ภายในให้ปลอดภัยก่อนยื่นให้ model อย่างไร — เพราะสิ่งที่ server เปิดออกมาคือทั้ง API และพื้นผิวการโจมตีในเวลาเดียวกัน นี่คือแก่นที่จะร้อยทั้งแปดบท

สิ่งที่จะทำต่อ

บทนี้วางแค่พื้น — MCP คืออะไร แก้ปัญหาอะไร และใครเล่นบทไหน จากนี้เราจะไล่จาก primitive ขึ้นไปหาการออกแบบและความปลอดภัย:

Primitive ทั้งสาม (บทที่ 2) — Tool (model ควบคุม), Resource (app ควบคุม), Prompt (ผู้ใช้ควบคุม) ต่างกันที่ ใครตัดสินใจว่าจะเรียกเมื่อไร
ออกแบบ tool เป็น ACL (บทที่ 3) — schema ของ tool เป็นทั้งพื้นผิวการใช้งานและพื้นผิวความปลอดภัย ตั้งชื่อเป็น namespace ใช้ field ที่มีความหมาย ยุบ CRUD บางๆ เป็น workflow tool
Resource กับ tool ต่างกันตรงไหน (บทที่ 4) — เส้นแบ่งคือ “ใครควบคุมการเรียก” ไม่ใช่ “อ่าน vs เขียน” และ human-in-the-loop บน tool เป็น SHOULD ไม่ใช่ MUST
Ubiquitous Language ของ server (บทที่ 5) — ชื่อและคำอธิบายของ primitive คือภาษาที่ model ใช้ให้เหตุผล และคำอธิบายเป็นสิ่งที่ ไม่ควรเชื่อโดยปริยาย
ความปลอดภัยคือสถาปัตยกรรม (บทที่ 6) — สี่หลักการของ spec, lethal trifecta, annotation ที่ไม่ใช่ trust boundary, sandbox ที่ จำกัดความเสียหาย ไม่ใช่ ป้องกัน
การประกอบและระบบนิเวศ (บทที่ 7) — sampling และ elicitation เป็นความสามารถฝั่ง client ไม่ใช่ primitive ของ server
เมื่อไร ไม่ ควรใช้ MCP (บทที่ 8) — เมื่อ REST/function-call ตรงๆ ชนะ และ MCP เพิ่มพื้นผิวความปลอดภัยโดยไม่จำเป็น

ทุกบทกลับมาที่ platform ฟู้ดเดลิเวอรีเดิมเสมอ — ไม่มี domain ใหม่ มีแต่การมองมันผ่านเลนส์ MCP server และย้ำวินัยเดิม: server surface คือภาษาที่เผยแพร่ของ bounded context และ tool ทุกตัวคือ ACL

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

บทนี้อ้างอิงแหล่งปฐมภูมิโดยตรง (ยังไม่มีการ์ด DevIQ สำหรับหัวข้อ MCP โดยเฉพาะ):

MCP Introduction — ที่มาของคำเปรียบ “USB-C สำหรับ AI”
Architecture (MCP spec 2025-11-25) — บทบาท Host/Client/Server บน JSON-RPC
Introducing MCP (Anthropic, พ.ย. 2024) — ปัญหาตัวเชื่อมเฉพาะกิจที่ MCP เกิดมาแก้
Donating MCP to the AAIF (Anthropic, ธ.ค. 2025) — MCP กลายเป็นมาตรฐานเป็นกลางใต้ Linux Foundation
คอร์ส Agent as Bounded Context — เลนส์ DDD (tool เป็น ACL, server surface เป็น published language) ที่คอร์สนี้ต่อยอด

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

ข้อ 1 / 3

คำเปรียบ "USB-C สำหรับ AI" ของ MCP มีที่มาจากแหล่งใด และควรอ้างเครดิตอย่างไร?

MCP คือ​อะไร แก้​ปัญหา​อะไร

MCP คือ “USB-C สำหรับ AI”

ปัญหา​ที่ MCP เกิด​มา​แก้: จาก M×N เป็น M+N

MCP ไม่ใช่ “โพรโทคอล​ของ Anthropic” อีก​ต่อ​ไป