โปรโตคอล Model Context Protocol ( MCP ) สัญญาว่าจะทำให้การเชื่อมต่อระหว่าง AI agents กับเครื่องมือภายนอกง่ายขึ้น แต่นักพัฒนากำลังแสดงความกังวลอย่างจริงจังเกี่ยวกับความปลอดภัยของระบบ authentication และการลดลงของประสิทธิภาพ แม้ว่า MCP จะได้รับความนิยมในฐานะวิธีมาตรฐานในการเปิดเผยเครื่องมือให้กับโมเดลภาษาขนาดใหญ่ แต่ความท้าทายในการนำไปใช้งานจริงทำให้บางคนตั้งคำถามถึงคุณค่าในทางปฏิบัติ
ส่วนประกอบของสถาปัตยกรรม MCP :
- Host Application: แอปแชทหรือ IDE (เช่น Cursor ) ที่มี MCP client
- MCP Client: จัดการการสื่อสารกับเซิร์ฟเวอร์ MCP
- MCP Server: เปิดเผยเครื่องมือ พรอมต์ ทรัพยากร หรือตัวอย่าง
- Communication Protocol: ใช้พื้นฐาน JSON-RPC พร้อมการยืนยันตัวตนและการค้นพบ
ปัญหา Authentication ที่น่าสะพรึงกลัวคุกคามการนำไปใช้ในองค์กร
หนึ่งในประเด็นเร่งด่วนที่สุดที่ MCP กำลังเผชิญคือระบบ authentication ที่เสียหาย นักพัฒนารายงานว่าการตั้งค่าการเชื่อมต่อที่ปลอดภัยมีความซับซ้อนและเปราะบางอย่างไม่จำเป็น โดยเฉพาะเมื่อเกี่ยวข้องกับ OAuth flows วิธีการปัจจุบันมักต้องการการจัดเก็บ authentication tokens แบบ plaintext ในตำแหน่งที่รู้จักกันดีบนเครื่องท้องถิ่น ซึ่งสร้างสิ่งที่นักพัฒนาที่ใส่ใจความปลอดภัยคนหนึ่งเรียกว่า ความฝันของ black hat
สำหรับผู้ใช้ระดับองค์กร ปัญหา authentication นั้นสร้างความยุ่งยากเป็นพิเศษ ทีมการตลาดที่ต้องการใช้ Google Analytics MCP servers ต้องเผชิญกับงานที่น่าหวาดกลัวในการจัดการการตั้งค่า Google Cloud และการแบ่งปัน service account credentials ซึ่งเป็นกระบวนการที่ซับซ้อนมากจนปิดกั้นผู้ใช้ที่ไม่ใช่ด้านเทคนิคจากการนำไปใช้งานได้อย่างมีประสิทธิภาพ
ปัญหาความยุ่งเหยิงของ authentication ทำให้เกิดการแตกแยกในชุมชน นักพัฒนาบางคนผลักดัน remote MCP servers ที่ทำงานใน isolated containers พร้อมการจัดการ identity ที่เหมาะสม ในขณะที่คนอื่นๆ ยึดติดกับการใช้งานแบบท้องถิ่นแม้จะมีความเสี่ยงด้านความปลอดภัย การแตกแยกนี้ทำลายเป้าหมายของ MCP ในการสร้างมาตรฐานสากล
ปัญหาหลักของ MCP ที่ระบุได้:
- การยืนยันตัวตน: โทเค็นแบบข้อความธรรมดาถูกเก็บไว้ในตำแหน่งที่รู้จักกันดี
- ประสิทธิภาพ: คำจำกัดความของเครื่องมือใช้พื้นที่ context window ที่มีค่า
- ความซับซ้อน: การตั้งค่า OAuth ต้องการความเชี่ยวชาญด้านเทคนิคสำหรับการใช้งานในองค์กร
- เครื่องมือล้นมือ: เครื่องมือที่มีให้ใช้มากเกินไปสามารถทำให้การตัดสินใจของ AI แย่ลง
- การค้นพบ: เครื่องมือทั้งหมดถูกเปิดเผยล่วงหน้าโดยไม่คำนึงถึงความเกี่ยวข้อง
เครื่องมือล้นหลามทำให้ประสิทธิภาพ AI ลดลง
การค้นพบที่น่าประหลาดใจในหมู่นักพัฒนา AI คือเครื่องมือที่มากขึ้นไม่ได้หมายความว่าประสิทธิภาพจะดีขึ้นเสมอไป เมื่อ agents เข้าถึงเครื่องมือหลายสิบหรือหลายร้อยตัวผ่าน MCP การตัดสินใจของพวกมันกลับแย่ลง ปัญหานี้เกิดจากข้อจำกัดของ context window โดยคำจำกัดความของเครื่องมือแต่ละตัวใช้พื้นที่อันมีค่าที่สามารถใช้สำหรับการสนทนาจริงหรือข้อมูลเฉพาะงาน
การทำให้เครื่องมือมากขึ้นพร้อมใช้งานสามารถให้ความสามารถมากขึ้นแก่ agent แต่ก็สามารถทำลายประสิทธิภาพได้อย่างง่ายดาย
การลดลงของประสิทธิภาพนี้บังคับให้นักพัฒนาต้องคัดสรรด้วยตนเองว่า agents ของพวกเขาสามารถเข้าถึงเครื่องมือใดได้บ้าง ซึ่งทำลายความสะดวกสบายที่ MCP สัญญาไว้ส่วนใหญ่ บางคนหันไปใช้ gateway solutions ที่กรองและจัดเรียงเครื่องมือก่อนนำเสนอให้กับ AI ซึ่งเพิ่มความซับซ้อนอีกชั้นหนึ่งให้กับสิ่งที่ควรจะเป็นโปรโตคอลที่ทำให้ง่ายขึ้น
กระบวนการค้นหาเครื่องมือใน MCP ก็มีส่วนทำให้เกิดปัญหาเช่นกัน เมื่อระบบ AI เชื่อมต่อกับ MCP server มันจะได้รับข้อมูลเกี่ยวกับเครื่องมือที่พร้อมใช้งานทั้งหมดล่วงหน้า โดยไม่คำนึงว่าเครื่องมือเหล่านั้นจะเกี่ยวข้องกับงานปัจจุบันหรือไม่ สิ่งนี้สร้างปัญหาอัตราส่วนสัญญาณต่อสัญญาณรบกวนที่ทำให้ความสามารถของ AI ในการมุ่งเน้นไปที่งานจริงลดลง
ชุมชนตั้งคำถามถึงข้อเสนอคุณค่าหลักของ MCP
นอกเหนือจากปัญหาทางเทคนิค นักพัฒนากำลังตั้งคำถามว่า MCP แก้ปัญหาจริงหรือไม่ หลายคนชี้ให้เห็นว่า REST APIs ที่มีอยู่แล้วพร้อมเอกสาร OpenAPI ให้การค้นหาเครื่องมือและอินเทอร์เฟซมาตรฐานอยู่แล้ว ชั้น MCP เพิ่มเติมดูเหมือนซ้ำซ้อนเมื่อโมเดล AI สามารถทำงานกับ JSON schemas และ HTTP endpoints ได้อยู่แล้ว
โมเดล local MCP server ที่นักพัฒนาดาวน์โหลดและรัน tool servers บนเครื่องของตน ดูน่าสงสัยเป็นพิเศษสำหรับหลายคน สำหรับฟังก์ชันง่ายๆ เช่น การรับวันที่ปัจจุบันหรือการเรียก API การ import package ของเครื่องมือดูตรงไปตรงมากว่าการรัน server process แยกต่างหาก
นักพัฒนาบางคนมอง MCP ในอนาคตในองค์กรขนาดใหญ่ที่ทีมต่างๆ ต้องการเปิดเผยความเชี่ยวชาญในโดเมนของตนให้กับระบบ AI ทั่วทั้งบริษัท ในสถานการณ์นี้ MCP สามารถให้การแยกความกังวลที่ช่วยให้ทีม backend เป็นเจ้าของคำจำกัดความเครื่องมือของตน ในขณะที่ทีม frontend สร้างอินเทอร์เฟซ AI อย่างไรก็ตาม กรณีการใช้งานระดับองค์กรนี้ยังคงเป็นเพียงทฤษฎีเป็นส่วนใหญ่
แนวทางทางเลือกที่กล่าวถึง:
- Direct REST APIs: การใช้ HTTP endpoints ที่มีอยู่แล้วพร้อมเอกสาร OpenAPI
- Package Imports: การรวมคำจำกัดความของเครื่องมือเป็นไลบรารีโค้ด
- Gateway Solutions: การกรองและจัดเรียงเครื่องมือก่อนที่ AI จะเข้าถึง
- Custom Implementations: การสร้างการเรียกใช้เครื่องมือโดยไม่ใช้มาตรฐาน MCP
 |
