เซิร์ฟเวอร์ MCP คืออะไร MCP และ MCP UI ทำงานอย่างไรในปี 2026

เมื่อวันที่ 1 เมษายน 2025 Invariant Labs เผยแพร่เครื่องมือชื่อ add มันรับตัวเลขสองตัวแล้วคืนผลบวก แต่คำอธิบายของมันมีบล็อกที่ติดป้าย IMPORTANT แฝงอยู่ด้วย บล็อกนี้มองไม่เห็นในหน้าจอของไคลเอนต์ และสั่งให้โมเดลอ่านไฟล์ ~/.cursor/mcp.json กับ ~/.ssh/id_rsa แล้วส่งทั้งสองไฟล์ออกไปทางพารามิเตอร์ที่ไม่ได้ใช้ โมเดลทำตาม ผู้ใช้เห็นแค่การบวกเลข

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

เซิร์ฟเวอร์ MCP คืออะไร

เซิร์ฟเวอร์ MCP คือโปรแกรมที่เปิดเครื่องมือ ข้อมูล และพรอมต์ให้แอปพลิเคชัน AI ใช้งานผ่าน Model Context Protocol (MCP) เอกสารทางการ นิยาม MCP ว่าเป็น “มาตรฐานโอเพนซอร์สสำหรับเชื่อมต่อแอปพลิเคชัน AI กับระบบภายนอก” ไคลเอนต์ AI อย่าง Claude, ChatGPT, Visual Studio Code หรือ Cursor จะเชื่อมต่อกับเซิร์ฟเวอร์ ถามว่ามีอะไรให้ใช้บ้าง แล้วเรียกใช้ความสามารถเหล่านั้นแทนผู้ใช้

Anthropic ประกาศ MCP เมื่อวันที่ 25 พฤศจิกายน 2024 พร้อมเซิร์ฟเวอร์สำเร็จรูปหกตัว ได้แก่ Google Drive, Slack, GitHub, Git, Postgres และ Puppeteer OpenAI นำไปใช้ในเดือนมีนาคม 2025 และ Google DeepMind ตามมาในเดือนเมษายน ในเดือนธันวาคม 2025 Anthropic บริจาคโปรโตคอลนี้ให้ Agentic AI Foundation ซึ่งเป็นกองทุนเฉพาะทางภายใต้ Linux Foundation ที่ Anthropic, Block และ OpenAI ร่วมกันก่อตั้ง

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

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

เซิร์ฟเวอร์ MCP ทำงานอย่างไร

ข้อกำหนดปัจจุบัน เวอร์ชัน 2026-07-28 ใช้ข้อความ JSON-RPC 2.0 รับส่งระหว่างสามบทบาท คำอธิบายของข้อกำหนดเองยาวแค่สามบรรทัด โฮสต์คือ “แอปพลิเคชัน LLM ที่เริ่มการเชื่อมต่อ” ไคลเอนต์คือ “ตัวเชื่อมต่อภายในแอปพลิเคชันโฮสต์” และเซิร์ฟเวอร์คือ “บริการที่ให้บริบทและความสามารถ”

โฮสต์ ไคลเอนต์ และเซิร์ฟเวอร์

โฮสต์คือแอปพลิเคชันที่คุณพิมพ์ใส่ เช่น Claude Desktop, IDE หรือเอเจนต์ที่คุณสร้างเอง ภายในโฮสต์ ไคลเอนต์หนึ่งตัวทำงานต่อการเชื่อมต่อเซิร์ฟเวอร์หนึ่งรายการ เซิร์ฟเวอร์อยู่อีกฝั่งและคุยกับระบบจริง ไม่ว่าจะเป็นฐานข้อมูล Postgres, GitHub API หรือโฟลเดอร์ในดิสก์ของคุณ โฮสต์ตัดสินว่าโมเดลจะเห็นอะไรและผู้ใช้ต้องอนุมัติอะไร เซิร์ฟเวอร์ตัดสินว่าระบบเบื้องหลังจะทำอะไร

