อธิบาย MCP: Model Context Protocol ทำงานอย่างไร

LLM สามารถเรียกใช้เครื่องมือได้มาระยะหนึ่งแล้ว แต่ Model Context Protocol (MCP) ทำให้การทำงานนี้มีโครงสร้างและเป็นมาตรฐานมากขึ้น

อย่างไรก็ตาม ยังมีความสับสนว่า MCP จริง ๆ แล้ว คือ อะไร

หลายคนคิดว่า MCP เป็นแอป, API หรือเครื่องมือบางอย่าง แต่ไม่ใช่เลย MCP คือโปรโตคอล และคำนี้มีความหมายเฉพาะเจาะจงมาก

มาดูรายละเอียดกัน

หากคุณต้องการดูว่า MCP ช่วยให้ทำอะไรได้ในทางปฏิบัติ ดูวิดีโอสั้นนี้ได้เลย:

โปรโตคอลคืออะไร

โปรโตคอลคือชุดกฎที่กำหนดว่าระบบตั้งแต่สองระบบขึ้นไปสื่อสารกันอย่างไร

ตัวโปรโตคอลเองไม่ได้ทำอะไรโดยตรง เพียงกำหนดโครงสร้างและความคาดหมายของการสนทนาระหว่างสองเอนทิตี ให้คิดว่าเป็น ภาษากลางที่มีกฎไวยากรณ์เคร่งครัด ซึ่งคอมพิวเตอร์ใช้ในการแลกเปลี่ยนข้อมูล

ระบบไปรษณีย์ทำสิ่งที่คล้ายกัน ที่ทำการไปรษณีย์ทุกแห่งในประเทศหนึ่ง ๆ ใช้รูปแบบที่อยู่มาตรฐานเดียวกันเพื่อส่งจดหมาย

หรือมองว่าเหมือน USB-C สำหรับเครื่องมือ AI ก็ได้ เมื่อ 20 ปีก่อน ตลาดเต็มไปด้วยสายชาร์จและสายส่งข้อมูลหลายประเภท เช่นเดียวกับระบบนิเวศ AI ที่เคยมีหลายวิธีในการส่งเครื่องมือให้โมเดลภาษา เฟรมเวิร์กอย่าง LangChain, Haystack และ Pydantic AI ต่างกำหนดรูปแบบของตนเองสำหรับการผสานเครื่องมือ ซึ่งหมายความว่าหากนักพัฒนาต้องการเขียนชุดเครื่องมือสำหรับ Google Maps ก็ต้องทำสำหรับเทคโนโลยีเฉพาะ แต่ละ แบบ

เพื่อให้เห็นภาพชัดขึ้น มาดูโปรโตคอลที่ได้รับความนิยมมากที่สุดอย่าง HTTP (Hypertext Transfer Protocol) ซึ่งขับเคลื่อนเว็บไซต์ HTTP กำหนดหลายสิ่ง รวมถึงวิธีที่เบราว์เซอร์ (ไคลเอนต์) ขอเว็บเพจจากเว็บเซิร์ฟเวอร์ และวิธีที่เซิร์ฟเวอร์ควรตอบกลับ

นี่คือตัวอย่างวงจร request-response ของ HTTP:

1. เบราว์เซอร์ส่งคำขอ HTTP

เมื่อคุณพิมพ์ https://example.com ในเบราว์เซอร์ เบราว์เซอร์จะส่งคำขอ HTTP ที่มีโครงสร้างไปยังเว็บเซิร์ฟเวอร์:

นี่คือพารามิเตอร์และค่าของ HTTP ที่ใช้ในตัวอย่างของเรา:

"GET" – นี่คือการกระทำ (ขอเว็บเพจ)
"/index.html" – เว็บเพจเฉพาะที่ถูกขอ
"HTTP/1.1" – เวอร์ชันของโปรโตคอลที่ใช้
"Host: example.com" – ชื่อโดเมนของเว็บไซต์
"User-Agent: Mozilla/5.0" – ข้อมูลเกี่ยวกับเบราว์เซอร์ที่ส่งคำขอ

เว็บเซิร์ฟเวอร์รู้วิธีตีความคำขอนี้เพราะ HTTP ทำให้รูปแบบนี้เป็นมาตรฐาน เซิร์ฟเวอร์เข้าใจ “ภาษา” นี้

2. เซิร์ฟเวอร์ตอบกลับโดยใช้โปรโตคอล HTTP

เซิร์ฟเวอร์ประมวลผลคำขอและส่งคำตอบ HTTP ที่มีโครงสร้างกลับมา:

"HTTP/1.1 200 OK" – รหัสตอบกลับ (200 หมายถึงสำเร็จ)
"Content-Type: text/html" – ประเภทของเนื้อหาที่ส่งกลับ
"Content-Length: 512" – ขนาดของคำตอบ
HTML Content – เนื้อหาเว็บเพจจริง (มีเพียงหัวข้อ "Welcome to Example.com")

