MCP: ปฏิวัติการโต้ตอบเครื่องมือของ AI Agent

ความท้าทายของการรวม AI-Tool แบบดั้งเดิม

ก่อนการเกิดขึ้นของ MCP, LLMs อาศัยการรวมเฉพาะกิจและเฉพาะเจาะจงกับโมเดลเพื่อเข้าถึงเครื่องมือภายนอก แนวทางเช่น ReAct, Toolformer, LangChain and LlamaIndex และ Auto-GPT แม้ว่าจะเป็นนวัตกรรมใหม่ แต่นำไปสู่ฐานรหัสที่กระจัดกระจายและบำรุงรักษายาก แหล่งข้อมูลใหม่หรือ API แต่ละแห่งต้องมี wrapper ของตัวเอง และ agent จะต้องได้รับการฝึกฝนโดยเฉพาะเพื่อใช้งาน แนวทางนี้กำหนดเวิร์กโฟลว์ที่แยกจากกันซึ่งไม่ได้มาตรฐาน โดยเน้นถึงความจำเป็นในการมีโซลูชันที่เป็นหนึ่งเดียว

• การรวมเฉพาะกิจ: โดยทั่วไป LLMs จะใช้การรวมแบบกำหนดเองและเฉพาะเจาะจงกับโมเดลเพื่อเข้าถึงเครื่องมือภายนอก
• ฐานรหัสที่กระจัดกระจาย: แหล่งข้อมูลใหม่หรือ API แต่ละแห่งจำเป็นต้องมี wrapper ของตัวเอง ส่งผลให้โค้ดมีความซับซ้อนและบำรุงรักษายาก
• เวิร์กโฟลว์ที่ไม่ได้มาตรฐาน: เวิร์กโฟลว์ที่แยกจากกันทำให้ยากต่อการบรรลุการรวมที่ราบรื่นในโมเดลและเครื่องมือต่างๆ

ขอแนะนำ Model Context Protocol (MCP)

Model Context Protocol (MCP) สร้างมาตรฐานวิธีที่ AI agent ค้นพบและเรียกใช้เครื่องมือภายนอกและแหล่งข้อมูล MCP เป็นโปรโตคอลเปิดที่กำหนดเลเยอร์ API ที่ใช้ JSON-RPC ทั่วไประหว่างโฮสต์ LLM และเซิร์ฟเวอร์ MCP ทำหน้าที่เป็น "พอร์ต USB-C สำหรับแอปพลิเคชัน AI" โดยมีอินเทอร์เฟซสากลที่โมเดลใดๆ ก็สามารถใช้เพื่อเข้าถึงเครื่องมือได้ ซึ่งจะช่วยให้มีการเชื่อมต่อที่ปลอดภัยแบบสองทางระหว่างแหล่งข้อมูลขององค์กรและเครื่องมือที่ขับเคลื่อนด้วย AI แทนที่ตัวเชื่อมต่อแบบค่อยเป็นค่อยไปในอดีต

ข้อดีที่สำคัญของ MCP

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

แทนที่จะเขียนพรอมต์เฉพาะโมเดลหรือการเรียกใช้ฟังก์ชันที่ฮาร์ดโค้ด agent เพียงแค่เชื่อมต่อกับเซิร์ฟเวอร์ MCP หนึ่งเครื่องขึ้นไป ซึ่งแต่ละเครื่องจะเปิดเผยข้อมูลหรือความสามารถในลักษณะที่เป็นมาตรฐาน Agent (หรือโฮสต์) จะดึงรายการเครื่องมือที่มีอยู่ รวมถึงชื่อ คำอธิบาย และสคีมาอินพุต/เอาต์พุตจากเซิร์ฟเวอร์ จากนั้นโมเดลสามารถเรียกใช้เครื่องมือใดก็ได้ตามชื่อ การสร้างมาตรฐานและการนำกลับมาใช้ใหม่นี้เป็นข้อได้เปรียบหลักเหนือแนวทางก่อนหน้า