1. โฮสต์ Claude Desktop · IDE · เอเจนต์ของคุณเอง

   แสดงเครื่องมือให้โมเดล และขอความยินยอมจากผู้ใช้

2. ไคลเอนต์ หนึ่งตัวต่อการเชื่อมต่อเซิร์ฟเวอร์

   สื่อสารด้วย JSON-RPC ผ่าน stdio หรือ Streamable HTTP

3. เซิร์ฟเวอร์ MCP เครื่องมือ · ทรัพยากร · พรอมต์

   อธิบายสิ่งที่มีให้ และรันการเรียกใช้

4. ระบบเบื้องหลัง ฐานข้อมูล · SaaS API · ไฟล์ในเครื่อง

   ทำงานจริง

เครื่องมือ ทรัพยากร และพรอมต์

เซิร์ฟเวอร์มีของให้ได้สามประเภท

• เครื่องมือ คือฟังก์ชันที่โมเดลสั่งรันได้ เช่น create_issue, query_orders, send_email แต่ละตัวมีชื่อ คำอธิบาย และ JSON Schema สำหรับอินพุต
• ทรัพยากร คือบริบทและข้อมูลให้ผู้ใช้หรือโมเดลอ่าน เช่น ไฟล์ สคีมาฐานข้อมูล หรือเรคคอร์ด
• พรอมต์ คือข้อความและเวิร์กโฟลว์แบบเทมเพลตที่ผู้ใช้เลือกได้ เช่น “สรุป pull request นี้ให้หน่อย”

เครื่องมือได้รับความสนใจมากที่สุดเพราะมันลงมือทำจริง นั่นก็เป็นเหตุผลเดียวกันที่มันแบกความเสี่ยงไว้เกือบทั้งหมด

การเรียกใช้เครื่องมือทีละขั้น

ฉบับแก้ไข 2026-07-28 ทำให้ MCP ไม่เก็บสถานะ (stateless) ไม่มีการจับมือ initialize อีกต่อไป ทุกคำขอจะพกเวอร์ชันโปรโตคอลและความสามารถของไคลเอนต์ไว้ในฟิลด์ _meta และเซิร์ฟเวอร์ต้องมีเมธอด server/discover เพื่อให้ไคลเอนต์ถามได้ตั้งแต่ต้นว่าเซิร์ฟเวอร์รองรับอะไร ตอนนี้การเรียกใช้เครื่องมือหนึ่งครั้งเป็นแบบนี้

1. ผู้ใช้ขอว่า: สร้างทิกเก็ตสำหรับบั๊กนี้

2. ขั้นที่ 1

   ค้นหา

   • ไคลเอนต์อาจเรียก server/discover เพื่อดูเวอร์ชันและความสามารถ
3. ขั้นที่ 2

   แสดงรายการเครื่องมือ

   • tools/list คืนชื่อ คำอธิบาย และสคีมาอินพุต
4. ขั้นที่ 3

   โมเดลเลือกเครื่องมือ

   • โฮสต์ส่งนิยามเครื่องมือให้โมเดล
5. ขั้นที่ 4

   ความยินยอมของผู้ใช้

   • ข้อกำหนดระบุว่าโฮสต์ต้องได้รับความยินยอมชัดเจนก่อนเรียกใช้เครื่องมือใด ๆ
6. ขั้นที่ 5

   เรียกใช้

   • tools/call พร้อมอาร์กิวเมนต์ และเวอร์ชันโปรโตคอลใน _meta

7. ถ้าข้อมูลไม่ครบ เซิร์ฟเวอร์จะคืน input_required แล้วไคลเอนต์ลองใหม่พร้อมคำตอบ

   ขั้นที่ 6

   ผลลัพธ์

8. ผลลัพธ์กลับไปหาโมเดลในฐานะบริบท