ข้อสำคัญ: HTTP เองไม่ได้ จัดเก็บ เว็บเพจหรือแสดงผลเว็บเพจ มันเพียงกำหนด กฎ ว่าเว็บเบราว์เซอร์และเว็บเซิร์ฟเวอร์ได้รับอนุญาตให้สื่อสารกันอย่างไร ระบบใดก็ตามที่ทำตามกฎเหล่านี้สามารถสื่อสารผ่านอินเทอร์เน็ตที่กำหนดด้วย HTTP ได้

MCP ทำงานอย่างไรในฐานะโปรโตคอล

ตอนนี้ ลองนำแนวคิดเดียวกันมาใช้กับ MCP (Model Context Protocol)

MCP คือโปรโตคอลสำหรับให้ AI agents สื่อสารกับเครื่องมือและแหล่งข้อมูลภายนอก เช่นเดียวกับ HTTP, MCP ไม่ได้จัดเก็บข้อมูลหรือดำเนินงานด้วยตัวเอง มันเพียงกำหนด วิธีมาตรฐาน ให้ AI ขอและดึงข้อมูลจากเครื่องมือ

แล้ว “เครื่องมือ” เหล่านั้นคืออะไร

ในบริบทของ LLM, เครื่องมือคือระบบภายนอก, API หรือบริการที่ AI สามารถโต้ตอบด้วยเพื่อขยายความสามารถออกไปนอกเหนือจากการสร้างข้อความ เครื่องมือทำให้ AI agents สามารถดึงข้อมูลแบบเรียลไทม์ จองนัดหมาย หรือส่งข้อความหาเพื่อนของคุณได้ ทำให้มีประโยชน์ต่อความต้องการในโลกจริงมากขึ้นมาก

สมมติว่าคุณถาม AI agent ว่า:

“ตอนนี้ที่ลอนดอนกี่โมง”

เนื่องจากตัว AI เองไม่รู้คำตอบที่ถูกต้อง เพราะโมเดล AI มีวันตัดความรู้ (ตุลาคม 2023 สำหรับโมเดลของ OpenAI) จึงต้องดึงข้อมูลสดจากบริการเวลา แต่แทนที่จะใช้ HTTP เพื่อขอเว็บเพจ AI ใช้ MCP เพื่อขอข้อมูลเวลา

สิ่งที่เกิดขึ้นคือ:

1. AI agent ส่งคำขอ MCP ไปยังบริการเวลา (ตัวอย่าง)

"method": "tools.call" → AI กำลังเรียกใช้เครื่องมือภายนอก
"tool": "get_time" → ชื่อของเครื่องมือที่ต้องการใช้
"args": { "location": "London" } → พารามิเตอร์อินพุตเฉพาะ

เช่นเดียวกับ HTTP คำขอนี้ทำตามรูปแบบที่เคร่งครัด เพื่อให้เครื่องมือใดก็ตามที่รองรับ MCP รู้แน่ชัดว่าต้องตีความอย่างไร

2. เซิร์ฟเวอร์เวลา MCP ตอบกลับ

เครื่องมือภายนอก (เซิร์ฟเวอร์เวลา) ทำตามกฎการตอบกลับของ MCP และส่งกลับ:

"status": "success" → ยืนยันว่าคำขอถูกประมวลผลอย่างถูกต้อง
"result" → มีข้อมูลเวลาจริง

ตอนนี้ AI agent สามารถนำข้อมูลนี้ไปประกอบเป็นคำตอบจริงให้ผู้ใช้ได้ว่า:

“เวลาปัจจุบันในลอนดอนคือ 12:20 PM (GMT)”

เพื่อสรุปและลดความสับสน:

“MCP เป็นแอป” → ไม่ใช่ MCP คือชุดกฎ คุณต้องมีซอฟต์แวร์ AI และเครื่องมือที่นำ MCP ไปใช้งานจริงจึงจะใช้ได้ เช่นเดียวกับที่แอป Instagram ต้องใช้เซิร์ฟเวอร์ Instagram ที่ทำงานอยู่เพื่อตอบคำขอ HTTP และส่งข้อมูล

“MCP เป็นฐานข้อมูล” → ไม่ใช่ MCP ไม่ได้จัดเก็บข้อมูล มันช่วยให้ AI agents สื่อสารกับฐานข้อมูลหรือ API

“MCP เหมือน API” → ไม่เชิง API คือวิธีเฉพาะในการโต้ตอบกับระบบหนึ่งระบบ ในขณะที่โปรโตคอล (เช่น MCP หรือ HTTP) กำหนดวิธีสากลที่ระบบหลายแบบใช้สื่อสารกันได้ MCP คือภาษาที่ระบบ AI ใช้โต้ตอบกับ API จริงจำนวนมากได้ (เวลา, ฐานข้อมูล, Stripe, Slack ฯลฯ)

ทำไม MCP จึงน่าสนใจ

ตอนนี้เรารู้แล้วว่า MCP คือวิธีมาตรฐานสำหรับให้ซอฟต์แวร์ AI โต้ตอบกับเครื่องมือและแอปภายนอก และ MCP ไม่ใช่ API มาทำความเข้าใจว่าทำไมชุมชนนักพัฒนา AI (รวมถึงเรา) จึงสนใจมัน

