Membebankan Tanggungjawab MCP
Satu kritikan umum ialah MCP dibebankan dengan terlalu banyak tanggungjawab. Penulis berpendapat bahawa MCP sepatutnya berfungsi sebagai pintu masuk untuk LLM mengakses dan berinteraksi dengan sumber luaran. Menganggapnya sebagai sekadar ‘pintu’ atau ‘jambatan’ membantu menjelaskan tujuan dan batasannya.
Menyalahkan isu seperti pendedahan data secara tidak sengaja, kerentanan suntikan segera dan kekurangan kawalan kos secara langsung kepada MCP adalah salah. Ini adalah masalah yang perlu ditangani oleh pembangun dalam batasan yang mereka kawal. Pembangun perlu melaksanakan had kadar dan memantau penggunaan, tanpa mengira protokol yang digunakan. Menyamakan ini dengan menyalahkan jalan raya kerana memandu laju adalah tepat – infrastruktur tidak bertanggungjawab untuk tingkah laku individu.
Akhirnya, banyak kebimbangan yang dibangkitkan adalah isu yang lebih luas yang berkaitan dengan menyerahkan tugas kepada ejen AI. Pembangun mesti bertanggungjawab untuk menguruskan cabaran ini dalam aplikasi khusus mereka, dan bukannya mengharapkan API itu sendiri untuk mengendalikan segala-galanya.
Pedang Bermata Dua LLM dan Suntikan Segera
Perbincangan baru-baru ini mengenai MCP sering menyerupai amaran tentang bahaya pisau tajam – ia boleh memotong jika tersalah kendali. Suntikan segera, kebimbangan yang ketara, adalah akibat daripada sifat LLM itu sendiri. Percubaan untuk menghapuskan risiko suntikan segera merendahkan keupayaan yang menjadikan LLM berharga.
Gagasan pemisahan ‘kawalan vs. data’, yang biasa dalam sistem tradisional, tidak wujud secara semula jadi dalam LLM. LLM memperoleh kuasa dan umumnya kerana ia tidak mempunyai pemisahan tegar ini. Ciri semula jadi ini menjadikan mereka terdedah kepada serangan suntikan segera.
Walaupun MCP Jauh sebagai Perkhidmatan mungkin menimbulkan risiko, kesalahannya bukan pada protokol itu sendiri tetapi dengan mempercayakan tugas sensitif kepada pihak ketiga yang tidak dipercayai. Analogi ini meluas kepada idea menampal pisau pada Roomba yang tidak menentu – masalahnya bukan pada pisau itu sendiri, tetapi keputusan untuk melekatkannya pada peranti yang tidak dapat diramalkan.
Nasihat untuk ‘berhati-hati’ atau cadangan peralatan pelindung, walaupun tepat secara teknikal, terlepas isu teras: keputusan yang tidak bijak untuk menggabungkan alat tajam dengan sistem yang tidak terkawal.
Cabaran Skalabiliti
Di sebalik kebimbangan keselamatan, MCP menghadapi batasan skalabiliti asas. Penulis menekankan korelasi negatif antara kebolehpercayaan LLM dan jumlah konteks pengajaran yang disediakan. Ini mencabar kepercayaan umum bahawa menambahkan lebih banyak data dan integrasi secara automatik akan menyelesaikan masalah. Apabila bilangan alat dan integrasi meningkat, prestasi ejen mungkin merosot sambil meningkatkan kos setiap permintaan secara serentak.
Penulis menekankan bahawa MCP tidak berskala melebihi ambang tertentu. Percubaan untuk menambahkan bilangan alat yang tidak terhad pada konteks ejen pasti akan memberi kesan negatif kepada keupayaannya. Batasan ini wujud dalam konsep MCP dan memerlukan lebih banyak perhatian daripada isu pengesahan.
Pengguna akhirnya mungkin mengalami penurunan prestasi apabila mereka mendayakan lebih banyak pelayan MCP, yang membawa kepada gangguan antara mereka. Ini sangat berbeza dengan sistem pengurusan pakej biasa, di mana bukan gangguan adalah sifat asas.
Masalah teras dengan MCP ialah tingkah laku sebenarnya menyimpang daripada jangkaan pengguna. Adalah penting untuk menyedari bahawa MCP bukanlah penyelesaian pasang dan guna yang menyepadukan bilangan alat yang tidak terhad tanpa akibat.
Menangani Batasan dengan UI dan Pengurusan Alat
Satu penyelesaian yang dicadangkan untuk batasan MCP adalah untuk meningkatkan antara muka pengguna. Jika alat dilaksanakan secara tidak sengaja, UI harus menyediakan cara mudah untuk melumpuhkannya atau mengubah suai penerangannya untuk menjelaskan penggunaan yang dimaksudkan.
Penulis juga menyatakan bahawa pertumbuhan konteks sering membawa kepada peningkatan prestasi dan keupayaan penggunaan dunia sebenar, yang bercanggah dengan tanggapan korelasi yang sememangnya negatif. Walau bagaimanapun, mereka mengakui bahawa dalam kes penggunaan tertentu atau dengan konteks yang direka dengan buruk, kemerosotan prestasi boleh berlaku.
Untuk menangani pilihan alat yang luar biasa, pendekatan ‘bahagi dan takluk’ dicadangkan. Ini melibatkan penambahan alat yang direka khusus untuk memilih alat yang paling relevan untuk tugas yang diberikan. ‘Alat memilih alat’ ini boleh menjadi panggilan LLM yang lain, yang ditugaskan untuk mengembalikan subset alat yang tersedia kepada ejen ‘induk’. Pendekatan berlapis ini menambah tahap pengarahan tambahan untuk mengurus kerumitan.
Walau bagaimanapun, hanya mempunyai alat dalam konteks boleh mengubah output model dengan ketara. Walaupun alat yang berkaitan secara kontekstual (dicapai melalui teknik seperti Penjanaan Tambahan Pengambilan atau RAG) bermanfaat, menyembunyikan semua alat di sebalik permintaan ‘get_tools’ boleh memudaratkan.
MCP sebagai Lapisan Pengangkutan dan Kebenaran
MCP terutamanya berfungsi sebagai format pengangkutan dan wayar dengan kitaran hayat permintaan/respons, memfokuskan pada kebenaran peringkat alat. Esei ini berhujah bahawa masalah terbesar dengan MCP adalah kegagalannya untuk membolehkan ejen AI menggubah alat secara fungsional.
Penulis mendakwa bahawa MCP mungkin tidak diperlukan dari awal, kerana LLM sudah mempunyai keupayaan untuk berinteraksi dengan API yang didokumenkan menggunakan spesifikasi OpenAPI. Elemen yang hilang ialah kebenaran – keupayaan untuk mengawal API yang boleh diakses oleh AI. Daripada MCP, penulis mencadangkan untuk membenarkan AI membuat permintaan HTTP sambil menggunakan kebenaran pada titik akhir tertentu. Pendekatan ini sejajar dengan trend semasa membungkus API sedia ada dengan alat MCP nipis.
Aspek MCP yang amat menjengkelkan ialah kekurangan sokongannya untuk menstrim hasil panggilan alat. Pasangan permintaan/respons tunggal memaksa pelanggan untuk berulang kali memanggil alat untuk penomboran halaman, menghalang proses yang berjalan lama. Melaksanakan keupayaan penstriman, mungkin menggunakan gRPC, boleh meningkatkan kecekapan MCP dengan ketara.
Kemudahan Mendedahkan Data Sensitif
Kebimbangan yang ketara dengan MCP ialah potensi untuk pendedahan mudah data sensitif. Tambahan pula, MCP tidak secara semula jadi menjadikan ejen AI lebih boleh dipercayai; ia hanya memberikan mereka akses kepada lebih banyak alat, yang secara paradoks boleh mengurangkan kebolehpercayaan dalam situasi tertentu.
Penulis mengakui bahawa mereka tidak menjangkakan MCP untuk menyelesaikan atau bertanggungjawab untuk semua isu ini. Sebaliknya, MCP mencipta permukaan yang lebih besar untuk masalah ini, yang memerlukan pembangun dan pengguna aplikasi untuk berwaspada.
Analogi dan Perancangan Bandar
Penulis menggunakan analogi perancangan bandar untuk menggambarkan isu itu. Membandingkan MCP dengan jalan bandar enam lorong dengan had laju 25mph menyerlahkan keterputusan antara reka bentuk dan penggunaan yang dimaksudkan. Hanya mengenakan denda atau menambah ‘pembetulan’ cetek tidak menangani masalah asas reka bentuk yang buruk.
Perancangan bandar yang berkesan melibatkan mereka bentuk jalan yang secara semula jadi menggalakkan pematuhan had laju. Begitu juga, MCP harus direka untuk mengurangkan potensi risiko secara intrinsik, dan bukannya bergantung semata-mata pada kawalan luaran.
LLM Mengambil Tindakan yang Tidak Diingini
Artikel itu beralih kepada kritikan yang lebih luas terhadap protokol yang membenarkan LLM melaksanakan tindakan pada perkhidmatan. Penulis mengenal pasti masalah teras: LLM mungkin mengambil tindakan yang pengguna tidak mahu mereka ambil. Mereka membezakan antara tindakan yang boleh diambil oleh LLM secara bebas dan tindakan yang memerlukan gesaan pengguna.
Walaupun matlamat utamanya mungkin untuk LLM menguruskan keseluruhan perniagaan, teknologi itu belum bersedia untuk autonomi sedemikian. Pada masa ini, pengguna mungkin tidak mahu AI menghantar e-mel tanpa semakan terlebih dahulu.
Penulis menolak penyelesaian untuk meminta pengguna untuk pengesahan, memetik risiko pengguna jatuh ke dalam corak pengesahan automatik (‘mod YOLO’) apabila kebanyakan alat kelihatan tidak berbahaya. Ini disamakan dengan fenomena psikologi orang ramai berbelanja lebih banyak dengan kad berbanding dengan wang tunai – masalah yang berakar umbi dalam tingkah laku manusia, bukan teknologi.
Soalan Asas: Mengapa Tidak Hanya Menggunakan API?
Soalan yang berulang dalam perbincangan tentang MCP ialah mengapa tidak hanya menggunakan API secara langsung.
MCP membenarkan pelanggan LLM yang pengguna tidak kawal secara langsung (cth., Claude, ChatGPT, Cursor, VSCode) untuk berinteraksi dengan API. Tanpa MCP, pembangun perlu membina pelanggan tersuai menggunakan API LLM, usaha yang jauh lebih mahal daripada menggunakan pelanggan sedia ada dengan langganan dan mengajar mereka cara menggunakan alat tertentu.
Seorang pembangun berkongsi pengalaman mereka membina pelayan MCP untuk menyambung ke pensintesis perkakasan FM mereka melalui USB, membolehkan reka bentuk bunyi yang dipacu AI.
Integrasi Pelanggan LLM dan Piawaian
Isu teras ialah tidak semua pelanggan LLM menyokong interaksi API langsung secara asli, dengan tindakan GPT tersuai ChatGPT menjadi pengecualian yang ketara. Anthropic, Google dan OpenAI telah bersetuju untuk menerima pakai MCP sebagai protokol yang dikongsi untuk menyelaraskan proses untuk pelanggan berkuasa LLM seperti Claude, ChatGPT dan Cursor.
MCP memudahkan proses untuk mereka yang membina pelanggan LLM. Jika anda mahu LLM berinteraksi dengan API, anda tidak boleh hanya menyediakan kunci API dan mengharapkannya berfungsi – anda perlu mencipta Ejen.
MCP boleh dilihat sebagai cara untuk mendokumenkan API dan menerangkan cara memanggilnya, bersama-sama dengan alat piawai untuk mendedahkan dokumentasi itu dan memudahkan panggilan. Ia menyediakan abstraksi yang mencukupi untuk membungkus API tanpa kerumitan yang tidak perlu, tetapi kesederhanaan ini juga boleh menyebabkan pengguna ‘menembak diri sendiri di kaki’.
Kecekapan dan Kebolehgunaan Semula MCP
Tanpa MCP, pembangun perlu berulang kali menerangkan kepada LLM cara menggunakan alat setiap kali ia digunakan. Ini membawa risiko LLM gagal menggunakan alat itu dengan betul kerana maklumat yang terlupa atau tingkah laku API bukan standard.
Penerangan dan penduaan berterusan ini membazirkan token dalam konteks, meningkatkan kos dan masa. MCP menyelaraskan proses ini dengan menggabungkan semua maklumat yang diperlukan, menjadikan penggunaan alat lebih cekap dan memudahkan perkongsian alat.
Dengan memberitahu penyedia LLM ‘inilah alat yang boleh anda gunakan’ bersama-sama dengan dokumentasi API, pengguna boleh menggunakan semula alat itu merentas berbilang sembang tanpa peringatan berulang. Ini juga membolehkan pelanggan LLM desktop menyambung ke program yang berjalan secara tempatan, menangani masalah proses pelaksanaan khusus OS.
MCP dan Akses Sumber Tempatan
MCP memudahkan akses kepada sumber tempatan seperti fail, pemboleh ubah persekitaran dan akses rangkaian untuk LLM. Ia direka untuk dijalankan secara tempatan, memberikan LLM akses terkawal kepada sumber ini.
‘Bentuk’ panggilan alat LLM standardsangat mencerminkan ‘bentuk’ panggilan alat MCP, menjadikannya standard yang mudah untuk menyambungkan alat kepada ejen.
MCP bertindak sebagai jambatan antara skema panggilan fungsi yang didedahkan kepada model AI dan API asas. Ia menterjemah panggilan fungsi ke dalam alat, membolehkan komunikasi yang lancar.
Jika anda seorang pembekal alat, MCP menawarkan protokol piawai untuk bahagian hadapan ejen AI untuk menyambung ke alat anda. Ini menjawab soalan mengapa protokol standard tidak boleh hanya HTTP dan OpenAPI.
MCP ialah meta-API yang menggabungkan titik akhir dan butiran operasinya ke dalam spesifikasi, membolehkan LLM berinteraksi dengannya dengan lebih berkesan.
MCP dalam Senario Khusus
MCP boleh menyelesaikan isu apabila pengguna bertanya soalan atau tidak pasti API yang hendak digunakan. Ia juga boleh memproses permintaan berdasarkan mesej sebelumnya.
Seorang pengguna berkongsi pengalaman mereka ingin mendapatkan ‘X’ pengguna dan menghantarnya ke titik akhir. Mereka mendapati MCP terlalu berlebihan untuk tugas yang mudah, menunjukkan bahawa ia tidak selalu diperlukan untuk interaksi API asas.
MCP disamakan dengan rangka kerja aplikasi web FastAPI untuk membina perisian yang boleh berkomunikasi melalui rangkaian, yang direka khusus untuk pengalaman ejen. Ia boleh dilihat sebagai ‘Rails-for-Skynet,’ menyediakan rangka kerja piawai untuk pembangunan ejen AI.
Kebimbangan Mengenai Kawalan Pembekal
Terdapat kebimbangan bahawa MCP sedang didorong untuk meningkatkan kawalan pihak pembekal ke atas sistem. Pembekal LLM akhirnya mungkin menyekat akses API, sama seperti cara Google menyukarkan penggunaan IMAP/SMTP dengan Gmail.
Menggunakan OpenAPI membolehkan ejen mendapatkan spesifikasi API daripada /openapi.json.
MCP membolehkan interaksi pantas, membolehkan pengguna menyelesaikan tugas dalam beberapa saat dan bukannya menghabiskan masa untuk menyediakan data input, menghantarnya ke API, menghuraikan output dan mengulangi proses untuk setiap mesej.
Kotak Pasir dan Risiko Keselamatan
Salah satu isu terbesar ialah cara output alat pelayan MCP boleh menjejaskan alat lain dalam utas mesej yang sama. Ini memerlukan kotak pasir antara alat untuk mengelakkan akibat yang tidak diingini. Makmal invarian menangani ini dengan penerangan alat, manakala yang lain telah menggunakan lampiran sumber MCP. Kekurangan kotak pasir memburukkan lagi risiko suntikan segera.
Ini disamakan dengan suntikan SQL – sistem yang digabungkan di mana kelemahan boleh dieksploitasi pada bila-bila masa dengan kebolehperhatian yang minimum.
Antara muka segera juga terdedah kepada bentuk suntikan SQL, kerana model tidak boleh membezakan bahagian segera yang boleh dipercayai daripada input yang dicemari pengguna. Menyelesaikan ini memerlukan perubahan asas kepada pengekodan, penyahkodan dan latihan model.
Ini membolehkan suntikan segera dan suntikan alat, yang berpotensi membawa kepada pelaksanaan kod yang tidak boleh dipercayai.
Kontainerisasi dan Akses Terkawal
Seorang pembangun mencipta pelayan MCP yang memulakan bekas Docker dengan kod projek dipasang. Pendekatan ini membolehkan LLM mengakses keseluruhan set alat Unix dan alat khusus projek dalam persekitaran kotak pasir.
Aliran kerja ejen ini, dipacu melalui antara muka berasaskan sembang, telah terbukti lebih berkesan daripada kaedah tradisional.
Kuncinya ialah memberikan ejen MCP akses kepada apa yang mereka perlukan, dan tidak lebih daripada itu. Kontainerisasi dan UX alat telus adalah penting untuk mengurangkan risiko keselamatan.
Mesin Maya dan Akses Internet
Memberi ejen komputer dengan pemasangan Linux minimum (sebagai VM atau bekas) boleh menghasilkan hasil yang lebih baik, membolehkan mereka mendapatkan maklumat daripada internet. Walau bagaimanapun, ini menimbulkan kebimbangan keselamatan mengenai arahan berniat jahat dan penyahjajaran data.
Membataskan akses kepada tapak web yang dipercayai boleh mengurangkan beberapa risiko, tetapi walaupun sumber yang dipercayai boleh mengehoskan kandungan berniat jahat. Pertukaran antara kemungkinan menemui arahan berniat jahat dan faedah produktiviti mesti dipertimbangkan dengan teliti.
Perbezaan antara pekerja dan ejen AI adalah ketara. Pekerja adalah orang undang-undang yang tertakluk kepada undang-undang dan kontrak, yang menyediakan akauntabiliti. Ejen AI tidak mempunyai rangka kerja undang-undang ini, menjadikan kepercayaan lebih sukar.
Peringkat Awal Pembangunan MCP
MCP hanya diumumkan pada November 2024, dan RFC sedang berkembang secara aktif.
Sesetengah orang melihat keseluruhan konsep pembantu peribadi AI, termasuk MCP, sebagai cacat dari segi asas.
Dorongan awal untuk Pembantu AI pada akhir 1990-an dan awal 2000-an gagal kerana pengagregat kandungan dengan integrasi menegak dan kuasa pembelian pukal terbukti lebih berkesan. Ini membawa kepada kebangkitan platform seperti Expedia dan eBay.
Sistem berbilang ejen memerlukan pengaturcara untuk mempengaruhi keadaan ejen, tugas pengaturcaraan yang mencabar.
Had Nilai Percuma
Keinginan untuk ‘menyenaraikan hasil mengikut ketersediaan tempat letak kereta’ menyerlahkan isu mengakses data di sebalik API berbayar atau bahagian hadapan yang disokong iklan. Syarikat tidak mungkin memberikan akses percuma kepada keseluruhan set data mereka melalui API.
Walaupun tidak semua syarikat akan menyepadukan data mereka ke dalam ejen AI, potensi untuk menggabungkan pelbagai alat untuk memperkasakan aliran kerja tetap ketara.
Syarikat yang mengutamakan pengekalan parit data akan menentang teknologi baharu yang mengancam parit itu.
Jika booking.com mempunyai API, mereka mungkin akan mengembalikan hasil yang sama seperti tapak web mereka, mungkin dengan pemformatan JSON atau XML.
Memintas Orang Tengah
Tidak masuk akal bagi orang tengah seperti booking.com untuk membenarkan pengguna memintas perkhidmatan mereka sepenuhnya.
Walau bagaimanapun, hotel individu mungkin mendapati ia bermanfaat untuk memintas booking.com, orang tengah yang sering mereka tidak sukai.
AI Penyelidikan Mendalam boleh mengimbas hotel berdasarkan kriteria tertentu dan berinteraksi dengan pelayan MCP Penemuan Hotel yang dikendalikan oleh hotel individu, memintas keperluan untuk menavigasi antara muka dan iklan booking.com.
Kes Penggunaan Praktikal
MCP boleh memudahkan tugas seperti mendapatkan log daripada Elasticsearch atau menanyakan pangkalan data dengan cara yang lebih berstruktur.
Sifat statik konfigurasi pelayan MCP, di mana pelayan baharu memerlukan penyuntingan fail .json dan memulakan semula aplikasi, boleh menjadi terhad.
Model Diperhalusi
MCP boleh dilihat sebagai model kecil yang diperhalusi yang memahami banyak alat MCP dan memilih yang betul untuk setiap perbualan.
Melaraskan alat secara dinamik berdasarkan konteks mungkin diperlukan untuk senario tertentu.
Perbualan Terbuka dan Masalah Perniagaan
MCP sangat sesuai untuk sistem perbualan terbuka umum tanpa aliran yang telah ditetapkan. Walau bagaimanapun, ia bukan penyelesaian yang sesuai untuk setiap masalah perniagaan. Ia tidak bertujuan untuk menggantikan rangka kerja seperti LangChain.
Alternatif kepada MCP, piawaian berasaskan komuniti terbuka, adalah protokol yang berpecah-belah, proprietari dan terkunci vendor. Piawaian yang cacat tetapi berkembang adalah lebih baik daripada tiada piawaian sama sekali.
Cara terbaik untuk melihat MCP ialah sebagai peralihan daripada pembangun individu yang membina pembungkus pelanggan di sekeliling API kepada pembekal API atau pembungkus yang diselenggara komuniti yang membina. Ini menyediakan kotak alat yang besar, serupa dengan NPM atau PyPi. Walau bagaimanapun, orkestrasi, keselamatan dan definisi penggunaan masih diperlukan.
Langchain generasi akan datang akan mendapat manfaat daripada alat yang lebih besar ini, tetapi inovasi masih diperlukan.
Alat Khusus Pengguna
Dalam sesetengah kes, alat mungkin khusus untuk data pengguna, seperti alat untuk menghiris dan memanipulasi fail CSV yang dimuat naik.
Satu isu yang sering diabaikan ialah MCP boleh memenuhi konteks model dengan terlalu banyak pilihan. Keutamaan dan pendedahan metadata adalah penting untuk mengelakkan penggunaan token yang membazir dan tingkah laku model yang tidak menentu.
Piawaian dan Teknologi Berkembang
Piawaian baharu muncul dari semasa ke semasa, dan sudah lama sejak piawaian benar-benar penting sehingga orang ramai terlupa cara ia berkembang.
Memuat turun program pelayan kecil daripada pembangun rawak untuk menambahkan ‘alat’ pada pelanggan LLM boleh menjadi berisiko.
Isu yang dibangkitkan adalah masalah sah yang perlu ditangani oleh ekosistem MCP. Beberapa penyelesaian akan berada dalam spesifikasi MCP, manakala yang lain akan menjadi luaran.
Kod Claude dan Penggunaan Dunia Sebenar
Terdapat pendapat yang berbeza-beza mengenai kejayaan MCP. Sesetengah orang telah mendengar cerita tentang syarikat yang berintegrasi dengan MCP, manakala yang lain telah mendengar daripada pengguna yang mendapati ia mengecewakan.
Ini menyerlahkan kelemahan gembar-gembur dan penerimaan awal.
Sesetengah pembangun mendapati bahawa API HTTP adalah lebih baik daripada MCP untuk kebanyakan kes penggunaan. Mereka berhujah bahawa penggunaan ‘alat’ merujuk kepada titik akhir API untuk keupayaan dan fungsi.
API tidak menerangkan sendiri secara lalai, yang mewakili peluang yang terlepas untuk penyokong REST dan HATEOAS untuk mempamerkan pendekatan mereka.
MCP sebagai Alternatif LangChain?
MCP telah digambarkan sebagai mempunyai ‘bau LangChain’ – tidak menyelesaikan masalah yang mendesak, terlalu abstrak dan mengalami kesukaran untuk menjelaskan kelebihannya.
Mungkin ia perlu mengatakan ‘END OF LINE’ dan menghalau penggodam wannabe ke grid permainan!
Soalan utama ialah sama ada paradigma Chatbot ‘am’ akan berterusan. Aplikasi khusus dengan alat mereka sendiri mungkin tidak memerlukan MCP.
Sebaliknya, apabila LLM menjadi lebih berkemampuan, alat luaran mungkin menjadi kurang perlu. Mengapa anda mahu MCP untuk memacu Photoshop apabila LLM boleh mengedit imej secara langsung?
Impian pembantu robot fiksyen sains mungkin tidak menjadi kenyataan, dan alat manipulasi bahasa khusus mungkin lebih berguna.
Pangkalan Pengguna dan Kesedaran Keselamatan
Pangkalan pengguna MCP termasuk individu yang kurang teknikal, menjadikan isu keselamatan sangat relevan. Meningkatkan kesedaran tentang amalan terbaik keselamatan adalah penting.
Mendasarkan Xops pada OpenRPC, yang memerlukan definisi skema hasil, membantu merancang cara output bersambung kepada input, meningkatkan kebolehpercayaan untuk aliran kerja yang kompleks.
Teknologi itu berkemungkinan akan berkembang dan menetap dari semasa ke semasa.
Lebihan dan Infrastruktur Awan
Sesetengah orang mempersoalkan keuntungan menggunakan MCP berbanding piawaian OpenAPI, melihatnya sebagai berlebihan.
Apakah yang akan digunakan oleh LLM untuk menghubungi sistem OpenAPI? Bagaimanakah ia akan terikat pada shell? Bagaimanakah hos LLM akan mengatur perkara itu?
MCP menyediakan cara berstruktur untuk LLM membuat panggilan alat.
Pelayan MCP sudah menjadi pelayan HTTP.
Kelebihan terbesar MCP adalah untuk penyedia LLM seperti OpenAI, bukan pembangun aplikasi.
LLM adalah otak tanpa alat, dan panggilan alat memperkasakan mereka. Walau bagaimanapun, dengan API biasa, penyedia LLM tidak mempunyai akses kepada alat tersebut. MCP memberikan mereka akses, meletakkan mereka sebagai pintu masuk kepada AI.
CLI lwn. API
Mengapa tidak menggunakan CLI secara terus, memandangkan LLM dilatih dalam bahasa semula jadi dan CLI ialah penyelesaian yang boleh dibaca dan ditulis manusia?
MCP muncul terlalu cepat dan memerlukan masa untuk matang. Ia tidak mempunyai pemeriksaan oleh badan piawaian konvensional dan dipacu oleh gembar-gembur.
Terdapat kekurangan aplikasi dunia sebenar.
Aplikasi Utama MCP
MCP digunakan dalam Claude Desktop dan aplikasi sembang AI khusus, alat automasi kod dan rangka kerja automasi ejen/LLM.
Ia adalah satu lagi teknologi tergesa-gesa yang berkemungkinan akan dibuang apabila akronim yang boleh disiarkan seterusnya tiba.
Terdapat dua jenis protokol panggilan alat model bahasa: yang orang ramai adukan dan yang tiada siapa gunakan.
Anthropic membangunkan ‘piawaian’ ini dalam vakum, yang membawa kepada isu keselamatan.
JSON-RPC 2.0
MCP dibina berdasarkan JSON-RPC 2.0, protokol ringan yang membolehkan komunikasi pelanggan dan pelayan menggunakan JSON.
Ia berasa seperti spesifikasi terpusat yang direka untuk ekosistem tertentu, mendakwa sejagat tanpa memperolehnya.
MCP cukup berkuasa untuk melakukan perkara yang berguna, yang menimbulkan kebimbangan keselamatan.
Ia bukan piawaian yang matang dan tidak direka untuk selamat.
Walaupun cadangan wujud, ia tidak dikuatkuasakan atau dilaksanakan.
Langchain dan Panggilan Alat
Langchain ialah salah satu daripada banyak rangka kerja yang melaksanakan corak ‘panggilan alat’.
MCP ialah spesifikasi untuk cara maklumat luaran memasuki tetingkap konteks model bahasa, termasuk panggilan alat, input bertemplat, pembatalan, penjejakan kemajuan dan keadaan pelayan alat.
Ia membantu menyeragamkan butiran supaya mana-mana kombo pembantu/integrasi serasi.
Walaupun MCP mempunyai masalah yang sah, pengkritik harus memperhalusi hujah mereka.
Pengesahan adalah penting dan tidak sepatutnya ditinggalkan daripada versi awal.
Terdapat terlalu banyak kerumitan.