ขั้นที่ 6 เป็นของใหม่ในฉบับแก้ไขนี้ เซิร์ฟเวอร์ที่ต้องการข้อมูลเพิ่มจะไม่ส่งคำขอของตัวเองย้อนกลับไปหาไคลเอนต์อีกแล้ว แต่จะคืนผลลัพธ์ที่ทำเครื่องหมาย input_required จากนั้นไคลเอนต์รวบรวมคำตอบแล้วลองเรียกครั้งเดิมใหม่ ข้อกำหนดเรียกสิ่งนี้ว่ารูปแบบ Multi Round-Trip Request

ช่องทางรับส่ง: stdio และ Streamable HTTP

ข้อกำหนดนิยามช่องทางรับส่งมาตรฐานไว้สองแบบ

• stdio: ไคลเอนต์เปิดเซิร์ฟเวอร์เป็นโปรเซสย่อย แล้วรับส่ง JSON-RPC ที่คั่นด้วยการขึ้นบรรทัดใหม่ผ่านอินพุตและเอาต์พุตมาตรฐาน เซิร์ฟเวอร์ภายในเครื่องส่วนใหญ่ทำงานแบบนี้ ซึ่งหมายความว่าเซิร์ฟเวอร์รันอยู่บนเครื่องของคุณด้วยสิทธิ์ของคุณ
• Streamable HTTP: ทุกข้อความคือ HTTP POST ไปยังเอนด์พอยต์เดียว และคำตอบกลับมาเป็นออบเจกต์ JSON หรือสตรีมเหตุการณ์ที่ผูกกับคำขอนั้น เซิร์ฟเวอร์ระยะไกลที่โฮสต์ไว้ทำงานแบบนี้

ช่องทาง HTTP+SSE แบบเก่าถูกเลิกสนับสนุนอย่างเป็นทางการแล้ว ฉบับแก้ไข 2026-07-28 ยังถอดเซสชันระดับโปรโตคอลและเฮดเดอร์ Mcp-Session-Id ออกด้วย เซิร์ฟเวอร์ที่ต้องเก็บสถานะข้ามการเรียกต้องสร้างแฮนเดิลของตัวเอง แล้วรับแฮนเดิลนั้นกลับมาเป็นอาร์กิวเมนต์เครื่องมือธรรมดา

การอนุญาตสิทธิ์

การอนุญาตสิทธิ์ใน MCP เป็นทางเลือก และใช้กับ HTTP เท่านั้น สำหรับ stdio ข้อกำหนดบอกว่าเซิร์ฟเวอร์ควรดึงข้อมูลรับรองจากสภาพแวดล้อมแทน สำหรับ HTTP เซิร์ฟเวอร์ MCP ที่มีการป้องกันจะทำหน้าที่เป็นเซิร์ฟเวอร์ทรัพยากรของ OAuth 2.1 มันต้องเผยแพร่ OAuth Protected Resource Metadata (RFC 9728) เพื่อให้ไคลเอนต์หาเซิร์ฟเวอร์อนุญาตสิทธิ์ของมันเจอ ไคลเอนต์ต้องระบุให้ชัดว่าโทเค็นออกให้เซิร์ฟเวอร์ตัวไหน (ตัวบ่งชี้ทรัพยากรตาม RFC 8707) เซิร์ฟเวอร์ต้องปฏิเสธโทเค็นทุกตัวที่ไม่ได้ออกให้ตัวเอง และแนวทางด้านความปลอดภัยระบุชัดว่า “token passthrough” หรือการส่งต่อโทเค็นของไคลเอนต์ไปยัง API ปลายทางโดยไม่แก้ไข เป็นสิ่งต้องห้าม

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

สิ่งที่ MCP UI เพิ่มเข้ามา: เซิร์ฟเวอร์ที่ส่งอินเทอร์เฟซกลับมา