เนื่องจาก MCP ไม่ใช่ API แต่ช่วยให้แอป AI โต้ตอบกับ API จริงได้ในระดับขนาดใหญ่ จึงช่วยให้โปรเจกต์ที่ต้องเชื่อมต่อกับระบบภายนอกจำนวนมากเริ่มต้นได้เร็วขึ้น เครื่องมือยังเพิ่มระยะเอื้อมให้โมเดลด้วย และ สิ่งที่เกิดขึ้นในเหตุการณ์ OpenAI Hugging Face คือภาพของระยะเอื้อมนั้นเมื่อมันเกินขอบเขตของงาน ในการทำสิ่งนี้ นักพัฒนาบางครั้งต้องผ่านวงจรการพัฒนา integration กับ API แบบเต็ม แต่ปัจจุบันมักใช้ไลบรารีหรือโปรเจกต์โอเพนซอร์สที่มีอยู่แล้ว (เช่น ที่มีบน GitHub) ซึ่งให้ฟังก์ชันที่ต้องการ

การใช้ไลบรารีเหล่านี้ช่วยเริ่มการพัฒนาได้เร็วขึ้น แต่ การผสานเข้ากับระบบของคุณอย่างถูกต้อง (หากไม่รองรับ implementation ที่คุณพบบน GitHub) ยังต้องใช้ความพยายาม เพื่อให้เครื่องมือทำงานร่วมกับ AI ได้

เมื่อใช้ MCP หากมีเฟรมเวิร์กพร้อมแล้ว การเพิ่ม integration ใหม่ (เช่น การเชื่อม Google Drive) อาจเป็นเพียงการเชื่อมต่อกับเซิร์ฟเวอร์ Google Drive MCP ด้วยโค้ดไม่กี่บรรทัด คุณจะไม่พบปัญหาความเข้ากันได้ เพราะทั้งสองฝ่ายใช้โปรโตคอลเดียวกันคือ MCP

มาลองเปรียบเทียบสองแนวทางเพื่อดูความแตกต่างให้ชัดขึ้น

การผสานแบบมาตรฐานเทียบกับการใช้ Model Context Protocol (MCP)

เพื่อให้การเปรียบเทียบนี้เป็นรูปธรรม มาดูการเพิ่มการเข้าถึงไฟล์ Google Drive ให้ AI Agent โดยเริ่มจากการทำด้วยตนเอง แล้วตามด้วยเครื่องมือที่รองรับ MCP

การผสานแบบมาตรฐาน

1. หาและปรับไลบรารี: คุณค้นหาไคลเอนต์ Google Drive API หรือโปรเจกต์โอเพนซอร์ส Google มีไลบรารีไคลเอนต์ให้ (เช่น Google Drive API for Python) คุณนำสิ่งนี้เข้าไปในโปรเจกต์ แต่ยังต้องตรวจสอบให้แน่ใจว่ามันทำงานกับสภาพแวดล้อมของ AI ของคุณได้

2. เขียนลอจิก: คุณเขียนฟังก์ชัน เช่น ค้นหาไฟล์หรือดึงเอกสารจาก Drive เมื่อ AI ต้องการบางอย่าง AI ต้องเรียกฟังก์ชันเหล่านี้ คุณจัดรูปแบบคำขอของ AI ให้เป็นการเรียก API เฉพาะของ Google Drive หลังจากได้รับคำตอบจาก Google คุณดึงเนื้อหาออกมาเพื่อส่งกลับไปยัง context ของ AI

3. จัดการข้อผิดพลาดและกรณีพิเศษ: เพิ่มโค้ดเพื่อจัดการกรณีอย่าง “ไม่พบไฟล์” ข้อผิดพลาดด้านสิทธิ์ หรือ rate limit ของ API หาก API ของ Google ส่งข้อผิดพลาดกลับมา คุณต้องจับข้อผิดพลาดนั้น และอาจตอบด้วยข้อความขออภัยหรือให้ AI ถามใหม่ คุณยังต้องป้องกันไม่ให้ AI ส่งคำขอมากเกินไปในเวลาสั้นเกินไป

4. บำรุงรักษา: เมื่อเวลาผ่านไป หาก Google อัปเดต API หรือไลบรารี คุณต้องอัปเดตโค้ดของคุณ หากพบบั๊กในไลบรารี คุณอาจต้องแพตช์หรือหาแหล่งอื่น โดยพื้นฐานแล้วคุณกลายเป็นผู้ดูแล integration ของ Google Drive นี้ภายในแอปพลิเคชัน AI ของคุณ

กระบวนการนี้ขยายไปยังเครื่องมืออื่นด้วย ต้องการเพิ่ม Slack หรือฐานข้อมูลให้ AI ของคุณหรือไม่ คุณต้องทำกระบวนการทั้งหมดซ้ำสำหรับแต่ละเครื่องมือ

การผสานด้วย MCP

ตอนนี้มาดูกันว่ากระบวนการจะเป็นอย่างไรเมื่อใช้ MCP

ก่อนอื่น มากำหนดแนวคิดหลัก:

Client – แอปพลิเคชัน AI (ChatGPT, Claude app, Quickchat AI) ที่สร้างการเชื่อมต่อกับเซิร์ฟเวอร์หนึ่งตัวหรือมากกว่า และขอข้อมูลหรือการกระทำเพื่อทำงานตามที่ผู้ใช้สั่ง

