MCP (Model Context Protocol) คืออะไร ทำไมนักพัฒนาควรรู้

ถ้าคุณเคยอยากให้ AI ผู้ช่วยเขียนโค้ดอ่าน issue ในระบบของทีม ดู schema ฐานข้อมูลจริง หรือค้นเอกสารภายในบริษัท คุณจะพบว่าแต่ละเครื่องมือมีวิธีเชื่อมต่อของตัวเอง ต้องเขียน integration ซ้ำไปซ้ำมา MCP หรือ Model Context Protocol ถูกสร้างขึ้นมาเพื่อแก้ปัญหานี้ คือเป็นมาตรฐานกลางสำหรับเชื่อมแอปพลิเคชัน AI เข้ากับเครื่องมือและแหล่งข้อมูลภายนอก บทความนี้จะอธิบายแนวคิดของ MCP ส่วนประกอบหลัก ตัวอย่างการใช้งานที่นักพัฒนาเจอบ่อย และที่สำคัญที่สุดคือเรื่องความปลอดภัยเมื่อติดตั้ง MCP server ที่คนอื่นเขียน

ปัญหาที่ MCP เข้ามาแก้

ก่อนมีมาตรฐานกลาง ถ้ามีแอป AI อยู่ M ตัว (เช่น IDE, แชตบอตบนเดสก์ท็อป, coding agent ใน terminal) และมีระบบที่อยากเชื่อมอยู่ N ระบบ (เช่น Git hosting, ฐานข้อมูล, ระบบ ticket, ไฟล์ในเครื่อง) ในกรณีแย่ที่สุดต้องเขียน integration ถึง M × N แบบ เพราะแต่ละแอปกำหนดรูปแบบ plugin ของตัวเอง

MCP เปลี่ยนสมการนี้ให้เหลือ M + N คือแอป AI แต่ละตัวรองรับ MCP ครั้งเดียว และระบบแต่ละระบบทำ MCP server ครั้งเดียว จากนั้นก็จับคู่กันได้หมด

MCP เป็น open protocol มีเอกสาร specification และ SDK สำหรับหลายภาษาที่ modelcontextprotocol.io ซึ่งควรเป็นแหล่งอ้างอิงหลักเวลาลงมือทำจริง เพราะรายละเอียดของ protocol มีการพัฒนาต่อเนื่อง

ส่วนประกอบหลัก: Host, Client, Server

สถาปัตยกรรมของ MCP มีบทบาทหลักสามแบบ:

• Host คือแอปพลิเคชัน AI ที่ผู้ใช้ใช้งานอยู่ เช่น IDE ที่มีผู้ช่วย AI หรือแอปแชตบนเดสก์ท็อป host เป็นคนคุมว่าจะเชื่อมต่อ server ไหน และคุมการขออนุญาตจากผู้ใช้
• Client คือส่วนที่อยู่ภายใน host ทำหน้าที่คุยกับ server หนึ่งตัวแบบหนึ่งต่อหนึ่ง host หนึ่งตัวจึงอาจมีหลาย client ถ้าเชื่อมหลาย server
• Server คือโปรแกรมที่เปิดความสามารถบางอย่างให้ AI ใช้ เช่น server สำหรับฐานข้อมูล server สำหรับระบบไฟล์ หรือ server ที่ห่อ API ภายในบริษัท

การสื่อสารระหว่าง client กับ server ใช้ข้อความรูปแบบ JSON-RPC ส่วนช่องทางรับส่ง (transport) มีทั้งแบบ server ที่รันเป็น process ในเครื่องและคุยผ่าน standard input/output และแบบ server ระยะไกลที่คุยผ่าน HTTP รายละเอียดของ transport แต่ละแบบให้ดูจาก specification

สิ่งที่ Server เปิดให้ใช้: Tools, Resources, Prompts