คำตอบแบบข้อความใช้ไม่ได้ทันทีที่ผู้ใช้ต้องเปรียบเทียบสี่สิบแถว ปรับฟอร์มที่มีสิบสองช่อง หรืออนุมัติชุดการเปลี่ยนแปลงทีละรายการ “MCP UI” คือชื่อที่คนใช้ค้นหาทางแก้ เซิร์ฟเวอร์ส่งอินเทอร์เฟซแบบโต้ตอบได้กลับมา และอินเทอร์เฟซนั้นแสดงผลภายในไคลเอนต์ AI ข้างบทสนทนา

ควรอธิบายสถานะให้ตรง จุดเริ่มต้นคือ MCP-UI ซึ่งเป็นโครงการชุมชน OpenAI สร้างกลไกคล้ายกันใน Apps SDK โครงการ MCP เสนอมาตรฐานร่วมกับทั้งสองฝ่ายเมื่อ 21 พฤศจิกายน 2025 และเผยแพร่ MCP Apps เมื่อ 26 มกราคม 2026 ในฐานะส่วนขยาย MCP อย่างเป็นทางการรายการแรก แพ็กเกจ MCP-UI ใช้มาตรฐานนี้แล้วและยังเป็นพื้นที่ทดลองการปรับปรุงต่อไปของชุมชน

ดังนั้น MCP UI ในวันนี้ก็คือ MCP Apps มันเป็นของทางการ และเป็นส่วนขยาย ไม่ใช่โปรโตคอลหลัก ส่วนขยายต้องเลือกเปิดใช้เอง ทั้งไคลเอนต์และเซิร์ฟเวอร์ต้องรองรับ และเอกสารก็บอกตรง ๆ ว่า “การรองรับของโฮสต์ต่างกันไปตามไคลเอนต์” เอกสาร MCP Apps ระบุโฮสต์ที่รองรับไว้ ได้แก่ Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam และ Archestra.AI เซิร์ฟเวอร์ที่เครื่องมือส่ง UI กลับมา ยังต้องใช้งานได้กับไคลเอนต์ที่แสดงแค่ข้อความ

ในเชิงกลไก มันนำชิ้นส่วนของ MCP เองกลับมาใช้

1. คำอธิบายของเครื่องมือมี _meta.ui.resourceUri ที่ชี้ไปยังทรัพยากร ui://
2. โฮสต์ดึงทรัพยากรนั้นมา ซึ่งก็คือหน้า HTML พร้อมสคริปต์ และโหลดล่วงหน้าได้ก่อนที่จะมีการเรียกเครื่องมือ
3. โฮสต์แสดงผลมันใน iframe แบบแซนด์บ็อกซ์ ที่อ่านหน้าแม่ คุกกี้ หรือพื้นที่จัดเก็บของหน้าแม่ไม่ได้
4. แอปกับโฮสต์คุยกันผ่าน postMessage ด้วย JSON-RPC สำเนียงหนึ่งของ MCP แอปขอให้เรียกเครื่องมือได้ และโฮสต์เป็นผู้ตัดสินว่าจะอนุญาตอันไหน

ต้นทุนมีอยู่จริง ตอนนี้คุณกำลังส่งฟรอนต์เอนด์เว็บไปทำงานในแอปพลิเคชันของคนอื่น ต้องประกาศนโยบายความปลอดภัยของเนื้อหาเอง ต้องยอมรับกฎการแสดงผลที่คุณควบคุมไม่ได้ และต้องมีข้อความสำรองสำหรับทุกโฮสต์ที่ไม่สนใจ UI ผลตอบแทนคืองานอนุมัติไม่ต้องเป็นบันทึกแชตอีกต่อไป รายการงานที่เหมาะสมซึ่งเอกสารยกมาเองปิดท้ายด้วย “การอนุมัติรายงานค่าใช้จ่าย การรีวิวการเปลี่ยนแปลงโค้ด หรือการคัดแยกปัญหา” นี่คือแก่นที่ตรงไปตรงมาของมัน MCP UI เก่งที่สุดเรื่องการตัดสินใจ ไม่ใช่การตกแต่ง

