ชุมชนเทคโนโลยีกำลังถกเถียงกันอย่างจริงจังว่า Model Context Protocol ( MCP ) นั้นจำเป็นจริงหรือไม่ โดยนักพัฒนาชี้ไปที่โซลูชันที่มีอยู่แล้วและทางเลือกใหม่ที่อาจตอบโจทย์เดียวกันได้อย่างมีประสิทธิภาพมากกว่า
MCP ได้รับการออกแบบมาเพื่อช่วยให้โมเดลภาษาขนาดใหญ่สามารถโต้ตอบกับระบบซอฟต์แวร์ภายนอกได้ โดยการจัดเตรียมวิธีมาตรฐานในการกำหนดทรัพยากร พรอมต์ และเครื่องมือต่างๆ อย่างไรก็ตาม การอภิปรายล่าสุดเผยให้เห็นความสงสัยที่เพิ่มขึ้นว่าโปรโตคอลใหม่นี้เพิ่มคุณค่าที่มีความหมายเหนือมาตรฐานที่มีอยู่แล้วอย่าง OpenAPI , gRPC และ command-line interfaces หรือไม่
ส่วนประกอบหลักของ MCP :
- Resources: ข้อมูลที่มีลักษณะคล้ายไฟล์ที่สามารถอ่านได้โดยไคลเอนต์ (การตอบสนองจาก API เนื้อหาของไฟล์)
- Tools: ฟังก์ชันที่สามารถเรียกใช้ได้โดย LLMs ด้วยการอนุมัติจากผู้ใช้
- Prompts: เทมเพลตที่เขียนไว้ล่วงหน้าสำหรับงานเฉพาะ
ความสำเร็จในการนำไปใช้ปกปิดปัญหาที่แท้จริง
การนำโปรโตคอลนี้ไปใช้อย่างรวดเร็วเกิดขึ้นส่วนใหญ่จากแนวทางการใช้งานจริงที่เป็นประโยชน์ นักพัฒนาสามารถสร้าง MCP servers ในเครื่องที่ทำหน้าที่เป็นตัวกลางรอบ APIs ที่มีอยู่แล้วได้อย่างรวดเร็วโดยไม่ต้องแก้ไขโครงสร้างพื้นฐานที่มีอยู่ ลักษณะ plug-and-play นี้ทำให้ MCP น่าสนใจสำหรับสภาพแวดล้อมองค์กรที่บริการภายในมักขาดเอกสารที่เหมาะสม
อย่างไรก็ตาม เมื่อบริษัทต่างๆ เริ่มปฏิบัติต่อ MCP เป็นมาตรฐาน remote API คำถามก็เกิดขึ้นว่าทำไมพวกเขาไม่ใช้โปรโตคอลที่มีอยู่แล้วซึ่งได้รับการปรับปรุงให้เหมาะสมสำหรับการใช้งาน AI แทน
การขาดมาตรฐานสร้างปัญหาใหม่
ความกังวลสำคัญที่เกิดขึ้นจากการอภิปรายของนักพัฒนาคือการขาดรูปแบบคำอธิบายมาตรฐานของ MCP ไม่เหมือนกับ REST APIs ที่สามารถอธิบายได้อย่างครบถ้วนในไฟล์ OpenAPI JSON เดียว MCP servers ไม่สามารถจัดหมวดหมู่หรือแลกเปลี่ยนผ่านข้อมูลเมตาที่เป็นมาตรฐานได้อย่างง่ายดาย สิ่งนี้สร้างความซับซ้อนที่ไม่จำเป็นเมื่อสร้างไดเรกทอรีเครื่องมือหรือแบ่งปันการกำหนดค่าเซิร์ฟเวอร์
ข้อโต้แย้งเรื่องความยาวเยิ่นต่อ OpenAPI ก็ดูอ่อนแอสำหรับนักพัฒนาหลายคน พวกเขาเสนอว่าข้อกำหนดที่มีอยู่แล้วสามารถปรับปรุงให้เหมาะสมสำหรับกรณีการใช้งาน AI โดยอาจใช้ overlay specifications หรือแปลงเป็นรูปแบบที่กะทัดรัดกว่าที่ออกแบบมาเฉพาะสำหรับการใช้งานของโมเดลภาษา
โซลูชันทางเลือกได้รับความสนใจ
การอภิปรายในชุมชนเน้นย้ำ UTCP.io เป็นทางเลือกที่มีศักยภาพในการแก้ไขข้อบกพร่องหลายประการของ MCP มาตรฐานใหม่นี้ดูเหมือนจะได้รับการออกแบบมาเพื่อแก้ปัญหาเดียวกันที่ MCP เผชิญ แต่มีการพิจารณาโปรโตคอลที่มีอยู่แล้วและความต้องการมาตรฐานได้ดีกว่า
นักพัฒนาบางคนกำลังหาทางแก้ไขข้อจำกัดของ MCP โดยใช้มันเป็นหลักสำหรับเอกสารประกอบ ขณะที่ดำเนินการเรียกใช้เครื่องมือจริงผ่านคำสั่ง CLI แบบดั้งเดิมหรือ APIs มาตรฐาน แนวทางผสมผสานนี้ชี้ให้เห็นว่าข้อเสนอคุณค่าหลักของ MCP อาจเป็นที่น่าสงสัย
โปรโตคอลทางเลือกที่กล่าวถึง:
- OpenAPI: มาตรฐานการระบุ REST API ที่ได้รับการยอมรับ
- gRPC: เฟรมเวิร์กสำหรับการเรียกใช้ขั้นตอนระยะไกลของ Google
- CLI: อินเทอร์เฟซบรรทัดคำสั่งที่ LLM สามารถจัดการได้อย่างมีประสิทธิภาพ
- UTCP.io: ทางเลือกใหม่ที่กำลังเกิดขึ้นสำหรับโปรโตคอล MCP
ควรมุ่งเน้นไปที่คุณภาพของเครื่องมือจริงๆ
บางทีแทนที่จะโต้เถียงกันเรื่อง MCP vs CLI เราควรเริ่มสร้างเครื่องมือที่ดีกว่า โปรโตคอลเป็นเพียงระบบประปา สิ่งที่สำคัญคือเครื่องมือของคุณช่วยหรือขัดขวางความสามารถของ agent ในการทำงานให้เสร็จสิ้น
การถกเถียงในท้ายที่สุดมุ่งเน้นไปที่ว่าระบบนิเวศ AI ต้องการโปรโตคอลอีกตัวหนึ่งหรือไม่ ในขณะที่มาตรฐานที่มีอยู่แล้วช่วยให้โมเดลภาษาโต้ตอบกับระบบภายนอกได้อย่างมีประสิทธิภาพอยู่แล้ว แม้ว่า MCP อาจให้การปรับปรุงเล็กน้อยในประสิทธิภาพ context window ความเกี่ยวข้องในระยะยาวยังคงไม่แน่นอนเนื่องจากโมเดลภาษายังคงพัฒนาอย่างรวดเร็วต่อไป
ฉันทามติของชุมชนดูเหมือนจะเปลี่ยนไปสู่การใช้ประโยชน์จากโปรโตคอลที่มีอยู่แล้วและมีชื่เสียงที่ดี ขณะเดียวกันก็มุ่งเน้นความพยายามในการพัฒนาไปที่การสร้างเครื่องมือและเอกสารที่ดีกว่า แทนที่จะเป็นมาตรฐานการสื่อสารใหม่