Model Context Protocol ( MCP ) ได้เปิดตัวการอัปเดตข้อกำหนดเวอร์ชันใหญ่ที่ยกเลิกการสนับสนุนการรวมกลุ่ม JSON-RPC พร้อมกับนำเสนอการปรับปรุงด้านความปลอดภัยและฟังก์ชันใหม่ที่สำคัญ การปรับปรุงครั้งนี้ถือเป็นหนึ่งในการเปลี่ยนแปลงที่สำคัญที่สุดของโปรโตคอลนี้นับตั้งแต่เริ่มต้น ทำให้เกิดการถกเถียงในชุมชนนักพัฒนาเกี่ยวกับความซับซ้อนและคุณค่าเชิงปฏิบัติของโปรโตคอลนี้
การยกเลิก JSON-RPC Batching ทำให้นักพัฒนาผิดหวัง
การยกเลิกการรวมกลุ่ม JSON-RPC ได้รับปฏิกิริยาที่หลากหลายจากชุมชน ฟีเจอร์นี้ช่วยให้นักพัฒนาสามารถรวมคำขอหลายรายการเข้าด้วยกันและประมวลผลเป็นการดำเนินการเดียว ซึ่งหลายคนพบว่าสวยงามแม้จะมีการใช้งานจริงที่จำกัด การยกเลิกนี้สะท้อนให้เห็นถึงการมุ่งเน้นของผู้ดูแลโปรโตคอลในการทำให้ข้อกำหนดง่ายขึ้น แม้ว่านักพัฒนาบางคนจะแสดงความคิดถึงสิ่งที่พวกเขาถือว่าเป็นความสามารถทางเทคนิคที่น่าสนใจ
การปรับปรุงด้านความปลอดภัยครั้งใหญ่ด้วยการรวม OAuth
การอัปเดตได้นำเสนอมาตรการรักษาความปลอดภัย OAuth อย่างครอบคลุมโดยการจำแนก MCP servers เป็น OAuth Resource Servers การเปลี่ยนแปลงนี้ต้องการให้ MCP clients ใช้งาน Resource Indicators ตามที่ระบุใน RFC 8707 เพื่อป้องกันไม่ให้เซิร์ฟเวอร์ที่เป็นอันตรายได้รับโทเค็นการเข้าถึงที่ไม่ได้รับอนุญาต ข้อกำหนดตอนนี้รวมถึงการพิจารณาด้านความปลอดภัยที่เพิ่มขึ้นและเอกสารแนวทางปฏิบัติที่ดีที่สุด เพื่อจัดการกับความกังวลที่เพิ่มขึ้นเกี่ยวกับโมเดลความปลอดภัยของโปรโตคอลในสภาพแวดล้อมการผลิต
*RFC 8707: มาตรฐานทางเทคนิคที่กำหนดวิธีการระบุทรัพยากรที่โทเค็นการเข้าถึงมีไว้สำหรับ ช่วยป้องกันการใช้โทเค็นในทางที่ผิด
ฟีเจอร์ใหม่ขยายความสามารถของโปรโตคอล
ฟีเจอร์ใหม่หลายอย่างได้ถูกเพิ่มเข้ามาเพื่อเพิ่มประสิทธิภาพการทำงานของโปรโตคอล การสนับสนุนผลลัพธ์เครื่องมือที่มีโครงสร้างช่วยให้การแลกเปลี่ยนข้อมูลมีการจัดระเบียบมากขึ้น ในขณะที่ elicitation ช่วยให้เซิร์ฟเวอร์สามารถขอข้อมูลเพิ่มเติมจากผู้ใช้ในระหว่างการโต้ตอบ ลิงก์ทรัพยากรในผลลัพธ์การเรียกใช้เครื่องมือให้การเชื่อมต่อที่ดีขึ้นระหว่างส่วนประกอบต่างๆ ของระบบ
การเปลี่ยนแปลงสำคัญในการอัปเดตข้อกำหนด MCP
ฟีเจอร์ที่ถูกลบออก:
- การสนับสนุน JSON-RPC batching
ฟีเจอร์ด้านความปลอดภัยใหม่:
- การจำแนกประเภท OAuth Resource Server สำหรับเซิร์ฟเวอร์ MCP
- ข้อกำหนดการใช้งาน Resource Indicators ( RFC 8707 )
- เอกสารข้อพิจารณาด้านความปลอดภัยที่ปรับปรุงแล้ว
- หน้าแนวทางปฏิบัติที่ดีด้านความปลอดภัยใหม่
ฟังก์ชันการทำงานใหม่:
- การสนับสนุนผลลัพธ์เครื่องมือที่มีโครงสร้าง
- Elicitation สำหรับการขอข้อมูลเพิ่มเติมจากผู้ใช้
- ลิงก์ทรัพยากรในผลลัพธ์การเรียกใช้เครื่องมือ
- ข้อกำหนด MCP-Protocol-Version header สำหรับคำขอ HTTP
การเปลี่ยนแปลง Schema:
- เพิ่มฟิลด์
_metaให้กับประเภทอินเทอร์เฟซเพิ่มเติม - เพิ่มฟิลด์
contextให้กับCompletionRequest - ฟิลด์
titleสำหรับชื่อที่แสดงผลแบบเป็นมิตรต่อมนุษย์ - Lifecycle Operation เปลี่ยนจาก SHOULD เป็น MUST
ชุมชนตั้งคำถามเกี่ยวกับคุณค่าพื้นฐานของโปรโตคอล
แม้จะมีการปรับปรุงเหล่านี้ แต่ชุมชนนักพัฒนายังคงแบ่งแยกเกี่ยวกับข้อเสนอคุณค่าหลักของ MCP นักวิจารณ์โต้แย้งว่าโปรโตคอลนี้เพิ่มความซับซ้อนที่ไม่จำเป็นเมื่อเปรียบเทียบกับการเรียก RPC แบบดั้งเดิมหรือการรวม API โดยตรง นักพัฒนาแบ็กเอนด์โดยเฉพาะตั้งคำถามเกี่ยวกับการตัดสินใจทางสถาปัตยกรรมที่ต้องการเซิร์ฟเวอร์แยกสำหรับแต่ละ API โดยมองว่าอาจสร้างไมโครเซอร์วิสหลายร้อยตัวในขณะที่การเรียกใช้ฟังก์ชันที่ง่ายกว่าก็เพียงพอแล้ว
หนึ่งในบทเรียนที่ใหญ่ที่สุดสำหรับฉันขณะที่ติดตาม MCP hype คือถ้าคุณกำลังเขียนซอฟต์แวร์แบ็กเอนด์ คุณไม่จำเป็นต้องใช้ MCP จริงๆ ในแง่สถาปัตยกรรม พวกมันไม่สมเหตุสมผล
ผู้สนับสนุนโต้แย้งว่า MCP ให้วิธีมาตรฐานในการแนบเครื่องมือกับ AI agents โดยไม่ต้องเสียค่า API โดยเฉพาะอย่างยิ่งเป็นประโยชน์สำหรับผู้ใช้ Claude พวกเขาเน้นคุณค่าของมันในฐานะระบบการรวมแบบ plug-and-play สำหรับสภาพแวดล้อมที่ไม่ใช่ทุกคนสามารถหรือได้รับอนุญาตให้เขียนโค้ดโดยตรงกับทรัพยากร
ความท้าทายด้านความเป็นผู้ใหญ่และการยอมรับของโปรโตคอล
ความเร็วของการเปลี่ยนแปลงข้อกำหนดทำให้เกิดคำถามเกี่ยวกับความเป็นผู้ใหญ่และความเสถียรของโปรโตคอล ในขณะที่นักพัฒนาบางคนชื่นชมการปรับปรุงอย่างต่อเนื่องและการตอบสนองต่อข้อเสนอแนะของชุมชน คนอื่นๆ กังวลเกี่ยวกับภาระการบำรุงรักษาในการรักษา MCP servers หลายตัวให้อัปเดตกับการปรับปรุงข้อกำหนดแต่ละครั้ง การพึ่งพา TypeScript ของโปรโตคอลสำหรับข้อกำหนดหลัก แทนที่จะเป็นรูปแบบเอกสาร API แบบดั้งเดิมเช่น OpenAPI ก็ดึงดูดความสนใจในฐานะตัวเลือกที่ไม่เป็นไปตามธรรมเนียม
การถกเถียงสะท้อนให้เห็นคำถามที่กว้างขึ้นเกี่ยวกับการมาตรฐานในระบบนิเวศเครื่องมือ AI และว่าโปรโตคอลที่มีอยู่อาจให้บริการวัตถุประสงค์ที่คล้ายกันด้วยความซับซ้อนที่น้อยกว่าหรือไม่ ขณะที่ MCP ยังคงพัฒนาต่อไป การยอมรับของมันน่าจะขึ้นอยู่กับว่าประโยชน์ของการมาตรฐานจะมีน้ำหนักมากกว่าต้นทุนความซับซ้อนที่รับรู้สำหรับแอปพลิเคชันประเภทต่างๆ หรือไม่
อ้างอิง: Key Changes