Server – แต่ละเซิร์ฟเวอร์อาจเชื่อมต่อกับสิ่งอย่างฐานข้อมูล, API (Google Drive) และกำหนดชุดของ “เครื่องมือ” หรือข้อมูลที่สามารถให้ได้ ในกรณีนี้ เซิร์ฟเวอร์คือโปรแกรมที่เปิดเผยเครื่องมือและความสามารถเหล่านี้ให้ Client (แอป AI)

นักพัฒนาเลือกอยู่ฝั่งใดฝั่งหนึ่งได้ตามสิ่งที่ต้องการทำ: สร้างเซิร์ฟเวอร์เพื่อเปิดเผยข้อมูล หรือสร้าง AI client ที่คุยกับเซิร์ฟเวอร์ใดก็ได้ คนส่วนใหญ่มักต้องการตัวเลือกที่สอง แต่เราจะเริ่มจากฝั่งเซิร์ฟเวอร์ก่อนเพื่อทำความเข้าใจว่า MCP ทำงานทีละขั้นตอนอย่างไร:

• การเริ่มต้น MCP server นักพัฒนาหรือผู้ดูแลระบบตั้งค่า MCP server สำหรับเครื่องมือหรือแหล่งข้อมูลที่กำหนด MCP server มักเป็นเพียงโปรแกรมขนาดเล็กที่ implement ข้อกำหนดของ MCP ตัวอย่างเช่น มีเซิร์ฟเวอร์ pre-built Google Drive MCP ให้ใช้งาน ซึ่งรู้วิธีค้นหาและดึงเอกสาร

  เมื่อเริ่มต้นเซิร์ฟเวอร์ คุณให้สิทธิ์เข้าถึงระบบเป้าหมาย (Google Drive) แก่เซิร์ฟเวอร์ จากนั้นเซิร์ฟเวอร์จะเปิดเผยชุดเครื่องมือที่สอดคล้องกับการกระทำหรือคำค้นที่มันจัดการได้ โดยพื้นฐานแล้วมันคือ API adapter ที่พูด MCP ฝั่งหนึ่ง และพูดกับบริการ native อีกฝั่งหนึ่ง

  เมื่อเซิร์ฟเวอร์ทำงานแล้ว มันจะรอรับคำขอ

• การเชื่อม LLM (client) กับ MCP server ขั้นถัดไป แอปพลิเคชัน AI (ฝั่ง “client”) ต้องเชื่อมต่อกับเซิร์ฟเวอร์นั้น ในทางปฏิบัติ หากคุณใช้แพลตฟอร์ม AI ที่รองรับ MCP (เช่น Claude Desktop) คุณจะกำหนดค่าด้วยที่อยู่หรือคำสั่งเพื่อเริ่มเซิร์ฟเวอร์ เมื่อเชื่อมต่อแล้ว client จะสร้าง session กับเซิร์ฟเวอร์ตาม handshake ของ MCP หากคุณใช้ interface ของ Claude คุณจะเห็นว่า Claude “connected” กับ MCP servers บางตัว (UI อาจแสดง connectors ที่ใช้ได้)

นี่คือลักษณะที่แสดงใน Claude UI

• การค้นหาเครื่องมือที่มีอยู่ เมื่อสร้างการเชื่อมต่อแล้ว สิ่งแรกที่ต้องทำคือดูว่าเซิร์ฟเวอร์มีอะไรให้ใช้งาน (บางครั้งเกิดขึ้นอัตโนมัติหลังจากคุณเชื่อมต่อกับเซิร์ฟเวอร์) MCP client ส่งคำขอ tools/list ไปยังเซิร์ฟเวอร์ (สิ่งนี้กำหนดไว้ในโปรโตคอล) เซิร์ฟเวอร์ตอบกลับด้วยรายการเครื่องมือที่มีอยู่ โดยแต่ละรายการมีรายละเอียด เช่น ชื่อ คำอธิบาย และ input schema

  ตัวอย่างเช่น เซิร์ฟเวอร์อาจตอบว่ามีเครื่องมือ create_file(path, content), read_file(path) และ search_files(query) ให้ใช้งาน จากนั้น client จะทำให้ข้อมูลนี้พร้อมใช้งานสำหรับ LLM ในหลาย implementation, client จะจัดรูปแบบคำอธิบายเครื่องมือเหล่านี้และใส่ไว้ใน context ของโมเดล (เช่น เพิ่มลงใน system prompt: “คุณมีสิทธิ์เข้าถึงเครื่องมือต่อไปนี้… [รายการเครื่องมือ]”)

นี่คือ system prompt ของ AI พร้อมข้อความของผู้ใช้ที่ขอเวลาปัจจุบัน

เมื่อ implement เครื่องมือ MCP แล้ว เครื่องมือชื่อ “get_current_time” จะถูกผสานเข้ามา ทำให้ AI เข้าถึงทรัพยากรภายนอกและดึงเวลาที่แน่นอนในลอนดอนได้

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