บทบาทหลักที่กำหนดโดย MCP

ข้อกำหนดเปิดของ MCP กำหนดบทบาทหลักสามประการ: โฮสต์ ไคลเอนต์ และเซิร์ฟเวอร์

1. โฮสต์: แอปพลิเคชัน LLM หรือส่วนติดต่อผู้ใช้ (เช่น UI แชท, IDE หรือเอ็นจินการจัดระเบียบ agent) ที่ผู้ใช้โต้ตอบด้วย โฮสต์ฝัง LLM และทำหน้าที่เป็นไคลเอนต์ MCP
2. ไคลเอนต์: โมดูลซอฟต์แวร์ภายในโฮสต์ที่ใช้โปรโตคอล MCP (โดยทั่วไปผ่าน SDK) ไคลเอนต์จัดการการส่งข้อความ การรับรองความถูกต้อง และการจัดเรียงพรอมต์และตอบสนองของโมเดล
3. เซิร์ฟเวอร์: บริการ (โลคัลหรือรีโมต) ที่ให้บริบทและเครื่องมือ เซิร์ฟเวอร์ MCP แต่ละเครื่องอาจห่อหุ้มฐานข้อมูล, API, ฐานรหัส หรือระบบอื่นๆ และโฆษณาความสามารถให้กับไคลเอนต์

MCP ได้รับแรงบันดาลใจอย่างชัดเจนจาก Language Server Protocol (LSP) ที่ใช้ใน IDEs: เช่นเดียวกับที่ LSP สร้างมาตรฐานวิธีที่เอดิเตอร์สืบค้นคุณสมบัติภาษา MCP สร้างมาตรฐานวิธีที่ LLMs สืบค้นเครื่องมือตามบริบท การใช้รูปแบบข้อความ JSON-RPC 2.0 ทั่วไป ทำให้ไคลเอนต์และเซิร์ฟเวอร์ใดๆ ที่ปฏิบัติตาม MCP สามารถทำงานร่วมกันได้ โดยไม่คำนึงถึงภาษาโปรแกรมหรือ LLM ที่ใช้

การออกแบบทางเทคนิคและสถาปัตยกรรม

MCP อาศัย JSON-RPC 2.0 เพื่อส่งข้อความสามประเภท: คำขอ, การตอบสนอง และการแจ้งเตือน ทำให้ agents สามารถทำการเรียกใช้เครื่องมือแบบซิงโครนัสและรับการอัปเดตแบบอะซิงโครนัส ในการใช้งานในเครื่อง ไคลเอนต์มักจะสร้างกระบวนการย่อยและสื่อสารผ่าน stdin/stdout (การขนส่ง stdio) ในทางตรงกันข้าม เซิร์ฟเวอร์ระยะไกลโดยทั่วไปจะใช้ HTTP กับ Server-Sent Events (SSE) เพื่อสตรีมข้อความในแบบเรียลไทม์ เลเยอร์การส่งข้อความที่ยืดหยุ่นนี้ทำให้มั่นใจได้ว่าเครื่องมือสามารถถูกเรียกใช้และส่งมอบผลลัพธ์ได้โดยไม่ปิดกั้นเวิร์กโฟลว์หลักของแอปพลิเคชันโฮสต์

ทุกเซิร์ฟเวอร์เปิดเผยเอนทิตีที่เป็นมาตรฐานสามรายการ: ทรัพยากร, เครื่องมือ และพรอมต์

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

การจัดเตรียมสคีมา JSON สำหรับแต่ละเอนทิตี ทำให้ large language model (LLM) ที่มีความสามารถใดๆ สามารถตีความและเรียกใช้ความสามารถเหล่านี้ได้โดยไม่จำเป็นต้องมีการแยกวิเคราะห์แบบกำหนดเองหรือการรวมที่ฮาร์ดโค้ด

