Machine Communication Protocol (MCP) telah menarik perhatian besar di dunia teknologi, khususnya di ranah Large Language Models (LLM). Walaupun menjanjikan untuk menyederhanakan interaksi antara LLM dan sumber daya eksternal, peninjauan lebih dekat mengungkapkan beberapa masalah dan batasan inheren yang memerlukan pertimbangan cermat. Analisis ini menggali kritik seputar MCP, menjelajahi kerentanannya, tantangan skalabilitas, dan implikasi yang lebih luas untuk pengembangan agen AI.
Membebani Tanggung Jawab MCP
Satu kritik umum adalah bahwa MCP dibebani dengan terlalu banyak tanggung jawab. Penulis berpendapat bahwa MCP seharusnya terutama berfungsi sebagai gerbang bagi LLM untuk mengakses dan berinteraksi dengan sumber daya eksternal. Memandangnya hanya sebagai “pintu” atau “jembatan” membantu memperjelas tujuan dan batasannya.
Mengaitkan masalah seperti paparan data yang tidak disengaja, kerentanan injeksi prompt, dan kekurangan pengendalian biaya secara langsung ke MCP adalah kesalahan penempatan kesalahan. Ini adalah masalah yang harus ditangani pengembang dalam batas-batas yang mereka kendalikan. Pengembang perlu menerapkan batasan laju dan memantau penggunaan, terlepas dari protokol yang digunakan. Menyamakan ini dengan menyalahkan jalan karena ngebut adalah tepat – infrastruktur tidak bertanggung jawab atas perilaku individu.
Pada akhirnya, banyak dari kekhawatiran yang diajukan adalah masalah yang lebih luas terkait dengan mendelegasikan tugas ke agen AI. Pengembang harus bertanggung jawab untuk mengelola tantangan ini dalam aplikasi khusus mereka, daripada mengharapkan API itu sendiri untuk menangani segalanya.
Pedang Bermata Dua LLM dan Injeksi Prompt
Diskusi baru-baru ini seputar MCP sering menyerupai peringatan tentang bahaya inheren pisau tajam – mereka dapat memotong jika salah ditangani. Injeksi prompt, masalah yang signifikan, adalah konsekuensi dari sifat LLM itu sendiri. Upaya untuk menghilangkan risiko injeksi prompt akan menurunkan kemampuan yang membuat LLM berharga.
Gagasan pemisahan “kontrol vs. data”, yang umum dalam sistem tradisional, tidak secara alami ada di LLM. LLM mendapatkan kekuatan dan generalitas mereka justru karena mereka tidak memiliki pemisahan yang kaku ini. Karakteristik inheren ini membuat mereka rentan terhadap serangan injeksi prompt.
Meskipun MCP jarak jauh sebagai Layanan dapat menghadirkan risiko, kesalahannya bukan pada protokol itu sendiri tetapi pada mempercayakan tugas-tugas sensitif kepada pihak ketiga yang tidak tepercaya. Analogi ini meluas ke gagasan merekatkan pisau ke Roomba yang tidak menentu – masalahnya bukan pada pisau itu sendiri, tetapi keputusan untuk memasangnya ke perangkat yang tidak dapat diprediksi.
Nasihat untuk “berhati-hati” atau saran perlengkapan pelindung, meskipun secara teknis akurat, melewatkan inti masalah: keputusan yang tidak bijaksana untuk menggabungkan alat tajam dengan sistem yang tidak terkendali.
Tantangan Skalabilitas
Di luar masalah keamanan, MCP menghadapi batasan skalabilitas mendasar. Penulis menyoroti korelasi negatif antara keandalan LLM dan jumlah konteks instruksional yang diberikan. Ini menantang keyakinan umum bahwa menambahkan lebih banyak data dan integrasi secara otomatis akan menyelesaikan masalah. Seiring bertambahnya jumlah alat dan integrasi, kinerja agen dapat menurun sambil secara bersamaan meningkatkan biaya setiap permintaan.
Penulis menekankan bahwa MCP tidak dapat diskalakan melampaui ambang batas tertentu. Upaya untuk menambahkan jumlah alat yang tidak terbatas ke konteks agen pasti akan berdampak negatif pada kemampuannya. Batasan ini melekat pada konsep MCP dan membutuhkan lebih banyak perhatian daripada masalah otentikasi.
Pengguna akhirnya dapat mengalami penurunan kinerja saat mereka mengaktifkan lebih banyak server MCP, yang menyebabkan gangguan di antara mereka. Ini sangat kontras dengan sistem manajemen paket tipikal, di mana non-interferensi adalah properti mendasar.
Masalah inti dengan MCP adalah bahwa perilaku aktualnya menyimpang dari harapan pengguna. Sangat penting untuk menyadari bahwa MCP bukanlah solusi plug-and-play yang secara mulus mengintegrasikan jumlah alat yang tidak terbatas tanpa konsekuensi.
Mengatasi Batasan dengan UI dan Manajemen Alat
Satu solusi yang diusulkan untuk batasan MCP adalah meningkatkan antarmuka pengguna. Jika suatu alat dieksekusi secara tidak sengaja, UI harus menyediakan cara mudah untuk menonaktifkannya atau mengubah deskripsinya untuk memperjelas penggunaan yang dimaksudkan.
Penulis juga mencatat bahwa pertumbuhan konteks seringkali mengarah pada peningkatan kinerja dan kemampuan penggunaan dunia nyata, yang bertentangan dengan gagasan korelasi yang sepenuhnya negatif. Namun, mereka mengakui bahwa dalam kasus penggunaan tertentu atau dengan konteks yang dirancang dengan buruk, penurunan kinerja dapat terjadi.
Untuk mengatasi pilihan alat yang luar biasa, pendekatan “bagi dan taklukkan” disarankan. Ini melibatkan penambahan alat yang dirancang khusus untuk memilih alat yang paling relevan untuk tugas tertentu. “Alat pemilih alat” ini dapat berupa panggilan LLM lain, yang bertugas mengembalikan subset alat yang tersedia ke agen “induk”. Pendekatan berlapis ini menambahkan tingkat tidak langsung tambahan untuk mengelola kompleksitas.
Namun, hanya memiliki alat dalam konteks dapat secara signifikan mengubah keluaran model. Meskipun alat yang relevan secara kontekstual (dicapai melalui teknik seperti Retrieval-Augmented Generation atau RAG) bermanfaat, menyembunyikan semua alat di balik permintaan “get_tools” dapat merugikan.
MCP sebagai Lapisan Transportasi dan Otorisasi
MCP terutama berfungsi sebagai format transportasi dan kawat dengan siklus hidup permintaan/respons, berfokus pada otorisasi tingkat alat. Esai ini berpendapat bahwa masalah terbesar dengan MCP adalah kegagalannya untuk memungkinkan agen AI menyusun alat secara fungsional.
Penulis berpendapat bahwa MCP mungkin tidak diperlukan sejak awal, karena LLM sudah memiliki kemampuan untuk berinteraksi dengan API yang didokumentasikan menggunakan spesifikasi OpenAPI. Elemen yang hilang adalah otorisasi – kemampuan untuk mengontrol API mana yang dapat diakses oleh AI. Alih-alih MCP, penulis menyarankan untuk mengizinkan AI untuk membuat permintaan HTTP sambil menerapkan otorisasi ke titik akhir tertentu. Pendekatan ini sejalan dengan tren saat ini untuk membungkus API yang ada dengan alat MCP tipis.
Aspek yang sangat menjengkelkan dari MCP adalah kurangnya dukungan untuk streaming hasil panggilan alat. Pasangan permintaan/respons tunggal memaksa klien untuk berulang kali memanggil alat untuk penomoran halaman, menghambat proses yang berjalan lama. Menerapkan kemampuan streaming, mungkin menggunakan gRPC, dapat secara signifikan meningkatkan efisiensi MCP.
Kemudahan Memaparkan Data Sensitif
Kekhawatiran yang signifikan dengan MCP adalah potensi paparan data sensitif yang mudah. Selain itu, MCP tidak secara inheren membuat agen AI lebih andal; itu hanya memberi mereka akses ke lebih banyak alat, yang secara paradoks dapat mengurangi keandalan dalam situasi tertentu.
Penulis mengakui bahwa mereka tidak mengharapkan MCP untuk menyelesaikan atau bertanggung jawab atas semua masalah ini. Sebaliknya, MCP menciptakan area permukaan yang lebih besar untuk masalah ini, yang mengharuskan pengembang aplikasi dan pengguna untuk waspada.
Analogi dan Perencanaan Kota
Penulis menggunakan analogi perencanaan kota untuk menggambarkan masalah tersebut. Membandingkan MCP dengan jalan kota enam jalur dengan batas kecepatan 25 mph menyoroti keterputusan antara desain dan penggunaan yang dimaksudkan. Hanya mengenakan denda atau menambahkan “perbaikan” dangkal tidak mengatasi masalah mendasar dari desain yang buruk.
Perencanaan kota yang efektif melibatkan perancangan jalan yang secara alami mendorong kepatuhan terhadap batas kecepatan. Demikian pula, MCP harus dirancang untuk secara inheren mengurangi potensi risiko, daripada hanya mengandalkan kontrol eksternal.
LLM Mengambil Tindakan yang Tidak Diinginkan
Artikel ini beralih ke kritik yang lebih luas tentang protokol yang memungkinkan LLM untuk mengeksekusi tindakan pada layanan. Penulis mengidentifikasi masalah inti: LLM dapat mengambil tindakan yang tidak dimaksudkan oleh pengguna. Mereka membedakan antara tindakan yang dapat diambil LLM secara independen dan tindakan yang memerlukan perintah pengguna.
Meskipun tujuan utamanya adalah agar LLM mengelola seluruh bisnis, teknologi ini belum siap untuk otonomi seperti itu. Saat ini, pengguna bahkan mungkin tidak ingin AI mengirim email tanpa tinjauan sebelumnya.
Penulis menolak solusi untuk meminta pengguna untuk konfirmasi, mengutip risiko pengguna jatuh ke dalam pola konfirmasi otomatis (“mode YOLO”) ketika sebagian besar alat tampak tidak berbahaya. Ini diibaratkan dengan fenomena psikologis orang yang menghabiskan lebih banyak dengan kartu daripada dengan uang tunai – masalah yang berakar pada perilaku manusia, bukan teknologi.
Pertanyaan Mendasar: Mengapa Tidak Menggunakan API Saja?
Pertanyaan yang berulang dalam diskusi tentang MCP adalah mengapa tidak menggunakan API secara langsung saja.
MCP memungkinkan klien LLM yang tidak dikontrol langsung oleh pengguna (misalnya, Claude, ChatGPT, Cursor, VSCode) untuk berinteraksi dengan API. Tanpa MCP, pengembang perlu membangun klien khusus menggunakan API LLM, upaya yang jauh lebih mahal daripada menggunakan klien yang ada dengan langganan dan mengajari mereka cara menggunakan alat tertentu.
Seorang pengembang berbagi pengalamannya membangun server MCP untuk terhubung ke synthesizer perangkat keras FM mereka melalui USB, yang memungkinkan desain suara berbasis AI.
Integrasi Klien LLM dan Standardisasi
Masalah intinya adalah bahwa tidak semua klien LLM secara native mendukung interaksi API langsung, dengan tindakan GPT khusus ChatGPT menjadi pengecualian penting. Anthropic, Google, dan OpenAI telah setuju untuk mengadopsi MCP sebagai protokol bersama untuk menyederhanakan proses untuk klien bertenaga LLM seperti Claude, ChatGPT, dan Cursor.
MCP menyederhanakan proses bagi mereka yang membangun klien LLM. Jika Anda ingin LLM berinteraksi dengan API, Anda tidak dapat hanya memberikan kunci API dan mengharapkannya berfungsi – Anda perlu membuat Agen.
MCP dapat dilihat sebagai cara untuk mendokumentasikan API dan menjelaskan cara memanggilnya, bersama dengan alat standar untuk memaparkan dokumentasi tersebut dan memfasilitasi panggilan. Ini memberikan abstraksi yang cukup untuk membungkus API tanpa komplikasi yang tidak perlu, tetapi kesederhanaan ini juga dapat menyebabkan pengguna “menembak diri sendiri di kaki”.
Efisiensi dan Penggunaan Kembali MCP
Tanpa MCP, pengembang perlu berulang kali menjelaskan kepada LLM cara menggunakan alat setiap kali dipanggil. Ini membawa risiko LLM gagal menggunakan alat dengan benar karena informasi yang terlupakan atau perilaku API yang tidak standar.
Penjelasan dan duplikasi yang konstan ini membuang-buang token dalam konteks, meningkatkan biaya dan waktu. MCP menyederhanakan proses ini dengan menggabungkan semua informasi yang diperlukan, membuat penggunaan alat lebih efisien dan memfasilitasi berbagi alat.
Dengan memberi tahu penyedia LLM “ini adalah alat yang dapat Anda gunakan” bersama dengan dokumentasi API, pengguna dapat menggunakan kembali alat itu di beberapa obrolan tanpa pengingat berulang. Ini juga memungkinkan klien LLM desktop untuk terhubung ke program yang berjalan secara lokal, mengatasi masalah proses eksekusi khusus OS.
MCP dan Akses Sumber Daya Lokal
MCP memfasilitasi akses ke sumber daya lokal seperti file, variabel lingkungan, dan akses jaringan untuk LLM. Ini dirancang untuk dijalankan secara lokal, memberikan LLM akses terkontrol ke sumber daya ini.
“Bentuk” panggilan alat LLM standar sangat mirip dengan “bentuk” panggilan alat MCP, menjadikannya standar yang mudah untuk menghubungkan alat ke agen.
MCP bertindak sebagai jembatan antara skema panggilan fungsi yang diekspos ke model AI dan API yang mendasarinya. Ini menerjemahkan panggilan fungsi ke dalam alat, memungkinkan komunikasi tanpa batas.
Jika Anda adalah penyedia alat, MCP menawarkan protokol standar untuk frontend agen AI untuk terhubung ke alat Anda. Ini menjawab pertanyaan mengapa protokol standar tidak dapat hanya HTTP dan OpenAPI.
MCP adalah meta-API yang menggabungkan titik akhir dan detail operasional mereka ke dalam spesifikasi, memungkinkan LLM untuk berinteraksi dengan mereka dengan lebih efektif.
MCP dalam Skenario Khusus
MCP dapat menyelesaikan masalah ketika pengguna mengajukan pertanyaan atau tidak yakin API mana yang akan digunakan. Itu juga dapat memproses permintaan berdasarkan pesan sebelumnya.
Seorang pengguna berbagi pengalamannya ingin mengambil “X” pengguna dan mengirimkannya ke titik akhir. Mereka menemukan MCP berlebihan untuk tugas yang begitu sederhana, yang menunjukkan bahwa itu tidak selalu diperlukan untuk interaksi API dasar.
MCP diibaratkan dengan kerangka kerja aplikasi web FastAPI untuk membangun perangkat lunak yang dapat berkomunikasi melalui jaringan, yang dirancang khusus untuk pengalaman agentic. Itu dapat dilihat sebagai “Rails-for-Skynet,” menyediakan kerangka kerja standar untuk pengembangan agen AI.
Kekhawatiran Tentang Kontrol Penyedia
Ada kekhawatiran bahwa MCP didorong untuk meningkatkan kontrol sisi penyedia atas sistem. Penyedia LLM pada akhirnya dapat membatasi akses API, mirip dengan bagaimana Google mempersulit penggunaan IMAP/SMTP dengan Gmail.
Menggunakan OpenAPI memungkinkan agen untuk mengambil spesifikasi API dari /openapi.json.
MCP memungkinkan interaksi cepat, memungkinkan pengguna untuk menyelesaikan tugas dalam hitungan detik daripada menghabiskan waktu untuk menyiapkan data input, mengirimkannya ke API, mengurai output, dan mengulangi proses untuk setiap pesan.
Sandboxing dan Risiko Keamanan
Salah satu masalah terbesar adalah bagaimana keluaran satu alat server MCP dapat memengaruhi alat lain dalam utas pesan yang sama. Ini membutuhkan sandboxing antara alat untuk mencegah konsekuensi yang tidak diinginkan. Laboratorium invariant mengatasi ini dengan deskripsi alat, sementara yang lain telah menggunakan lampiran sumber daya MCP. Kurangnya sandboxing memperburuk risiko injeksi prompt.
Ini diibaratkan dengan injeksi SQL – sistem yang dirakit di mana kerentanan dapat dieksploitasi pada titik mana pun dengan minimal observabilitas.
Antarmuka prompt juga rentan terhadap bentuk injeksi SQL, karena model tidak dapat membedakan bagian prompt yang dapat dipercaya dari input yang dicemari pengguna. Menyelesaikan ini membutuhkan perubahan mendasar pada pengkodean, dekode, dan pelatihan model.
Ini memungkinkan injeksi prompt dan injeksi alat, yang berpotensi mengarah pada eksekusi kode yang tidak dapat dipercaya.
Kontainerisasi dan Akses Terkontrol
Seorang pengembang membuat server MCP yang memulai wadah Docker dengan kode proyek yang dipasang. Pendekatan ini memungkinkan LLM untuk mengakses seluruh toolset Unix dan peralatan khusus proyek dalam lingkungan yang di-sandbox.
Alur kerja agentic ini, yang didorong melalui antarmuka berbasis obrolan, telah terbukti lebih efektif daripada metode tradisional.
Kuncinya adalah memberikan agen MCP akses ke apa yang mereka butuhkan, dan tidak lebih. Kontainerisasi dan UX alat yang transparan sangat penting untuk mengurangi risiko keamanan.
Mesin Virtual dan Akses Internet
Memberi agen komputer dengan instalasi Linux minimal (sebagai VM atau wadah) dapat menghasilkan hasil yang lebih baik, memungkinkan mereka untuk mengambil informasi dari internet. Namun, ini menimbulkan kekhawatiran keamanan mengenai instruksi berbahaya dan eksfiltrasi data.
Membatasi akses ke situs web tepercaya dapat mengurangi beberapa risiko, tetapi bahkan sumber tepercaya dapat menghosting konten berbahaya. Pertukaran antara kemungkinan menemukan instruksi berbahaya dan manfaat produktivitas harus dipertimbangkan dengan hati-hati.
Perbedaan antara karyawan dan agen AI signifikan. Karyawan adalah orang hukum yang tunduk pada undang-undang dan kontrak, memberikan akuntabilitas. Agen AI tidak memiliki kerangka hukum ini, membuat kepercayaan lebih sulit.
Tahap Awal Pengembangan MCP
MCP hanya diumumkan pada November 2024, dan RFC secara aktif berkembang.
Beberapa orang melihat seluruh konsep asisten pribadi AI, termasuk MCP, sebagai pada dasarnya cacat.
Dorongan awal untuk Asisten AI pada akhir 1990-an dan awal 2000-an gagal karena agregator konten dengan integrasi vertikal dan daya beli massal terbukti lebih efektif. Ini menyebabkan munculnya platform seperti Expedia dan eBay.
Sistem multi-agen mengharuskan pemrogram untuk memengaruhi keadaan agen, tugas pemrograman yang menantang.
Batas Nilai Gratis
Keinginan untuk “peringkat hasil berdasarkan ketersediaan parkir” menyoroti masalah mengakses data di balik API berbayar atau frontend yang didukung iklan. Perusahaan tidak mungkin memberikan akses gratis ke seluruh dataset mereka melalui API.
Meskipun tidak semua perusahaan akan mengintegrasikan data mereka ke dalam agen AI, potensi untuk menggabungkan berbagai alat untuk mendukung alur kerja tetap signifikan.
Perusahaan yang memprioritaskan mempertahankan parit data kemungkinan akan menolak teknologi baru yang mengancam parit itu.
Jika booking.com memiliki API, mereka kemungkinan akan mengembalikan hasil yang sama dengan situs web mereka, mungkin dengan format JSON atau XML.
Melewati Perantara
Tidak masuk akal bagi perantara seperti booking.com untuk memungkinkan pengguna melewati layanan mereka sepenuhnya.
Namun, hotel individu mungkin merasa bermanfaat untuk melewati booking.com, perantara yang sering tidak mereka sukai.
AI Riset Mendalam dapat memindai hotel berdasarkan kriteria tertentu dan berinteraksi dengan server MCP Penemuan Hotel yang dijalankan oleh hotel individu, melewati kebutuhan untuk menavigasi antarmuka dan iklan booking.com.
Kasus Penggunaan Praktis
MCP dapat memfasilitasi tugas-tugas seperti mengambil log dari Elasticsearch atau membuat kueri database dengan cara yang lebih terstruktur.
Sifat statis dari konfigurasi server MCP, di mana server baru memerlukan pengeditan file .json dan memulai ulang aplikasi, dapat membatasi.
Model yang Disetel Halus
MCP dapat dilihat sebagai model kecil yang disetel halus yang memahami banyak alat MCP dan memilih yang tepat untuk setiap percakapan.
Menyesuaikan alat secara dinamis berdasarkan konteks mungkin diperlukan untuk skenario tertentu.
Percakapan Terbuka dan Masalah Bisnis
MCP sangat cocok untuk sistem percakapan umum dan terbuka tanpa alur yang telah ditentukan sebelumnya. Namun, ini bukan solusi satu ukuran untuk semua untuk setiap masalah bisnis. Itu tidak dimaksudkan untuk mengganti kerangka kerja seperti LangChain.
Alternatif untuk MCP, standar berbasis komunitas terbuka, adalah protokol yang terpecah, hak milik, dan terkunci vendor. Standar yang cacat tetapi berkembang lebih disukai daripada tidak ada standar sama sekali.
Cara terbaik untuk melihat MCP adalah sebagai pergeseran dari pengembang individu yang membangun pembungkus klien di sekitar API ke penyedia API atau pembungkus yang dikelola komunitas yang membangunnya. Ini menyediakan kotak peralatan yang besar, mirip dengan NPM atau PyPi. Namun, orkestrasi, keamanan, dan definisi penggunaan masih diperlukan.
Generasi Langchain berikutnya akan mendapat manfaat dari kotak alat yang lebih besar ini, tetapi inovasi masih diperlukan.
Alat Khusus Pengguna
Dalam beberapa kasus, alat mungkin khusus untuk data pengguna, seperti alat untuk mengiris dan memanipulasi file CSV yang diunggah.
Satu masalah yang sering diabaikan adalah bahwa MCP dapat memenuhi konteks model dengan terlalu banyak opsi. Prioritasi dan paparan metadata sangat penting untuk menghindari penggunaan token yang boros dan perilaku model yang tidak menentu.
Standar dan Teknologi yang Berkembang
Standar baru muncul seiring waktu, dan sudah begitu lama sejak standar benar-benar penting sehingga orang lupa bagaimana mereka berkembang.
Mengunduh program server kecil dari pengembang acak untuk menambahkan “alat” ke klien LLM bisa berisiko.
Masalah yang diajukan adalah masalah sah yang perlu ditangani oleh ekosistem MCP. Beberapa solusi akan berada dalam spesifikasi MCP, sementara yang lain akan berada di luar.
Kode Claude dan Penggunaan Dunia Nyata
Ada pendapat yang kontras tentang keberhasilan MCP. Beberapa orang telah mendengar cerita tentang perusahaan yang berintegrasi dengan MCP, sementara yang lain telah mendengar dari pengguna yang merasa kecewa.
Ini menyoroti kelemahan dari hype dan adopsi awal.
Beberapa pengembang menemukan bahwa API HTTP lebih unggul daripada MCP untuk sebagian besar kasus penggunaan. Mereka berpendapat bahwa penggunaan “alat” bermuara pada titik akhir API untuk kemampuan dan fungsionalitas.
API tidak menjelaskan sendiri secara default, yang mewakili kesempatan yang terlewatkan bagi pendukung REST dan HATEOAS untuk menampilkan pendekatan mereka.
MCP sebagai Alternatif LangChain?
MCP telah digambarkan memiliki “bau LangChain” – tidak memecahkan masalah mendesak, terlalu abstrak, dan mengalami kesulitan menjelaskan keuntungannya.
Mungkin perlu mengatakan “AKHIR BARIS” dan mengasingkan peretas wannabe ke kisi permainan!
Pertanyaan kunci adalah apakah paradigma Chatbot “umum” akan bertahan. Aplikasi khusus dengan alat mereka sendiri mungkin tidak membutuhkan MCP.
Sebaliknya, karena LLM menjadi lebih mampu, alat eksternal mungkin menjadi kurang diperlukan. Mengapa Anda menginginkan MCP untuk menjalankan Photoshop ketika LLM dapat dengan mudah mengedit gambar secara langsung?
Impian asisten robot fiksi ilmiah mungkin tidak terwujud, dan alat manipulasi bahasa khusus mungkin lebih berguna.
Basis Pengguna dan Kesadaran Keamanan
Basis pengguna MCP mencakup individu yang kurang teknis, membuat masalah keamanan sangat relevan. Meningkatkan kesadaran akan praktik terbaik keamanan sangat penting.
Mendasarkan Xops pada OpenRPC, yang mengharuskan mendefinisikan skema hasil, membantu merencanakan bagaimana output terhubung ke input, meningkatkan keandalan untuk alur kerja yang kompleks.
Teknologi ini kemungkinan akan berevolusi dan menetap seiring waktu.
Redundansi dan Infrastruktur Cloud
Beberapa orang mempertanyakan keuntungan menggunakan MCP dibandingkan standar OpenAPI, melihatnya sebagai berlebihan.
Apa yang akan digunakan LLM untuk memanggil sistem OpenAPI? Bagaimana itu akan terikat ke shell? Bagaimana host LLM akan mengatur itu?
MCP menyediakan cara terstruktur bagi LLM untuk membuat panggilan alat.
Server MCP sudah menjadi server HTTP.
Keuntungan terbesar dari MCP adalah untuk penyedia LLM seperti OpenAI, bukan pengembang aplikasi.
LLM adalah otak tanpa alat, dan panggilan alat memberdayakan mereka. Namun, dengan API normal, penyedia LLM tidak memiliki akses ke alat itu. MCP memberi mereka akses, memposisikan mereka sebagai gerbang ke AI.
CLI vs. API
Mengapa tidak menggunakan CLI secara langsung, mengingat bahwa LLM dilatih dalam bahasa alami dan CLI adalah solusi yang umum dibaca dan ditulis manusia?
MCP muncul terlalu cepat dan membutuhkan waktu untuk dewasa. Ia tidak memiliki pemeriksaan oleh badan standar konvensional dan didorong oleh hype.
Ada kekurangan aplikasi dunia nyata.
Aplikasi Utama MCP
MCP digunakan di Claude Desktop dan aplikasi obrolan AI khusus, alat otomatisasi kode, dan kerangka kerja otomatisasi agen/LLM.
Itu adalah teknologi terburu-buru lainnya yang kemungkinan akan dibuang ketika akronim hype-able berikutnya tiba.
Ada dua jenis protokol panggilan alat model bahasa: yang dikeluhkan orang dan yang tidak digunakan siapa pun.
Anthropic mengembangkan “standar” ini dalam ruang hampa, yang menyebabkan masalah keamanan.
JSON-RPC 2.0
MCP dibangun di atas JSON-RPC 2.0, protokol ringan yang memungkinkan komunikasi klien dan server menggunakan JSON.
Rasanya seperti spesifikasi terpusat yang dirancang untuk ekosistem tertentu, mengklaim universalitas tanpa menghasilkannya.
MCP cukup kuat untuk melakukan hal-hal yang berguna, yang menimbulkan masalah keamanan.
Itu bukan standar yang matang dan tidak dirancang untuk aman.
Meskipun rekomendasi ada, mereka tidak diberlakukan atau diterapkan.
Langchain dan Panggilan Alat
Langchain adalah salah satu dari banyak kerangka kerja yang mengimplementasikan pola “panggilan alat”.
MCP adalah spesifikasi untuk bagaimana informasi eksternal memasuki jendela konteks model bahasa, termasuk panggilan alat, input yang ditemplat, pembatalan, pelacakan kemajuan, dan statefulness server alat.
Ini membantu menstandarisasi detail sehingga kombinasi asisten/integrasi apa pun kompatibel.
Meskipun MCP memiliki masalah yang sah, para kritikus harus memperhalus argumen mereka.
Otentikasi sangat penting dan seharusnya tidak dihilangkan dari versi awal.
Ada terlalu banyak kompleksitas.