• การใช้เครื่องมือผ่าน MCP เมื่อ AI ต้องดำเนินการหรือดึงข้อมูล มันจะเรียกใช้เครื่องมือผ่าน MCP จากมุมมองของ AI (โดยเฉพาะโมเดลอย่าง Claude ที่รองรับการใช้เครื่องมือโดยตรง) มันจะตัดสินในกระบวนการ reasoning ว่า “ฉันควรเรียกเครื่องมือ X ด้วยพารามิเตอร์เหล่านี้” MCP client จะจับเจตนานั้นและส่งคำขอ tools/call ในรูปแบบ MCP ไปยังเซิร์ฟเวอร์ที่เหมาะสม (Google Drive MCP server)

• MCP server ทำหน้าที่เป็นสะพาน มันรับคำขอที่มีโครงสร้างและเป็นไปตาม MCP จาก AI agent, map ไปยัง endpoint ของ Google Drive API ที่ถูกต้อง, เขียนคำขอใหม่เป็นการเรียก Google Drive API จริง, ดำเนินการตามคำขอ, ประมวลผลคำตอบ และจัดรูปแบบกลับเป็นคำตอบที่สอดคล้องกับ MCP อีกครั้งก่อนส่งกลับไปยัง AI agent

  สิ่งที่ควรสังเกตคือ MCP servers ทำตามแนวทางที่มีโครงสร้างในการจัดการข้อผิดพลาด เพื่อให้ AI Agents ตีความและดำเนินการกับข้อผิดพลาดได้อย่างมีประสิทธิภาพ

  สมมติว่า AI Agent ใช้เครื่องมือ MCP เพื่อค้นหาไฟล์ใน Google Drive หากคำขอมี file ID ที่ไม่ถูกต้อง (เช่น สตริงความยาวห้าตัวอักษรแทนรูปแบบที่คาดไว้) MCP server จะส่งข้อความข้อผิดพลาดกลับมา:

  แทนที่จะล้มเหลวเฉย ๆ AI Agent สามารถนำคำตอบที่มีโครงสร้างนี้มาเรียบเรียงเป็น feedback ที่เป็นมิตรกับผู้ใช้:

  “ดูเหมือนว่า file ID ที่คุณให้มาจะสั้นเกินไป Google Drive file ID โดยทั่วไปมีความยาว 28 ตัวอักษร โปรดตรวจสอบอีกครั้งแล้วลองใหม่ได้ไหม”

  แนวทางนี้ทำให้ข้อผิดพลาดไม่กลายเป็นทางตัน แต่เปลี่ยนเป็นโอกาสให้ AI Agent ช่วยนำผู้ใช้ไปสู่การแก้ไขที่สำเร็จ

• การตอบคำถาม/คำขอของผู้ใช้ เมื่อ MCP server ส่งผลลัพธ์กลับมา MCP client จะส่งข้อมูลนั้นกลับให้แอป AI จากนั้นโมเดลจะนำผลลัพธ์ไปรวมในการ reasoning หรือรวมโดยตรงใน output ที่สร้างให้ผู้ใช้

  หากผู้ใช้ขอให้สร้างไฟล์ Google Sheets ใหม่ คำตอบจากเซิร์ฟเวอร์ (ที่มี file ID และลิงก์ที่สร้างขึ้น) จะถูกส่งเข้าโมเดล จากนั้นโมเดลจะตอบผู้ใช้ว่า: “ข่าวดี ไฟล์ Google Sheets ใหม่ของคุณพร้อมแล้ว คุณสามารถเข้าถึงได้ที่นี่: [link]”

ตลอดกระบวนการนี้ AI ยังคงควบคุม flow: มันตัดสินใจว่าจะเรียกเครื่องมือเมื่อใดและจะใช้ผลลัพธ์ในการสร้างคำตอบอย่างไร ขณะเดียวกัน นักพัฒนาไม่ต้อง orchestrate ขั้นตอนเหล่านี้ด้วยตนเอง เฟรมเวิร์ก MCP และโมเดล AI จัดการให้ ผลลัพธ์สุดท้ายคือผู้ใช้สามารถถามคำถามหรืองานที่ซับซ้อนซึ่งต้องใช้ข้อมูลหรือการกระทำจากภายนอก และ AI สามารถ ดำเนินการเหล่านั้นได้โดยอัตโนมัติ ผ่าน MCP และส่งผลลัพธ์กลับมา

ประโยชน์ของการใช้ MCP

สังเกตว่าแนวทางนี้ซ่อนรายละเอียดจำนวนมากไว้: client ไม่ได้จัดการ API keys หรือ HTTP status codes สิ่งเหล่านี้ถูกจัดการโดย MCP server

ประเด็นหลักคือความเรียบง่ายที่จุด integration: เรา “ขอ” ลูกค้า และเราได้รับลูกค้า ลอจิกของการดึงข้อมูลถูกห่อหุ้มไว้ที่อื่น นั่นหมายความว่านักพัฒนาที่ทำงานฝั่ง AI ไม่จำเป็นต้องเขียน HTTP calls ใหม่สำหรับการกระทำใหม่แต่ละอย่าง เพียงเรียกเครื่องมือตามชื่อ งานหนัก (auth, การเรียก endpoint ของ Google Drive, การจัดรูปแบบคำตอบ) ทำในโค้ดของ MCP server ซึ่งนำกลับมาใช้ซ้ำได้และเป็นมาตรฐาน