การออกแบบแบบโมดูลาร์

สถาปัตยกรรม MCP แยกข้อกังวลอย่างหมดจดในสามบทบาท โฮสต์ฝัง LLM และจัดระเบียบการไหลของการสนทนา โดยส่งแบบสอบถามของผู้ใช้ไปยังโมเดลและจัดการผลลัพธ์ ไคลเอนต์ใช้โปรโตคอล MCP เอง จัดการการจัดเรียงข้อความ การรับรองความถูกต้อง และรายละเอียดการขนส่งทั้งหมด เซิร์ฟเวอร์โฆษณาทรัพยากรและเครื่องมือที่มีอยู่ ดำเนินการตามคำขอที่เข้ามา (เช่น การแสดงรายการเครื่องมือหรือการดำเนินการแบบสอบถาม) และส่งคืนผลลัพธ์ที่มีโครงสร้าง การออกแบบแบบโมดูลาร์นี้ ซึ่งครอบคลุม AI และ UI ในโฮสต์ ตรรกะโปรโตคอลในไคลเอนต์ และการดำเนินการในเซิร์ฟเวอร์ ทำให้มั่นใจได้ว่าระบบยังคงบำรุงรักษาได้ ขยายได้ และง่ายต่อการพัฒนา

รูปแบบการโต้ตอบและเวิร์กโฟลว์ของ Agent

การใช้ MCP ใน agent เป็นไปตามรูปแบบที่เรียบง่ายของการค้นพบและการดำเนินการ เมื่อ agent เชื่อมต่อกับเซิร์ฟเวอร์ MCP ก่อนอื่น agent จะเรียกเมธอด list_tools() เพื่อดึงเครื่องมือและทรัพยากรที่มีอยู่ทั้งหมด จากนั้นไคลเอนต์จะรวมคำอธิบายเหล่านี้เข้ากับบริบทของ LLM (เช่น โดยการจัดรูปแบบเป็นพรอมต์) ตอนนี้โมเดลรู้ว่าเครื่องมือเหล่านี้มีอยู่และพารามิเตอร์ที่ใช้

เวิร์กโฟลว์ที่เรียบง่าย

1. การค้นพบ: Agent เชื่อมต่อกับเซิร์ฟเวอร์ MCP และดึงรายการเครื่องมือและทรัพยากรที่มีอยู่โดยใช้เมธอด list_tools()
2. การรวม: ไคลเอนต์รวมคำอธิบายเหล่านี้เข้ากับบริบทของ LLM
3. การดำเนินการ: เมื่อ agent ตัดสินใจที่จะใช้เครื่องมือ LLM จะปล่อยการเรียกที่มีโครงสร้าง (เช่น วัตถุ JSON ที่มี call: tool_name, args: {...})
4. การเรียกใช้: โฮสต์รับรู้ว่าเป็นการเรียกใช้เครื่องมือ และไคลเอนต์ออกคำขอ call_tool() ที่สอดคล้องกันไปยังเซิร์ฟเวอร์
5. การตอบสนอง: เซิร์ฟเวอร์ดำเนินการเครื่องมือและส่งผลลัพธ์กลับมา จากนั้นไคลเอนต์จะป้อนผลลัพธ์นี้ลงในพรอมต์ถัดไปของโมเดล ทำให้ปรากฏเป็นบริบทเพิ่มเติม

