Model Context Protocol ( MCP ) berjanji untuk menyederhanakan cara agen AI terhubung ke tool eksternal, namun para developer mengangkat kekhawatiran serius tentang keamanan autentikasi dan degradasi performa. Meskipun MCP telah mendapat daya tarik sebagai cara standar untuk mengekspos tool kepada large language model, tantangan implementasi di dunia nyata menyebabkan beberapa pihak mempertanyakan nilai praktisnya.
Komponen Arsitektur MCP:
- Aplikasi Host: Aplikasi chat atau IDE (seperti Cursor) dengan klien MCP
- Klien MCP: Menangani komunikasi dengan server MCP
- Server MCP: Menyediakan tools, prompts, resources, atau samples
- Protokol Komunikasi: Berbasis JSON-RPC dengan autentikasi dan discovery
Mimpi Buruk Autentikasi Mengancam Adopsi Enterprise
Salah satu masalah paling mendesak yang dihadapi MCP adalah sistem autentikasi yang rusak. Developer melaporkan bahwa menyiapkan koneksi yang aman sangat kompleks dan rapuh, terutama ketika OAuth flow terlibat. Pendekatan saat ini sering kali memerlukan penyimpanan token autentikasi plaintext di lokasi yang sudah dikenal di mesin lokal, menciptakan apa yang disebut seorang developer yang sadar keamanan sebagai mimpi black hat.
Untuk pengguna enterprise, masalah autentikasi sangat merepotkan. Tim marketing yang ingin menggunakan server MCP Google Analytics menghadapi tugas yang menakutkan untuk menavigasi setup Google Cloud dan berbagi kredensial service account - sebuah proses yang begitu kompleks sehingga secara efektif menghalangi pengguna non-teknis dari adopsi.
Kekacauan autentikasi telah menyebabkan perpecahan dalam komunitas. Beberapa developer mendorong server MCP remote yang berjalan dalam container terisolasi dengan manajemen identitas yang tepat, sementara yang lain tetap dengan implementasi lokal meskipun ada risiko keamanan. Fragmentasi ini merusak tujuan MCP untuk menciptakan standar universal.
Masalah Utama MCP yang Teridentifikasi:
- Autentikasi: Token plaintext disimpan di lokasi yang sudah dikenal umum
- Performa: Definisi tool menghabiskan ruang context window yang berharga
- Kompleksitas: Pengaturan OAuth memerlukan keahlian teknis untuk penggunaan enterprise
- Tool Overload: Semakin banyak tool yang tersedia dapat menurunkan kualitas pengambilan keputusan AI
- Discovery: Semua tool diekspos di awal terlepas dari relevansinya
Kelebihan Tool Menurunkan Performa AI
Penemuan mengejutkan di antara developer AI adalah bahwa lebih banyak tool tidak selalu berarti performa yang lebih baik. Ketika agen memiliki akses ke puluhan atau ratusan tool melalui MCP , pengambilan keputusan mereka justru menjadi lebih buruk. Masalah ini berasal dari keterbatasan context window - setiap definisi tool mengambil ruang berharga yang bisa digunakan untuk percakapan aktual atau informasi spesifik tugas.
Hanya dengan membuat lebih banyak tool tersedia dapat memberikan agen lebih banyak kemampuan, tetapi hal itu dapat dengan mudah merusak performa.
Degradasi performa ini telah memaksa developer untuk secara manual mengkurasi tool mana yang dapat diakses agen mereka, mengalahkan sebagian besar kemudahan yang dijanjikan MCP . Beberapa beralih ke solusi gateway yang memfilter dan menyusun tool sebelum menyajikannya kepada AI , menambahkan lapisan kompleksitas lain pada apa yang seharusnya menjadi protokol yang menyederhanakan.
Proses penemuan tool dalam MCP juga berkontribusi pada masalah ini. Ketika sistem AI terhubung ke server MCP , ia menerima informasi tentang semua tool yang tersedia di muka, terlepas dari apakah mereka relevan dengan tugas saat ini. Ini menciptakan masalah rasio signal-to-noise yang menurunkan kemampuan AI untuk fokus pada pekerjaan yang sebenarnya.
Komunitas Mempertanyakan Proposisi Nilai Inti MCP
Di luar masalah teknis, developer mempertanyakan apakah MCP memecahkan masalah nyata. Banyak yang menunjukkan bahwa REST API yang ada dengan dokumentasi OpenAPI sudah menyediakan penemuan tool dan antarmuka standar. Lapisan MCP tambahan tampak berlebihan ketika model AI sudah dapat bekerja dengan JSON schema dan HTTP endpoint.
Model server MCP lokal, di mana developer mengunduh dan menjalankan server tool di mesin mereka, terasa sangat dipertanyakan oleh banyak orang. Untuk fungsi sederhana seperti mendapatkan tanggal saat ini atau melakukan panggilan API , mengimpor paket tool tampak lebih mudah daripada menjalankan proses server terpisah.
Beberapa developer melihat masa depan MCP dalam organisasi besar di mana tim yang berbeda perlu mengekspos keahlian domain mereka ke sistem AI seluruh perusahaan. Dalam skenario ini, MCP dapat menyediakan pemisahan kepentingan yang memungkinkan tim backend memiliki definisi tool mereka sementara tim frontend membangun antarmuka AI . Namun, kasus penggunaan enterprise ini sebagian besar tetap teoretis.
Pendekatan Alternatif yang Disebutkan:
- REST APIs Langsung: Menggunakan endpoint HTTP yang sudah ada dengan dokumentasi OpenAPI
- Impor Paket: Menyertakan definisi tool sebagai pustaka kode
- Solusi Gateway: Memfilter dan menyusun tool sebelum akses AI
- Implementasi Kustom: Membangun pemanggilan tool tanpa standarisasi MCP
 |
|---|
| Menjelajahi kompleksitas dan redundansi Model Context Protocol dalam penemuan alat dalam sistem AI |
Jalan ke Depan Masih Tidak Jelas
Meskipun ada kritik, MCP tidak tanpa pembela. Pendukung berargumen bahwa seperti USB , MCP mungkin berevolusi melampaui kasus penggunaan yang berfokus pada AI aslinya untuk menjadi protokol integrasi tujuan umum. Fondasi JSON-RPC dan mekanisme penemuan bawaan dapat membuatnya berguna untuk komunikasi sistem-ke-sistem bahkan tanpa keterlibatan AI .
Keuntungan terbesar protokol ini mungkin adalah timingnya. Ketika pemanggilan tool AI menjadi lebih umum, memiliki standar apa pun lebih baik daripada lanskap implementasi kustom yang terfragmentasi saat ini. Namun, masalah autentikasi dan performa memerlukan solusi sebelum MCP dapat mencapai adopsi enterprise yang luas.
Untuk saat ini, developer tampaknya mengambil pendekatan wait-and-see. Mereka yang membangun aplikasi AI sederhana sering melewatkan MCP sepenuhnya, sementara organisasi yang lebih besar bereksperimen dengan solusi gateway untuk mengatasi keterbatasan saat ini. Kesuksesan protokol kemungkinan akan bergantung pada apakah masalah fundamental ini diselesaikan dalam versi mendatang.
Referensi: An LLM does not need to understand MCP