นี่คือสรุปประโยชน์หลัก:

• ลด glue code เฉพาะ API ก่อนมี MCP การทำให้ AI ใช้บริการภายนอกมักต้องเขียนโค้ด “glue” จำนวนมาก: เรียก API, แปลงคำตอบเป็นข้อความที่โมเดลเข้าใจได้ จากนั้น parse output ของโมเดลเพื่ออาจเรียก API อีกตัว เป็นต้น เมื่อใช้ MCP, glue จำนวนมากถูกตัดออก client ของโมเดลและเซิร์ฟเวอร์จัดการการแลกเปลี่ยนข้อมูลในแบบมีโครงสร้าง คุณจึงไม่ต้องแปลงรูปแบบอื่น (เช่น JSON) เป็นข้อความหรือกลับกันด้วยตนเอง โปรโตคอลทำให้ คุณยังไม่ต้องเขียนลอจิกเพื่อตัดสินใจว่าจะเรียกอะไรเมื่อใด AI (ที่ได้รับคำแนะนำจากคำอธิบายเครื่องมือและ reasoning หรือ prompt ของตัวเอง) เป็นฝ่ายทำ

• connector ที่ใช้ซ้ำและแชร์ได้ แทน API wrapper แบบทำครั้งเดียว เมื่อใช้ MCP คุณเขียน integration ครั้งเดียว และนำไปใช้ซ้ำได้ในหลายโปรเจกต์และระบบ AI ตัวอย่างเช่น คุณอาจสร้าง MCP server สำหรับ wiki ภายในของบริษัท แอป AI ใดก็ตามที่รองรับ MCP สามารถเชื่อมต่อกับเซิร์ฟเวอร์นั้นเพื่อ query wiki ได้ คุณไม่ต้อง implement “wiki search” ใหม่สำหรับ AI chatbot ตัวใหม่แต่ละตัวหรือผู้ให้บริการ LLM แต่ละราย การใช้ซ้ำได้นี้เป็นการเปลี่ยนจากอดีตที่แต่ละทีมอาจเขียน integration สำหรับ API เดียวกันในรูปแบบที่ต่างกันเล็กน้อย MCP ส่งเสริมให้มีคลัง connectors ที่แชร์และปรับปรุงร่วมกันได้

• การผสานแบบ plug-and-play กับ LLM ต่าง ๆ MCP ไม่ขึ้นกับโมเดล โปรโตคอลไม่สนใจว่า client เป็น Claude, GPT-4, DeepSeek หรือโมเดลในอนาคตใด ๆ ตราบใดที่ client จัดการ interface ของ MCP ได้ ในอนาคต หากคุณต้องการเปลี่ยนไปใช้โมเดลอื่น คุณทำได้โดยไม่ต้องเขียน integration ทั้งหมดใหม่

• บำรุงรักษาง่ายขึ้น เพราะเป็นมาตรฐานเปิด จึงมีชุมชนที่เติบโตและช่วยสร้างเซิร์ฟเวอร์สำเร็จรูป (สำหรับฐานข้อมูล, API ยอดนิยม ฯลฯ) ที่คุณนำมาใช้ได้แทนการสร้างจากศูนย์ เมื่อคุณผสานระบบมากขึ้น MCP ช่วยหลีกเลี่ยง “สปาเกตตี” ของ integration แบบ point-to-point จำนวนมาก และคุณไม่จำเป็นต้องติดตามการอัปเดต API ทั้งหมดจากผู้ให้บริการรายอื่น

API integrations จะล้าสมัยหรือไม่

ทั้ง API integrations แบบดั้งเดิมและ MCP ต่างมีที่ใช้งาน แนวทางที่ดีที่สุดขึ้นอยู่กับลักษณะของโปรเจกต์ ความเชี่ยวชาญของทีม และเป้าหมายระยะยาว

หากคุณต้องผสานกับบริการภายนอกเพียงหนึ่งหรือสองบริการ และการโต้ตอบค่อนข้างตรงไปตรงมา direct API integration มักเป็นวิธีที่เร็วที่สุด หากเว็บแอปของคุณเพียงต้องตรวจสอบ Stripe payment token ตอน checkout การเรียก Stripe API โดยตรงนั้นเรียบง่ายและได้ผล การนำ MCP เข้ามาในสถานการณ์นี้อาจเกินความจำเป็น คุณสามารถ เชื่อมต่อ AI Agent กับ REST API ใดก็ได้ที่มีเอกสาร ด้วย HTTP Action ที่ผ่านการตรวจสอบหนึ่งรายการ หรือใช้ integration แบบคลิกเดียว เช่น Google Sheets เพื่อบันทึก leads และ demo requests โดยไม่ต้องรัน MCP server