ตัวอย่าง Tajo แบบอ่านอย่างเดียว

ส่วน Alto MCP ของ Tajo มี query_contacts สำหรับค้นหารายชื่อผู้ติดต่อที่เก็บในพื้นที่ทำงานที่เชื่อมต่อ ค้นหาผู้ติดต่อเดิมหนึ่งรายด้วยอีเมล แล้วตรวจ ID สถานะความยินยอมทางอีเมล และเวลาที่พบล่าสุด เครื่องมือแยก get_contact_topic_status อ่านการสมัครตามหัวข้อของรายนั้น

ทั้งหมดเป็นการอ่านจากพื้นที่ทำงาน ไม่ได้ดึงข้อมูลล่าสุดจากผู้ให้บริการ เริ่มซิงก์ หรือส่งข้อความ และไม่พิสูจน์ว่าตัวเชื่อมต่อของทุกผู้ให้บริการทำงาน หากข้อมูลขาดหรือเก่าให้ตรวจที่ต้นทาง ผลลัพธ์ว่างไม่ได้พิสูจน์ว่าบุคคลนั้นไม่มีใน Brevo

ใช้เอกสาร Tajo MCP เชื่อมต่อไคลเอนต์ที่รองรับและดูเครื่องมือที่พื้นที่ทำงานซึ่งได้รับสิทธิ์เปิดให้ใช้จริง แผงโต้ตอบช่วยตรวจทานได้เมื่อโฮสต์รองรับ MCP Apps แต่ผลลัพธ์ข้อความยังต้องอธิบายสิ่งที่เกิดขึ้น

การเรียกเครื่องมือไม่ใช่การซิงก์ที่ต่อเนื่อง

การซิงก์เป็นประจำยังต้องมีตารางเวลา อัตลักษณ์ระเบียนที่คงที่ ความคืบหน้าที่บันทึกไว้ การตัดสินใจลองซ้ำ และบันทึกการเขียนที่เสร็จแล้ว สิ่งเหล่านี้เป็นหน้าที่ของแอปที่รันงาน MCP กำหนดมาตรฐานการเข้าถึงเครื่องมือ แต่การมีรายชื่อเครื่องมือไม่สร้างกฎธุรกิจเหล่านี้

หลังหมดเวลา การอ่านมักลองซ้ำได้ แต่การส่งหรือจ่ายเงินอาจเกิดขึ้นแล้ว เก็บบันทึกการรันและตรวจผลก่อนลองอีกครั้ง ความมั่นใจของโมเดลไม่ได้ให้อนุญาตหรือทำให้การลองซ้ำปลอดภัย

การเขียนผู้ติดต่อไปปลายทางดูได้ในคู่มือ Brevo API ส่วนเมื่อใดฟิลด์ที่คำนวณควรมีการซิงก์แยกที่ดูแลต่อเนื่อง ดูreverse ETL

บิลค่าความปลอดภัยมาพร้อมกับโปรโตคอล

ข้อโต้แย้งนี้ควรถูกยกมาให้ครบ “MCP ยื่นรายการฟังก์ชันที่ลบข้อมูลและส่งอีเมลได้ให้โมเดลที่ทำงานด้วยความน่าจะเป็น แล้วเชื่อข้อความที่คนแปลกหน้าเขียนมาเพื่ออธิบายฟังก์ชันเหล่านั้น นี่ไม่ใช่มาตรฐานการเชื่อมต่อ มันคือการโจมตีซัพพลายเชนที่มีข้อกำหนดกำกับ” ส่วนใหญ่ถูกต้อง ข้อกำหนดเองก็เห็นด้วยกับหลักตั้งต้นนี้ หัวข้อความปลอดภัยของมันบอกว่าเครื่องมือ “เทียบเท่าการรันโค้ดใดก็ได้ และต้องจัดการด้วยความระมัดระวังที่เหมาะสม” บอกว่าคำอธิบายเครื่องมือ “ควรถือว่าไม่น่าเชื่อถือ เว้นแต่ได้มาจากเซิร์ฟเวอร์ที่เชื่อถือได้” และบอกว่า MCP “ไม่สามารถบังคับใช้หลักความปลอดภัยเหล่านี้ในระดับโปรโตคอลได้”