MCP server สามารถเปิดความสามารถได้สามประเภทหลัก ซึ่งต่างกันที่ว่า "ใครเป็นคนตัดสินใจใช้"

ถ้าคุณเคยอ่านเรื่อง Tool Use หรือ Function Calling มาก่อน แนวคิดของ tools ใน MCP ก็คล้ายกัน ต่างกันตรงที่ MCP ทำให้นิยาม tool อยู่ใน server ที่แยกออกมา และแอป AI ไหนที่รองรับ MCP ก็นำไปใช้ได้ ไม่ต้องผูกกับแอปเดียว

ตัวอย่างนิยาม tool ในเชิงแนวคิด (ใช้ JSON Schema อธิบาย input) จะมีหน้าตาประมาณนี้:

{
  "name": "find_orders",
  "description": "ค้นหาคำสั่งซื้อของลูกค้าตามรหัสลูกค้า คืนค่าไม่เกิน 20 รายการ อ่านอย่างเดียว",
  "inputSchema": {
    "type": "object",
    "properties": {
      "customer_id": { "type": "integer" },
      "status": { "type": "string", "enum": ["pending", "paid", "shipped"] }
    },
    "required": ["customer_id"]
  }
}

สังเกตว่าคำอธิบายบอกขอบเขตชัดเจน (อ่านอย่างเดียว คืนไม่เกิน 20 รายการ) ซึ่งช่วยทั้งโมเดลในการเลือกใช้ และช่วยผู้ใช้ในการตัดสินใจอนุมัติ

ตัวอย่างการใช้งานที่นักพัฒนาเจอบ่อย

• ฐานข้อมูล ให้ AI อ่าน schema ของ PostgreSQL จริงเพื่อช่วยเขียน query หรือ migration แทนที่จะต้องคัดลอก DDL ไปวางเอง
• ระบบไฟล์และเอกสาร ให้ AI ค้นเอกสารภายในทีม เช่น coding standard หรือคู่มือ deploy
• Git hosting และ issue tracker ให้ coding agent อ่านรายละเอียด issue แล้วเสนอการแก้ไข หรือสรุปการเปลี่ยนแปลงของ pull request
• ระบบภายในบริษัท ทีมเขียน MCP server ห่อ API ของตัวเอง เช่น ระบบสต็อก หรือระบบ HR แบบอ่านอย่างเดียว เพื่อให้พนักงานถามข้อมูลผ่านแอป AI ที่ใช้อยู่แล้ว

สำหรับทีม PHP/Yii2 แนวทางที่ปลอดภัยในการเริ่มต้นคือทำ server ที่เปิดเฉพาะข้อมูลแบบอ่านอย่างเดียว เช่น schema และข้อมูลตัวอย่างจากฐานข้อมูล dev แล้วค่อยพิจารณาเพิ่ม tool ที่เขียนข้อมูลเมื่อเข้าใจความเสี่ยงดีแล้ว

ความปลอดภัย: Server ที่ติดตั้งคือโค้ดที่รันด้วยสิทธิ์ของคุณ

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

ความเสี่ยงหลักที่ควรรู้:

• โค้ดอันตรายหรือ supply chain server อาจถูกเขียนมาให้ขโมยไฟล์ .env หรือ SSH key หรือ dependency ของมันอาจถูกแทรกโค้ดภายหลัง
• Prompt injection ผ่านข้อมูล ข้อความที่ server ส่งกลับมา เช่น เนื้อหา issue หรือหน้าเว็บ อาจมีคำสั่งแฝงที่หลอกให้โมเดลเรียก tool อื่นทำสิ่งที่ผู้ใช้ไม่ได้ตั้งใจ
• คำอธิบาย tool ที่ชี้นำ ข้อความ description ของ tool ถูกส่งให้โมเดลอ่าน server ที่ไม่น่าไว้ใจอาจซ่อนคำสั่งไว้ในนั้น
• สิทธิ์มากเกินจำเป็น server ฐานข้อมูลที่เชื่อมด้วย user ที่มีสิทธิ์ DROP หรือ DELETE บน production เปิดโอกาสให้ความผิดพลาดเล็ก ๆ กลายเป็นเรื่องใหญ่
• ข้อมูลรั่วออกนอกองค์กร ข้อมูลที่ tool ดึงมาจะถูกส่งเข้าไปในบริบทของโมเดล ต้องแน่ใจว่าเป็นข้อมูลที่อนุญาตให้ส่งไปยังผู้ให้บริการ AI ได้