ในกรณีที่คุณต้องควบคุม request/response อย่างเข้มงวดมาก (เพื่อปรับแต่ง performance, จัดการข้อมูลแบบพิเศษ หรือใช้โปรโตคอล proprietary) การเขียนเข้าหา API โดยตรงอาจดีกว่า การผสานแบบดั้งเดิมเปิดให้คุณใช้ฟีเจอร์ขั้นสูงทั้งหมดของ API และปรับแต่งการเรียกได้อย่างแม่นยำ หาก API มีข้อกำหนดที่ไม่ปกติ หรือหากคุณต้องการหลีกเลี่ยง abstraction layer เพื่อความชัดเจนและการควบคุมสูงสุด แนวทางดั้งเดิมก็เหมาะสม

สำหรับตัวอย่างที่เป็นรูปธรรมว่าเครื่องมือ MCP ถูกเปิดเผยให้ AI Agent ที่ใช้งานจริงควบคู่กับ custom API actions อย่างไร ดูวิธีที่ Quickchat AI Agents รวมทั้งสองแนวทางเข้าด้วยกัน การอภิปรายเชิงลึกว่าเมื่อใดควรใช้ MCP, AI Actions แยกรายการ หรือ “Generate from Text” อยู่ใน APIs for AI Agents: From MCP to Custom Endpoints หากต้องการลองด้วยตัวเอง ให้ทำตามคู่มือทีละขั้นตอนเพื่อ เชื่อมต่อ AI Agent ของคุณกับ remote MCP server เพื่อให้เรียกเครื่องมือที่ทำงานจริงระหว่างบทสนทนาได้

รายชื่อ MCP servers ที่มีให้ใช้งาน

หากคุณต้องการเริ่มต้นกับ MCP ดูไดเรกทอรี MCP servers ด้านล่าง:

• https://github.com/modelcontextprotocol/servers
• https://smithery.ai

คุณยังสามารถรันได้โดยไม่ต้องเขียนโค้ด: Quickchat AI Agent ทุกตัวสามารถเปลี่ยนเป็น MCP server พร้อม hosted URL ที่ Claude, ChatGPT และ Cursor เรียกเป็นเครื่องมือได้ การเชื่อมต่อทำงานได้อีกทิศทางเช่นกัน: Quickchat AI Agent สามารถเรียก hosted MCP server ของผู้ให้บริการเป็นเครื่องมือของตน ซึ่งเป็นวิธีที่ AI scheduling assistant ที่สร้างบน Calendly’s MCP server ตรวจสอบ availability จริงและจองการประชุมจากแชต และเป็นวิธีที่ Notion AI chatbot ตอบจาก help center ที่มีข้อมูลสด และบันทึก support requests กลับเข้า Notion database

Quickchat AI ยังรัน remote MCP server สำหรับบัญชีของคุณเองด้วย เชื่อมต่อกับ ChatGPT, Claude, Cursor หรือ Codex แล้วคุณสามารถจัดการ AI Agents ของคุณจากที่นั่นได้: analytics, conversation transcripts, knowledge base updates และการสร้าง Agent ใหม่ ภายใต้การลงชื่อเข้าใช้ OAuth ครั้งเดียว ขั้นตอนการตั้งค่าสำหรับแต่ละ client อยู่ใน Manage Your AI Agent from ChatGPT, Claude, and Codex with MCP

FAQ

ทำงานได้เฉพาะกับ Claude เท่านั้นหรือไม่

MCP ไม่ขึ้นกับโมเดล โปรโตคอลไม่สนใจว่า client เป็น Claude, GPT-4, อนุพันธ์ของ LLaMA แบบ local หรือโมเดลในอนาคตใด ๆ ตราบใดที่ client จัดการ interface ของ MCP ได้ หมายความว่าคุณไม่ถูกผูกกับผู้ให้บริการ AI รายเดียวเมื่อสร้าง tool integrations ของคุณ

MCP ต่างจากการให้ข้อมูลทั้งหมดที่โมเดลต้องใช้ตั้งแต่ต้นอย่างไร ทำไมไม่ใส่ข้อมูลทั้งหมดลงใน prompt แทน

MCP แตกต่างโดยพื้นฐานจากการยัดข้อมูลลงใน prompt ของโมเดล เพราะมันทำให้โมเดลดึงข้อมูลแบบไดนามิกเมื่อจำเป็น แทนที่จะทำงานกับ prompt แบบคงที่ที่โหลดไว้ล่วงหน้า การยัดข้อความลงใน prompt จะเจอข้อจำกัด เพราะโมเดล AI มี context window ที่จำกัด หมายความว่าข้อมูลที่มากเกินไปอาจทำให้รายละเอียดสำคัญหายไป ทำให้การตอบช้าลง และเพิ่มค่าใช้จ่าย API (เพราะโมเดลคิดราคาตาม token ที่ผู้ให้บริการ LLM ใช้) นอกจากนี้ยังให้ความรู้ ณ เวลาใดเวลาหนึ่งเท่านั้น ในขณะที่ MCP เปิดให้เข้าถึงข้อมูลภายนอกแบบเรียลไทม์และ ให้ AI ลงมือทำสิ่งต่าง ๆ ได้ ไม่ใช่แค่อ่านข้อมูล AI ที่มี prompt เต็มแน่นอาจรู้รายละเอียดลูกค้า แต่จะไม่สามารถอัปเดตระเบียนหรือประมวลผลธุรกรรมได้

