Model Context Protocol Menghapuskan JSON-RPC Batching Sambil Menambah Keselamatan OAuth dan Output Alat Berstruktur

Model Context Protocol ( MCP ) telah mengeluarkan kemas kini spesifikasi utama yang menghapuskan sokongan JSON-RPC batching sambil memperkenalkan peningkatan keselamatan yang ketara dan fungsi baharu. Semakan ini mewakili salah satu perubahan paling besar kepada protokol sejak ia diperkenalkan, mencetuskan perdebatan dalam komuniti pembangun mengenai kerumitan protokol dan nilai praktikal.

Penghapusan JSON-RPC Batching Mengecewakan Pembangun

Penghapusan JSON-RPC batching telah menimbulkan reaksi bercampur-campur daripada komuniti. Ciri ini membolehkan pembangun menggabungkan berbilang permintaan bersama-sama dan memprosesnya sebagai satu operasi, yang mana ramai mendapati elegan walaupun penggunaan praktikalnya terhad. Penghapusan ini mencerminkan tumpuan penyelenggara protokol untuk memudahkan spesifikasi, walaupun sesetengah pembangun menyatakan nostalgia terhadap apa yang mereka anggap sebagai keupayaan teknikal yang menarik.

Baik Pulih Keselamatan Utama dengan Integrasi OAuth

Kemas kini ini memperkenalkan langkah keselamatan OAuth yang komprehensif dengan mengklasifikasikan pelayan MCP sebagai OAuth Resource Servers. Perubahan ini memerlukan klien MCP melaksanakan Resource Indicators seperti yang dinyatakan dalam RFC 8707 untuk menghalang pelayan berniat jahat daripada mendapatkan token akses tanpa kebenaran. Spesifikasi kini termasuk pertimbangan keselamatan yang dipertingkat dan dokumentasi amalan terbaik, menangani kebimbangan yang semakin meningkat mengenai model keselamatan protokol dalam persekitaran pengeluaran.

*RFC 8707: Standard teknikal yang mentakrifkan cara menentukan sumber mana token akses dimaksudkan, membantu mencegah penyalahgunaan token.

Ciri Baharu Mengembangkan Keupayaan Protokol

Beberapa ciri baharu telah ditambah untuk meningkatkan fungsi protokol. Sokongan output alat berstruktur membolehkan pertukaran data yang lebih teratur, manakala elicitation membolehkan pelayan meminta maklumat tambahan daripada pengguna semasa interaksi. Pautan sumber dalam hasil panggilan alat menyediakan sambungan yang lebih baik antara komponen sistem yang berbeza.

Perubahan Utama dalam Kemaskini Spesifikasi MCP

Ciri-ciri yang Dibuang:

• Sokongan kumpulan JSON-RPC

Ciri-ciri Keselamatan Baharu:

• Klasifikasi OAuth Resource Server untuk pelayan MCP
• Keperluan pelaksanaan Resource Indicators ( RFC 8707 )
• Dokumentasi pertimbangan keselamatan yang dipertingkat
• Halaman amalan terbaik keselamatan yang baharu

Fungsi Baharu:

• Sokongan output alat berstruktur
• Elicitation untuk meminta maklumat pengguna tambahan
• Pautan sumber dalam hasil panggilan alat
• Keperluan header MCP-Protocol-Version untuk permintaan HTTP

Perubahan Skema:

• Medan _meta ditambah kepada jenis antara muka tambahan
• Medan context ditambah kepada CompletionRequest
• Medan title untuk nama paparan mesra pengguna
• Lifecycle Operation ditukar daripada SHOULD kepada MUST

Komuniti Mempersoalkan Nilai Asas Protokol

Walaupun terdapat penambahbaikan ini, komuniti pembangun kekal berpecah mengenai cadangan nilai teras MCP . Pengkritik berhujah bahawa protokol menambah kerumitan yang tidak perlu berbanding panggilan RPC tradisional atau integrasi API langsung. Pembangun backend khususnya mempersoalkan keputusan seni bina yang memerlukan pelayan berasingan untuk setiap API , melihatnya sebagai berpotensi mewujudkan beratus-ratus mikroservis di mana panggilan fungsi yang lebih mudah sudah memadai.

Salah satu pengajaran terbesar bagi saya semasa mengikuti gembar-gembur MCP ialah jika anda menulis perisian backend, anda sebenarnya tidak perlu melakukan MCP . Dari segi seni bina, ia tidak masuk akal.

Penyokong menentang bahawa MCP menyediakan cara piawai untuk melampirkan alat kepada ejen AI tanpa menanggung kos API , terutamanya bermanfaat untuk pengguna Claude . Mereka menekankan nilainya sebagai sistem integrasi plug-and-play untuk persekitaran di mana tidak semua orang boleh atau diberi kuasa untuk menulis kod secara langsung terhadap sumber.

Cabaran Kematangan dan Penerimaan Protokol

Kadar perubahan spesifikasi yang pantas menimbulkan persoalan mengenai kematangan dan kestabilan protokol. Walaupun sesetengah pembangun menghargai penambahbaikan berterusan dan responsif terhadap maklum balas komuniti, yang lain bimbang tentang beban penyelenggaraan untuk memastikan berbilang pelayan MCP dikemas kini dengan setiap semakan spesifikasi. Pergantungan protokol pada TypeScript untuk spesifikasi terasnya, bukannya format dokumentasi API yang lebih tradisional seperti OpenAPI , juga menarik perhatian sebagai pilihan yang tidak konvensional.

Perdebatan mencerminkan persoalan yang lebih luas mengenai penyeragaman dalam ekosistem alat AI dan sama ada protokol sedia ada mungkin melayani tujuan yang serupa dengan kerumitan yang kurang. Apabila MCP terus berkembang, penerimaan ia berkemungkinan bergantung pada sama ada faedah penyeragaman mengatasi kos kerumitan yang dianggap untuk jenis aplikasi yang berbeza.

Rujukan: Perubahan Utama