ลองนึกภาพว่า...
คุณมีผู้ช่วยที่ฉลาดมาก พูดอะไรก็เข้าใจ แต่คุณต้องคอยบอกเสมอว่า
- “ข้อมูลอยู่ในแฟ้มไหน”
- “ทีมเราชื่ออะไร”
- “เมื่อวานเราคุยเรื่องอะไรไปแล้ว”
ผู้ช่วยแบบนั้นยังถือว่าทำงานแทนเราได้จริงหรือเปล่า?
นี่แหละครับ คือปัญหาที่ Model Context Protocol หรือ MCP พยายามเข้ามาแก้
ปัญหา: เมื่อต้องให้ Agent ใช้งาน API จริง
สมมุติว่าเรามี AI Agent ที่อยากให้ทำสิ่งต่าง ๆ เช่น:
- ส่งข้อความใน Slack
- ส่งอีเมลด้วย Gmail
- ดึงข้อมูลจาก Database
โดยทั่วไปแล้ว สิ่งเหล่านี้เราต้อง “เขียนโค้ดเองทั้งหมด” เช่น:
- ไปเปิดเอกสาร API ของ Slack, Gmail, ฐานข้อมูล
- ศึกษาว่าแต่ละอันต้องส่งข้อมูลแบบไหน (payload)
- เขียนฟังก์ชันของเราเอง แล้วให้ agent เรียกใช้

ลองนึกภาพว่า agent คือ Cursor Editor (https://cursor.com) ถ้าอยากให้มัน “ดึงยอดขายวันนี้ แล้วส่งให้ทีมดูใน Slack” ต้องทำอะไรบ้าง?
Cursor ไม่รู้ว่า database ของเราอยู่ที่ไหน, table ชื่ออะไร, หรือ Slack workspace ชื่ออะไรเลย เราจึงต้อง:
- สร้างฟังก์ชันดึงข้อมูล
- สร้างฟังก์ชันส่งข้อความไป Slack
- เขียน script เอง และให้ agent รู้จัก script นี้ผ่านการ prompt

ปัญหาฝั่ง script (คนเขียน)
- ถ้าข้อมูลในระบบหายไป... จะให้ agent ส่งอะไร ? -> คุณต้องเขียนโค๊ดรองรับ "กรณีผิดพลาด" เองทั้งหมด
- ต้องใส่ระบบยืนยันตัวตน, ป้องกันกรณี agent เรียกใช้บ่อยเกิน, แปลงรูปแบบข้อความให้ถูกต้อง -> ต้องทำเองทั้งหมด
- ถ้าวันนึงต้องมาเพิ่ม feature -> ต้องกลับมาแก้โค๊ดเดิมหรือเขียนสคริปใหม่อีกชุด
- สุดท้ายจะมีคริปต์หลายอันจนจำไม่ได้ว่าอันใหนทำอะไร -> และพออยากใช้ข้อมูล "ของเมื่อวาน" ยังต้องมาแก้ query มือ
ปัญหาของฝั่ง agent ที่ใช้
แม้คุณจะเขียนสคริปต์ไว้ดีแค่ไหน
แต่ปัญหาฝั่ง agent ก็ยังมีอยู่
- Agent ส่วนใหญ่ไม่มีความจำ ถ้าคุณเผลอสั่งซ้ำ เช่น "ส่งยอดขายวันนี้" มันก็จะทำซ้ำทันทีโดยที่ไม่ถามหรือเตือนเลย
- Agent แต่ละเจ้ามีวิธีเชื่อมต่อที่ไม่เหมือนกัน ถ้าวันนึงคุณต้องเปลี่ยน Agent ตัวใหม่. สคริปต์เดิมอาจใช้ไม่ได้ และต้องเขียนใหม่อีกรอบ ซึ่งส่วนนี้เราจะมาทำความเข้าใจเพิ่มว่าทำไม
ปัญหายิ่งชัด เมื่อเอา script ไปใช้กับ Agent ตัวอื่น เช่น Windsurf
- Cursor ใช้ script แบบ Node.js
- Windsurf ต้องประกาศล่วงหน้าใน
winds.yml
ว่า prompt ไหนใช้ script ไหน - ต้องเขียน logic เป็น declarative plan ล่วงหน้า ไม่เหมือน Cursor ที่รันตาม script ได้เลย
Flow การทำงานของ agent แต่ละตัวไม่เหมือนกัน จึงยากที่จะใช้ script ร่วมกันได้ในหลาย agent
สังเกตุ flow ของทั้ง 2 Agent จะเป็นประมาณนี้
- Cursor
[User Prompt]
↓
"ดึงข้อมูลการขายล่าสุด"
↓
[LLM วิเคราะห์ intent]
↓
[ดึง script ที่ user เขียน]
const result = await db.query("SELECT ...");
↓
[แสดงผลใน console / inline display]
- Windsurf
[User สร้าง winds.yml]
↓
tools:
- name: querySales
path: ./tools/querySales.js
steps:
- name: getSales
tool: querySales
↓
[Agent runtime อ่าน plan]
↓
[Agent เรียก tool → รัน query]
↓
[แสดงผลใน stdout / result log]
แล้ว MCP เข้ามาช่วยแก้ปัญหาอะไร
MCP คือ “สมองกลาง” ที่เชื่อม Agents ↔ Tools/API เข้ามาเพื่อทำให้ Agent เข้าใจบริบท รู้ว่าต้องทำอะไร ใช้ tool อะไร ด้วยตัวมันเองและเป็นกลางใช้งานได้สำหรับ agent อื่นๆ การทำแบบนี้จะตรงตามหลักการที่ว่า
If you want to solve a problem you simply need to add another layer of abstraction (ถ้าปัญหามันยุ่งยากเราก็แค่ "แยกให้มันคุยกันผ่านอีก layer นึง)

MCP Server เป็น ระบบที่ทำตามแนวคิด MCP ซึ่งคอยประมวลและจัดการการทำงานของ agent อย่างมีลำดับ โดยทั้งสองจะสื่อสารกันโดยใช้ MCP protocol
หลักการทำงานของ MCP Server:
- รับ prompt จาก agent เช่น “ดึงข้อมูลยอดขายวันนี้ ส่งให้ทีมใน Slack”
- วิเคราะห์ว่า user คนนี้คือใคร, ใช้เครื่องมืออะไรได้บ้าง
- วางแผนลำดับงาน (ไม่ต้องเขียน prompt หลายขั้นเอง)
- หา API ที่เหมาะสม เช่น Slack API, DB API
- เติมข้อมูล context เช่น “วันนี้” คือวันที่เท่าไหร่
- เรียกใช้ API จริง พร้อมจัดการ auth, error, retry ให้เอง
- ส่งผลลัพธ์กลับ agent อย่างเรียบร้อย
- เก็บ log และ trace เพื่อตรวจสอบย้อนหลังได้
✅ ทำให้เราสามารถใช้ agent ตัวไหนก็ได้ โดยไม่ต้องเขียนโค้ดใหม่ซ้ำ ๆ
สรุป
เราคาดหวังว่า agent จะทำงานแทนเรา — ไม่ใช่แค่เข้าใจภาษา แต่คือเข้าใจ context รอบข้าง, รู้ว่าใครคือทีม, เคยทำอะไรมาบ้าง
MCP จึงไม่ใช่แค่ตัวเชื่อม API แต่มันคือโครงสร้างความเข้าใจ ที่ช่วยให้ agent ทำงานกับโลกจริงได้
เมื่อ agent เข้าใจโลกมากขึ้น โลกก็ต้องมีโครงสร้างให้ agent เข้าใจด้วยเช่นกัน