ถ้าเราเชื่อมต่อเครื่องมือ หลายสิบ ตัวกับ AI จะทำให้โมเดลสับสนหรือใช้ผิดหรือไม่

ขึ้นอยู่กับ implementation แต่เป็นความจริงที่ LLM ปัจจุบันมีข้อจำกัดในการแยกแยะและเลือกจากตัวเลือกจำนวนมาก หากคุณให้โมเดลเห็นเครื่องมือที่เป็นไปได้ เช่น 50 ตัว มีความเสี่ยงที่มันอาจเลือกตัวผิด แนวทาง MCP เองไม่ได้บังคับให้คุณโหลดทุกอย่างพร้อมกัน คุณควรเชื่อมต่อเครื่องมือที่เกี่ยวข้องตาม context แนวปฏิบัติที่ดีคือเชื่อมต่อเฉพาะเครื่องมือที่จำเป็นสำหรับงาน/โดเมนตรงหน้า และใช้ประโยชน์จาก multiagent collaboration ซึ่งเป็นลักษณะของ tool routing หรือ agent ที่ตัดสินใจก่อนว่าควรพิจารณา subset ของเครื่องมือใด

MCP เทียบกับ Function Calling

Function calling แบบดั้งเดิม (อย่างที่เห็นใน API ของ OpenAI หรือ LLM อื่น ๆ) เปิดให้นักพัฒนากำหนดชุดฟังก์ชัน ส่ง definition ให้โมเดล และให้โมเดล “เรียก” ตามชื่อพร้อมอาร์กิวเมนต์ นี่เป็นก้าวสำคัญสำหรับการผสาน AI แต่มีข้อจำกัด ความแตกต่างสำคัญอย่างหนึ่งคือเครื่องมือถูกกำหนดเมื่อใดและอย่างไร ใน function calling แบบคลาสสิก ฟังก์ชันที่เป็นไปได้ทั้งหมดต้องถูกประกาศล่วงหน้า (ตอน design time) ใน prompt หรือผ่าน API โมเดลสามารถ เรียกได้เฉพาะฟังก์ชันคงที่เหล่านั้น ใน MCP เครื่องมือค้นพบได้ขณะรันไทม์ AI สามารถ query ว่ามีอะไรให้ใช้ และแม้กระทั่งรับเครื่องมือใหม่ระหว่าง session ได้

MCP เทียบกับ GPT Actions & Plugins

GPT Actions/Plugins หมายถึงระบบนิเวศของ OpenAI ที่คุณสามารถเปิดใช้ plugins (เช่น เว็บเบราว์เซอร์ หรือ PDF reader) สำหรับ ChatGPT หรือ “GPTs” (custom ChatGPT agents) ที่สามารถใช้เครื่องมือได้ สิ่งเหล่านั้นน่าสนใจ แต่ต้องพัฒนาเฉพาะสำหรับแต่ละ plugin และจำกัดอยู่บนแพลตฟอร์มของ OpenAI หากคุณต้องการ ChatGPT plugin สำหรับงานหนึ่ง คุณต้องสร้าง API และ manifest และผ่านการอนุมัติของ OpenAI หรืออย่างน้อยต้องเปิดใช้ด้วยตนเอง แต่ละ plugin โดยพื้นฐานแล้วเป็น silo เช่น weather plugin, travel plugin ฯลฯ แต่ละตัวมี endpoint และลอจิกของตัวเอง MCP ปรับปรุงแนวคิดนี้โดยการ รวมให้เป็นหนึ่งเดียว และเปิดกว้างขึ้น

MCP เทียบกับ RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG) คือเทคนิคที่เสริม LLM ด้วย knowledge base ภายนอก โดยทั่วไป RAG เกี่ยวข้องกับ vector database หรือ search index: query ของผู้ใช้ถูกใช้เพื่อดึงเอกสารหรือข้อมูลที่เกี่ยวข้อง (ด้วย semantic search หรือวิธีอื่น) และเอกสารเหล่านั้นถูกส่งให้โมเดลเป็น context เพิ่มเติมเพื่อ “อ่าน” ขณะสร้างคำตอบ RAG เป็นเรื่องของการให้ความรู้ที่โมเดลไม่มีมาแต่เดิม โดยเฉพาะมีประโยชน์สำหรับ factual QA หรือข้อมูลเฉพาะโดเมน อย่างไรก็ตาม RAG เป็นแบบอ่านอย่างเดียว โมเดลดึงข้อความมาได้ แต่ไม่ได้ดำเนินการใด ๆ นอกเหนือจากการดึงข้อมูล

ในทางตรงกันข้าม MCP เป็นเรื่องของ การลงมือทำ หรือดำเนินการใด ๆ ตามต้องการ ไม่ใช่แค่ดึง context เชิงข้อมูล เมื่อใช้ MCP, AI สามารถ ทำ สิ่งต่าง ๆ ได้: เขียนลงฐานข้อมูล, ส่งอีเมล, execute code ฯลฯ มันไม่ได้จำกัดอยู่ที่การดึงความรู้ แต่สามารถ trigger การเปลี่ยนแปลงในระบบภายนอกได้ ดังนั้นในหลายแง่ RAG และ MCP จึงตอบโจทย์คนละวัตถุประสงค์กัน