เมื่อ agent ตัดสินใจที่จะใช้เครื่องมือ (มักจะได้รับแจ้งจากแบบสอบถามของผู้ใช้) LLM จะปล่อยการเรียกที่มีโครงสร้าง (เช่น วัตถุ JSON ที่มี \"call\": \"tool_name\", \"args\": {…}) โฮสต์รับรู้ว่าเป็นการเรียกใช้เครื่องมือ และไคลเอนต์ออกคำขอ call_tool() ที่สอดคล้องกันไปยังเซิร์ฟเวอร์ เซิร์ฟเวอร์ดำเนินการเครื่องมือและส่งผลลัพธ์กลับมา จากนั้นไคลเอนต์จะป้อนผลลัพธ์นี้ลงในพรอมต์ถัดไปของโมเดล ทำให้ปรากฏเป็นบริบทเพิ่มเติม โปรโตคอลนี้จัดการวงจรของการค้นพบ→พรอมต์→เครื่องมือ→ตอบสนองอย่างโปร่งใส

การใช้งานและระบบนิเวศ

MCP ไม่ขึ้นกับการใช้งาน ข้อกำหนดอย่างเป็นทางการได้รับการดูแลบน GitHub และมี SDK หลายภาษา รวมถึง TypeScript, Python, Java, Kotlin และ C# นักพัฒนาสามารถเขียนไคลเอนต์หรือเซิร์ฟเวอร์ MCP ในสแต็กที่ต้องการได้ ตัวอย่างเช่น OpenAI Agents SDK มีคลาสที่ช่วยให้เชื่อมต่อกับเซิร์ฟเวอร์ MCP มาตรฐานจาก Python ได้อย่างง่ายดาย บทช่วยสอนของ InfraCloud สาธิตการตั้งค่าเซิร์ฟเวอร์ MCP ระบบไฟล์ที่ใช้ Node.js เพื่อให้ LLM สามารถเรียกดูไฟล์ในเครื่องได้

ระบบนิเวศที่กำลังเติบโต

• SDK ภาษา: มีใน TypeScript, Python, Java, Kotlin และ C#
• เซิร์ฟเวอร์โอเพนซอร์ส: Anthropic ได้เปิดตัวตัวเชื่อมต่อสำหรับบริการยอดนิยมมากมาย รวมถึง Google Drive, Slack, GitHub, Postgres, MongoDB และการท่องเว็บด้วย Puppeteer และอื่นๆ
• แพลตฟอร์มแบบบูรณาการ: Claude Desktop, Google’s Agent Development Kit และ Cloudflare’s Agents SDK ได้รวมการสนับสนุน MCP
• Auto-Agents: Auto-GPT สามารถเสียบเข้ากับ MCP ทำให้สามารถค้นพบและใช้เครื่องมือแบบไดนามิกได้

เมื่อทีมหนึ่งสร้างเซิร์ฟเวอร์สำหรับ Jira หรือ Salesforce แล้ว agent ที่สอดคล้องใดๆ ก็สามารถใช้งานได้โดยไม่ต้องแก้ไข ในด้านไคลเอนต์/โฮสต์ แพลตฟอร์ม agent จำนวนมากได้รวมการสนับสนุน MCP Claude Desktop สามารถแนบกับเซิร์ฟเวอร์ MCP ได้ Google’s Agent Development Kit ถือว่าเซิร์ฟเวอร์ MCP เป็นผู้ให้บริการเครื่องมือสำหรับโมเดล Gemini Cloudflare’s Agents SDK ได้เพิ่มคลาส McpAgent เพื่อให้ FogLAMP ใดๆ สามารถเป็นไคลเอนต์ MCP พร้อมการสนับสนุนการตรวจสอบสิทธิ์ในตัว แม้แต่ auto-agents เช่น Auto-GPT ก็สามารถเสียบเข้ากับ MCP ได้: แทนที่จะเขียนฟังก์ชันเฉพาะสำหรับแต่ละ API agent จะใช้ไลบรารีไคลเอนต์ MCP เพื่อเรียกใช้เครื่องมือ แนวโน้มไปสู่ตัวเชื่อมต่อสากลนี้ให้คำมั่นสัญญาว่าสถาปัตยกรรม agent อัตโนมัติแบบโมดูลาร์มากขึ้น

ในทางปฏิบัติ ระบบนิเวศนี้ช่วยให้ผู้ช่วย AI ใดๆ สามารถเชื่อมต่อกับแหล่งข้อมูลหลายแหล่งพร้อมกันได้ เราสามารถจินตนาการถึง agent ที่ในการประชุมหนึ่งใช้เซิร์ฟเวอร์ MCP สำหรับเอกสารองค์กร อีกเครื่องหนึ่งสำหรับแบบสอบถาม CRM และอีกเครื่องหนึ่งสำหรับการค้นหาไฟล์ในอุปกรณ์ MCP ยังจัดการกับการชนกันของชื่ออย่างสง่างาม: หากเซิร์ฟเวอร์สองเครื่องมีเครื่องมือที่เรียกว่า ‘วิเคราะห์’ ไคลเอนต์สามารถตั้งชื่อได้ (เช่น ‘ImageServer.analyze’ เทียบกับ ‘CodeServer.analyze’) เพื่อให้ทั้งสองยังคงใช้งานได้โดยไม่มีข้อขัดแย้ง

ข้อดีเหนือกระบวนทัศน์ก่อนหน้า

MCP นำมาซึ่งข้อดีหลักหลายประการที่วิธีเดิมขาด:

• การรวมที่เป็นมาตรฐาน: MCP มีโปรโตคอลเดียวสำหรับเครื่องมือทั้งหมด
• การค้นพบเครื่องมือแบบไดนามิก: Agents สามารถค้นพบเครื่องมือได้ในรันไทม์
• การทำงานร่วมกันและการนำกลับมาใช้ใหม่: เซิร์ฟเวอร์เครื่องมือเดียวกันสามารถให้บริการไคลเอนต์ LLM หลายรายได้
• ความสามารถในการปรับขนาดและการบำรุงรักษา: MCP ช่วยลดงานที่ซ้ำซ้อนลงได้อย่างมาก
• ระบบนิเวศที่ประกอบได้: MCP ช่วยให้ตลาดของเซิร์ฟเวอร์ที่พัฒนาขึ้นอย่างอิสระ
• ความปลอดภัยและการควบคุม: โปรโตคอลรองรับการไหลของการอนุญาตที่ชัดเจน

ข้อดีที่สำคัญโดยสรุป

• โปรโตคอลที่เป็นหนึ่งเดียว: MCP นำเสนอโปรโตคอลที่เป็นมาตรฐานเดียวสำหรับเครื่องมือทั้งหมด ปรับปรุงการพัฒนาและขจัดความจำเป็นในการใช้ตรรกะการแยกวิเคราะห์แบบกำหนดเอง
• การค้นพบรันไทม์: Agents สามารถค้นพบความสามารถที่มีอยู่แบบไดนามิก ขจัดความจำเป็นในการรีสตาร์ทหรือตั้งโปรแกรมใหม่เมื่อมีการเพิ่มเครื่องมือใหม่
• Model Agnostic: MCP ช่วยให้เซิร์ฟเวอร์เครื่องมือเดียวกันสามารถให้บริการไคลเอนต์ LLM หลายราย หลีกเลี่ยงการล็อกอินของผู้ขายและลดความพยายามทางวิศวกรรมที่ซ้ำซ้อน
• ลดความซ้ำซ้อน: นักพัฒนาสามารถเขียนเซิร์ฟเวอร์ MCP เดียวสำหรับงานต่างๆ เช่น การค้นหาไฟล์ ซึ่งเป็นประโยชน์ต่อ agents ทั้งหมดในทุกรุ่น
• ระบบนิเวศแบบเปิด: MCP ส่งเสริมตลาดตัวเชื่อมต่อแบบเปิด เช่นเดียวกับ Web API
• การไหลของการอนุญาต: MCP รองรับการไหลของการอนุญาตที่ชัดเจน ปรับปรุงการตรวจสอบและรักษาความปลอดภัยเมื่อเทียบกับการแจ้งเตือนแบบอิสระ

ผลกระทบต่ออุตสาหกรรมและการใช้งานจริง

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

กรณีการใช้งานที่เป็นรูปธรรม

• เครื่องมือสำหรับนักพัฒนา: โปรแกรมแก้ไขโค้ดและแพลตฟอร์มการค้นหาใช้ MCP เพื่อให้ผู้ช่วยสามารถสืบค้นที่เก็บโค้ด เอกสาร และประวัติการ commit
• ความรู้ขององค์กรและแชทบอท: บอท Helpdesk สามารถเข้าถึงข้อมูล Zendesk หรือ SAP ผ่านเซิร์ฟเวอร์ MCP ตอบคำถามเกี่ยวกับตั๋วที่เปิดอยู่ หรือสร้างรายงานตามข้อมูลองค์กรแบบเรียลไทม์
• การสร้างที่ได้รับการปรับปรุงด้วยการดึงข้อมูล: Agents RAG สามารถรวมการดึงข้อมูลตามการฝังเข้ากับเครื่องมือ MCP เฉพาะสำหรับการสืบค้นฐานข้อมูลหรือการค้นหากราฟ
• ผู้ช่วยเชิงรุก: Agents ที่ขับเคลื่อนด้วยเหตุการณ์จะตรวจสอบอีเมลหรือสตรีมงาน และกำหนดเวลากำหนดการประชุมหรือสรุปรายการดำเนินการโดยอัตโนมัติ โดยเรียกใช้เครื่องมือปฏิทินและจดบันทึกผ่าน MCP

ในแต่ละสถานการณ์ MCP ช่วยให้ agents สามารถปรับขนาดในระบบที่หลากหลายได้โดยไม่ต้องเขียนโค้ดการรวมใหม่ มอบโซลูชัน AI ที่บำรุงรักษาได้ ปลอดภัย และทำงานร่วมกันได้

การเปรียบเทียบกับกระบวนทัศน์ก่อนหน้า

MCP รวมและขยายแนวทางก่อนหน้า โดยนำเสนอการค้นพบแบบไดนามิก สคีมาที่เป็นมาตรฐาน และการทำงานร่วมกันข้ามโมเดลในโปรโตคอลเดียว

• เทียบกับ ReAct: MCP มีอินเทอร์เฟซที่เป็นทางการให้กับโมเดลโดยใช้สคีมา JSON ช่วยให้ไคลเอนต์สามารถจัดการการดำเนินการได้อย่างราบรื่น
• เทียบกับ Toolformer: MCP ทำให้เครื่องมือภายนอกเชื่อมต่อกับโมเดลได้อย่างสมบูรณ์ ช่วยให้รองรับเครื่องมือที่ลงทะเบียนใดๆ ได้แบบศูนย์ช็อตโดยไม่ต้องฝึกอบรมใหม่
• เทียบกับไลบรารีเฟรมเวิร์ก: MCP เปลี่ยนตรรกะการรวมเข้าสู่โปรโตคอลที่นำกลับมาใช้ใหม่ได้ ทำให้ agents มีความยืดหยุ่นมากขึ้นและลดการทำซ้ำโค้ด
• เทียบกับ Autonomous Agents: การใช้ไคลเอนต์ MCP ทำให้ agents ดังกล่าวไม่จำเป็นต้องมีโค้ดแบบกำหนดเองสำหรับบริการใหม่ แต่จะอาศัยการค้นพบแบบไดนามิกและการเรียก JSON-RPC แทน
• เทียบกับ API การเรียกใช้ฟังก์ชัน: MCP ทั่วไปจะเรียกใช้ฟังก์ชันในไคลเอนต์และเซิร์ฟเวอร์ใดๆ โดยรองรับการสตรีม การค้นพบ และบริการแบบมัลติเพล็กซ์

ข้อจำกัดและความท้าทาย

แม้ว่าจะมีแนวโน้มที่ดี แต่ MCP ยังคงอยู่ในช่วงพัฒนา:

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