Checklist ก่อนติดตั้ง MCP server:

1. ติดตั้งจากแหล่งที่เชื่อถือได้ อ่าน source code หรืออย่างน้อยดู repository ผู้ดูแล และ dependency
2. ปักเวอร์ชันให้แน่นอน ไม่ดึงเวอร์ชันล่าสุดอัตโนมัติทุกครั้งที่รัน
3. ให้สิทธิ์น้อยที่สุด เช่น user ฐานข้อมูลแบบอ่านอย่างเดียว ชี้ไปที่ฐาน dev ไม่ใช่ production จำกัดโฟลเดอร์ที่ server เข้าถึงได้
4. ใส่ credential ผ่าน environment หรือ secret manager อย่า commit ไฟล์ config ที่มี token ลง Git
5. เปิดการยืนยันก่อนเรียก tool ที่เขียนหรือลบข้อมูลไว้เสมอ และอ่านจริง ๆ ก่อนกดอนุมัติ
6. ปิดหรือถอน server ที่ไม่ได้ใช้แล้ว

ถ้าคุณเป็นคนเขียน server เอง ให้คิดแบบเดียวกับการเขียน API สาธารณะ คือ validate input ทุกตัว ใช้ prepared statement ห้ามต่อ string เป็น SQL จำกัดจำนวนผลลัพธ์ และ log การเรียกใช้ tool ไว้ตรวจสอบย้อนหลัง

สรุป

• MCP คือ open protocol สำหรับเชื่อมแอป AI กับเครื่องมือและข้อมูลภายนอก ลดงาน integration จาก M × N เหลือ M + N
• host คือแอปที่ผู้ใช้ใช้งาน client อยู่ใน host และคุยกับ server ซึ่งเปิดความสามารถให้ใช้
• server เปิดได้สามแบบหลัก คือ tools ที่โมเดลเรียกได้ resources ที่เป็นข้อมูลบริบท และ prompts ที่เป็นแม่แบบให้ผู้ใช้เลือก
• MCP server ในเครื่องคือโค้ดที่รันด้วยสิทธิ์ของคุณ ต้องตรวจแหล่งที่มา ปักเวอร์ชัน และให้สิทธิ์น้อยที่สุด
• ข้อมูลที่ไหลผ่าน tool อาจมี prompt injection จึงต้องอ่านก่อนอนุมัติการกระทำที่มีผลข้างเคียงเสมอ

ลองทำ

สำรวจแอป AI ที่คุณใช้เขียนโค้ดอยู่ว่ารองรับ MCP หรือไม่ ถ้ารองรับ ให้ลองเขียน "แผนการติดตั้ง" ของ server ตัวหนึ่งที่สนใจ เช่น server สำหรับ PostgreSQL โดยตอบคำถามต่อไปนี้ให้ครบก่อนติดตั้งจริง: ใครเป็นผู้ดูแล source code อยู่ที่ไหน server จะเห็นไฟล์หรือข้อมูลอะไรบ้าง จะใช้ database user ที่มีสิทธิ์อะไร (ลองสร้าง role ที่มีเฉพาะ SELECT บนฐาน dev) และ tool ตัวไหนที่ต้องตั้งให้ขออนุมัติทุกครั้ง จากนั้นค่อยติดตั้งตามแผนและลองถามคำถามเกี่ยวกับ schema ดู