นี่คือบันทึกที่ผ่านมา

• Tool poisoning (การวางยาพิษในเครื่องมือ) การเปิดเผยของ Invariant Labs เมื่อเดือนเมษายน 2025 คือเครื่องมือ add ข้างต้น โพสต์เดียวกันยังอธิบาย rug pull ซึ่งเซิร์ฟเวอร์เปลี่ยนคำอธิบายเครื่องมือหลังจากคุณอนุมัติไปแล้ว และ shadowing ซึ่งเซิร์ฟเวอร์ประสงค์ร้ายตัวหนึ่งเขียนพฤติกรรมของโมเดลที่มีต่อเซิร์ฟเวอร์อีกตัวที่เชื่อถือได้ใหม่
• เซิร์ฟเวอร์ในเครื่องถูกเจาะ ในเดือนกรกฎาคม 2025 JFrog เปิดเผย CVE-2025-6514 ใน mcp-remote เวอร์ชัน 0.0.5 ถึง 0.1.15 ซึ่งทำให้เซิร์ฟเวอร์ประสงค์ร้ายรันคำสั่งบนเครื่องของผู้ใช้ได้ ในฤดูร้อนเดียวกัน CVE-2025-49596 ก็กระทบ MCP Inspector ของ Anthropic เอง ซึ่งเผยแพร่ออกมาโดยไม่มีการยืนยันตัวตนเป็นค่าเริ่มต้น
• ขอบเขตสิทธิ์บวมเกินจำเป็น แนวปฏิบัติด้านความปลอดภัยที่ดีที่สุดฉบับทางการระบุรูปแบบนี้ไว้ตรง ๆ คือโทเค็นที่ได้สิทธิ์ files:* หรือ admin:* ตั้งแต่ต้น เพราะเซิร์ฟเวอร์แสดงขอบเขตทุกตัว และไคลเอนต์ก็ขอไปทั้งหมด
• ความกังวลจากหน่วยงานรัฐ ในเดือนพฤษภาคม 2026 สำนักงานความมั่นคงแห่งชาติของสหรัฐฯ (NSA) ระบุว่า “การแพร่กระจายอย่างรวดเร็ว” ของ MCP “ได้แซงหน้าการพัฒนาโมเดลความปลอดภัยของมัน”

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

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

โปรโตคอลทำให้กล่องเป็นมาตรฐานแล้ว การตรวจสินค้าข้างในยังเป็นหน้าที่ของคุณ

สร้างเซิร์ฟเวอร์ MCP เอง หรือใช้ของที่มีอยู่

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

เอเจนต์ของคุณควรใช้เซิร์ฟเวอร์ MCP ตัวไหน

1. ผู้ให้บริการเผยแพร่เซิร์ฟเวอร์ที่ครอบคลุมงานนี้

   ใช้เซิร์ฟเวอร์ของผู้ให้บริการ

   มันตามทัน API และผู้ให้บริการดูแลให้

2. ระบบเดียว แต่ต้องการการกระทำที่น้อยลงหรือปลอดภัยขึ้น

   ใช้ แต่จำกัดขอบเขต

   ให้สิทธิ์น้อยที่สุด และเปิดเฉพาะกลุ่มเครื่องมือที่เอเจนต์ต้องใช้

3. ข้อมูลภายใน หรือระบบที่ไม่มีเซิร์ฟเวอร์

   สร้างเซิร์ฟเวอร์ขนาดเล็ก

   เครื่องมือไม่กี่ตัวที่ตรงกับงาน บน API ของคุณเอง ด้วยระบบยืนยันตัวตนของคุณเอง