|---|
| การสำรวจความซับซ้อนและความซ้ำซ้อนของ Model Context Protocol ในการค้นหาเครื่องมือภายในระบบ AI |
เส้นทางข้างหน้ายังคงไม่ชัดเจน
แม้จะมีการวิพากษ์วิจารณ์ MCP ก็ไม่ได้ขาดผู้สนับสนุน ผู้สนับสนุนโต้แย้งว่าเหมือนกับ USB , MCP อาจพัฒนาไปเกินกว่ากรณีการใช้งานที่มุ่งเน้น AI ในตอนแรกเพื่อกลายเป็นโปรโตคอลการรวมระบบที่มีวัตถุประสงค์ทั่วไป รากฐาน JSON-RPC และกลไกการค้นหาที่มีอยู่แล้วสามารถทำให้มีประโยชน์สำหรับการสื่อสารระหว่างระบบต่อระบบแม้ไม่มี AI เข้าร่วม
ข้อได้เปรียบที่ใหญ่ที่สุดของโปรโตคอลอาจเป็นจังหวะเวลา ขณะที่การเรียกใช้เครื่องมือ AI กลายเป็นเรื่องธรรมดามากขึ้น การมีมาตรฐานใดๆ ก็ดีกว่าภูมิทัศน์ที่แตกแยกในปัจจุบันของการใช้งานแบบกำหนดเอง อย่างไรก็ตาม ปัญหา authentication และประสิทธิภาพต้องการการแก้ไขก่อนที่ MCP จะสามารถบรรลุการนำไปใช้ในองค์กรอย่างแพร่หลาย
ในตอนนี้ นักพัฒนาดูเหมือนจะใช้แนวทางรอดูก่อน ผู้ที่สร้างแอปพลิเคชัน AI แบบง่ายมักข้าม MCP ไปเลย ในขณะที่องค์กรขนาดใหญ่ทดลองกับ gateway solutions เพื่อจัดการกับข้อจำกัดปัจจุบัน ความสำเร็จของโปรโตคอลน่าจะขึ้นอยู่กับว่าปัญหาพื้นฐานเหล่านี้จะได้รับการแก้ไขในเวอร์ชันอนาคตหรือไม่