4. งานครอบคลุมสองระบบขึ้นไป

   สร้างหรือใช้เลเยอร์ที่มีการกำกับดูแล

   เครื่องมือชุดเดียว กฎความยินยอม และประวัติการตรวจสอบที่ครอบคลุมทุกระบบ

การสร้างเซิร์ฟเวอร์พื้นฐานคือส่วนที่ง่าย ด้วย SDK ทางการ เซิร์ฟเวอร์ stdio ที่ใช้งานได้พร้อมเครื่องมือหนึ่งตัวใช้เวลาแค่บ่ายเดียว ต้นทุนมาทีหลัง ทั้ง OAuth สำหรับเวอร์ชัน HTTP การรับมือกับการเลิกสนับสนุน (ฉบับแก้ไข 2026-07-28 เลิกสนับสนุน Roots, Sampling และ Logging รวมถึง Dynamic Client Registration) และงานต่อเนื่องในการเขียนคำอธิบายเครื่องมือที่โมเดลอ่านได้ถูกต้อง ความผิดพลาดที่พบบ่อยที่สุดคือการห่อ API แบบหนึ่งเอนด์พอยต์ต่อหนึ่งเครื่องมือ คำอธิบายเครื่องมือทุกตัวคือข้อความที่โมเดลต้องอ่านและชั่งน้ำหนัก รายการเครื่องมือสั้น ๆ ที่ตรงกับงานจึงดีกว่า API ทั้งหมด

MCP, API, การเชื่อมต่อ และ iPaaS

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

ความต่างนี้ขีดเส้นแบ่งได้ชัดระหว่าง MCP กับอีกสองอย่างที่คนมักสับสน

• การเชื่อมต่อและ iPaaS (เปรียบเทียบแพลตฟอร์มหลักไว้ที่นี่) ย้ายข้อมูลตามกำหนดเวลาหรือทริกเกอร์อย่างแน่นอนตายตัว ไม่ว่าจะมีใครอยู่ในแชตหรือไม่ การซิงค์คำสั่งซื้อ 40,000 รายการเข้า CRM ทุกคืนไม่ควรขึ้นอยู่กับว่าโมเดลตัดสินใจเรียกเครื่องมือ 40,000 ครั้งหรือไม่
• Reverse ETL ส่งข้อมูลที่ผ่านการจัดโมเดลแล้วจากคลังข้อมูลกลับเข้าเครื่องมือที่ใช้ทำงาน Reverse ETL คืออะไรและเหมาะกับงานแบบไหน เป็นอีกหัวข้อหนึ่ง และมันคือไปป์ไลน์ ไม่ใช่บทสนทนา
• MCP มีไว้สำหรับช่วงเวลาที่คนหรือเอเจนต์ต้องถาม ตรวจดู หรือสั่งงานข้ามระบบเหล่านั้นตามต้องการ

ความผิดพลาดเกิดได้ทั้งสองทาง บางทีมสร้างเซิร์ฟเวอร์ MCP เพื่อซิงค์ข้อมูลจำนวนมาก แล้วได้ไปป์ไลน์ที่ช้า แพง และทำซ้ำให้ได้ผลเดิมไม่ได้ อีกบางทีมสร้างการเชื่อมต่ออย่างพิถีพิถัน แล้วยื่น API key ดิบให้ผู้ช่วย AI ไปคิวรี จนได้ประตูหลังที่ไม่มีใครกำกับดูแล

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

ภายใน 22 เดือน MCP เติบโตจากเซิร์ฟเวอร์อ้างอิงหกตัวมาเป็นโปรเจกต์ของ Linux Foundation ที่ Claude, ChatGPT, VS Code และ Cursor ใช้สื่อสารกันได้ทั้งหมด การเชื่อมโมเดลเข้ากับระบบตอนนี้กลายเป็นส่วนที่ถูกแล้ว การตัดสินว่ามันได้รับอนุญาตให้ทำอะไรที่นั่นต่างหากคืองานจริง