Menelaah MCP secara kritis

• MCP(Model Context Protocol) menyediakan cara integrasi yang terstandarisasi agar LLM dapat berinteraksi dengan dunia luar
• Belakangan ini standar serupa seperti ACP dari IBM dan A2A dari Google bermunculan, sementara implementasi MCP dan alat terkait juga bertambah dengan cepat
• Namun, praktik engineering yang belum matang seperti kebingungan desain, dokumentasi yang kurang, dan minimnya spesifikasi protokol yang nyata disebut sebagai masalah
• Metode transport yang saat ini diusulkan seperti HTTP+SSE dan Streamable HTTP justru menambah kompleksitas dan isu keamanan, sehingga penggunaan WebSocket direkomendasikan sebagai alternatif
• Protokol terbaru juga menambahkan kompleksitas berlebihan dan inkonsistensi dalam otorisasi dan manajemen sesi

---

Tinjauan MCP dan perkembangan terbaru

• MCP adalah protokol terbuka yang dibuat untuk menstandarkan cara aplikasi menyediakan konteks kepada large language model (LLM)
• Dalam sebulan terakhir, MCP muncul sebagai standar kunci untuk menjadikan LLM sebagai agen, dan penggunaannya serta implementasinya menyebar sangat cepat
• Standar yang lebih ortodoks dengan tujuan serupa juga bermunculan cepat, seperti ACP dari IBM dan A2A dari Google

Masalah praktik engineering dan spesifikasi protokol

• Tingkat implementasi nyata dan dokumentasinya yang rendah terlihat di banyak tempat
• Perusahaan teknologi besar menginvestasikan dana sangat besar untuk pelatihan model, tetapi SDK dan dokumentasi mereka berkualitas rendah sehingga menimbulkan kebingungan bagi pengguna
• MCP juga menunjukkan masalah serupa, dengan sebagian desain yang tidak masuk akal serta kekurangan spesifikasi, contoh, dan panduan

Pembahasan protokol transport

Metode transport stdio

• Stdio adalah cara tradisional yang menghubungkan server dan klien MCP secara lokal melalui pipe(stdout, stdin) secara langsung
• Metode ini memiliki lebih sedikit penanganan socket yang rumit maupun isu spesifik OS, dan memungkinkan konfigurasi lingkungan yang ringkas seperti variabel lingkungan serta stream input/output

Metode HTTP+SSE / Streamable HTTP

• Dengan niat untuk menyesuaikan diri pada era web, metode HTTP+SSE dan Streamable HTTP diadopsi agar juga mendukung basis HTTP
• Namun, meski ditujukan sebagai pengganti WebSocket, pendekatan ini justru memicu lebih banyak ambiguitas, kebingungan desain, dan kompleksitas
• Karena satu sesi dan koneksi dapat dibuat atau diakhiri melalui beberapa cara, hal ini menjadi beban besar bagi server dari sisi manajemen status dan keamanan

Kesulitan dalam contoh implementasi server/klien MCP

• Dukungan yang kurang memadai di berbagai bahasa sangat menonjol, termasuk ketiadaan SDK Go resmi
• Karena dokumentasi dan spesifikasinya tidak jelas, dalam banyak kasus implementasi nyata harus dilakukan melalui reverse engineering
• Meski server contoh kebanyakan berbasis Python, JavaScript, penerapannya di lingkungan kerja nyata sulit karena isu dependensi dan portabilitas
• Saat mengimplementasikan server, SSE/Streamable HTTP berusaha menyamar sebagai socket, tetapi pada praktiknya sulit mempertahankan sesi dan status koneksi secara konsisten, serta memerlukan infrastruktur tambahan seperti message queue

Struktur dan masalah HTTP+SSE serta Streamable HTTP

Mode HTTP+SSE

• Klien membuka sesi SSE dengan server, lalu saat melakukan permintaan tulis ke endpoint terpisah, server mengembalikan respons 202 dan mengirimkan jawaban melalui koneksi SSE yang sudah ada
• Diperlukan sinkronisasi koneksi sesi dan pemeliharaan status, tetapi proses ini juga kurang terdokumentasi dan kompleksitas operasionalnya sangat tinggi

Mode Streamable HTTP

• Pembuatan sesi, pembukaan SSE, dan pengiriman respons semuanya bercampur dalam berbagai cara sehingga alur satu permintaan~respons tidak konsisten
• Berbagai bentuk manajemen status, endpoint, dan header bercampur sehingga menimbulkan hambatan serius bagi implementasi nyata dan skalabilitas

Implikasi umum

• Seiring meningkatnya kompleksitas teknis, beban kognitif dan pemeliharaan bagi pengembang ikut membesar, dan di antara berbagai implementasi server/klien muncul masalah ketidakcocokan kompatibilitas serta perilaku yang tak dapat diprediksi
• Server harus melacak semua status dan kondisi koneksi, dan di lingkungan terdistribusi, penskalaan yang efisien serta sinkronisasi status menjadi jauh lebih sulit

Implikasi keamanan

• Cara koneksi/sesi yang sangat beragam dan terperinci meningkatkan kerentanan keamanan manajemen status seperti session hijacking, replay attack, dan denial of service (DoS)
• Banyaknya titik masuk dan cara merespons memperluas permukaan serangan, serta memungkinkan aktivitas berbahaya disamarkan melalui alur yang tidak diinginkan

Kebingungan dalam protokol manajemen otorisasi

• Spesifikasi saat ini menerapkan aturan yang tidak konsisten, misalnya OAuth2 hanya diwajibkan saat menggunakan transport HTTP, sementara transport STDIO secara bebas memakai variabel lingkungan
• Muncul kebingungan dan ketidakwajaran, seperti mengapa hanya transport HTTP yang dipaksa menerapkan OAuth2 yang rumit

Usulan perbaikan

• Perlu penyederhanaan ke satu protokol JSON RPC, dengan metode transport yang pada dasarnya hanya berfokus pada Stdio dan WebSocket
• Pendekatan yang diinginkan adalah memetakan variabel pada lingkungan Stdio ke header di lingkungan HTTP, serta input dan output masing-masing ke stream dua arah milik WebSocket
• Dengan begitu, pelacakan sesi yang tidak perlu, manajemen status, dan banyak penanganan kasus pengecualian bisa dihilangkan
• WebSocket seharusnya menjadi pilihan standar untuk semua transport berbasis HTTP, dan juga dapat menyelesaikan isu sinkronisasi status yang rumit

Perbandingan dengan protokol alternatif dan tren pasar

• ACP dari IBM dan A2A dari Google menawarkan desain transport yang lebih ringkas dan fungsi penemuan agen dari sisi interoperabilitas agen
• Namun pada dasarnya, kebanyakan masih berada pada tingkat yang dapat diintegrasikan sebagai alat terpisah di dalam lingkungan pembangunan MCP
• Fenomena terus munculnya protokol baru berisiko mengarah pada banjir standar, sehingga memprioritaskan kesederhanaan transport penting bagi pertumbuhan industri

[GN⁺]

Komentar Hacker News

• Saya yakin alasan dokumen yang ditulis vendor LLM membingungkan adalah karena mereka memang memakai LLM untuk menulis dokumen itu sendiri, dan ini pendekatan yang sangat buruk; terutama untuk pekerjaan spesifikasi, memakai LLM jauh lebih buruk daripada sekadar memakainya untuk menulis dokumentasi yang baik. Proses menulis spesifikasi itu sendiri adalah bagian yang inti, dan penting bagi desainer manusia untuk dengan cermat menemukan cacat, kekurangan, dan menangani berbagai kasus, tetapi pada spesifikasi MCP saya tidak melihat banyak jejak perenungan manusia semacam itu. Gaya datarnya yang khas, penyampaiannya yang berantakan, dan susunannya yang didominasi daftar benar-benar terasa seperti hasil tulisan LLM
  • Dokumen DeepSeek justru bermasalah karena sangat banyak kesalahan ejaan dan tata bahasa. Aneh sekali perusahaan seperti itu, yang setiap hari bergelut dengan bahasa dan bahkan pernah memiliki LLM bahasa Inggris terbaik di dunia, tetap tidak mampu menghasilkan dokumen yang terlihat profesional secara pekerjaan
  • Saya juga sangat merasa spesifikasi ini ditulis oleh LLM; semua buktinya mengarah ke sana. Saya menduga sebagian besar produk sekarang dibuat untuk IPO, agar bisa dipamerkan ke investor sebagai sesuatu yang sudah dibangun dengan cara merata-ratakan hasil yang paling masuk akal
  • Kalau itu benar, sungguh disayangkan. Anthropic punya banyak orang pintar, jadi sangat mengecewakan jika hal seperti ini terjadi pada komponen inti dari ekosistem yang penting
  • Baru sekarang saya terpikir bahwa vendor AI coding punya insentif untuk sengaja membuat dokumentasi sulit dipahami: menciptakan kode yang tidak bisa dimengerti manusia dan hanya bisa ditafsirkan oleh AI mereka, sehingga pengguna sepenuhnya bergantung pada layanan AI khusus mereka. Jika dalam dua tahun mereka gagal benar-benar menggantikan programmer sungguhan, strategi ini justru akan melenyapkan seluruh konsumen dan menghancurkan pasar mereka sendiri. Yang tersisa pada akhirnya hanya tumpukan kode raksasa yang tidak bisa diterjemahkan balik antara manusia dan AI
  • Ternyata bukan cuma saya yang kehilangan fokus saat membaca prosa hasil tulisan LLM; tulisan mesin yang repetitif dan tanpa konteks seperti ini tidak mengandung pemikiran yang dalam dan makin lama bahkan menimbulkan kelelahan emosional. Ketika LLM seperti ini sampai menulis spesifikasi teknis, pada akhirnya akan terselip isi yang bahkan tidak dipahami penulisnya sendiri secara tidak sadar. Ini yang makin saya khawatirkan
  • Dokumen DeepSeek secara umum tampak tidak terlalu buruk. Memang terlihat seperti dibuat cepat-cepat, tetapi levelnya masih lumayan. Itu berarti mungkin ada pengecualian terhadap logika bahwa semua dokumentasi yang ditulis LLM pasti buruk
• Belakangan bidang LLM terasa meniru paradigma perangkat lunak dengan sangat cepat seolah memakai cheat code. Cara mengekspos fungsi jarak jauh sudah punya banyak contoh di masa lalu seperti DLL, gRPC, SOAP, IDL, dCOM, tetapi kubu LLM saat ini tampaknya bahkan hampir tidak sadar bahwa semua itu pernah ada. Saya berharap seiring waktu hal ini akan menjadi lebih matang, tetapi pekerjaan rumah yang tersisa tetap harus diselesaikan
  • Beberapa bulan lagi pasti akan lebih matang, tetapi kalau melihat ekosistem Python awal dulu, saya jadi teringat bagaimana kesalahan-kesalahan menetap di lapisan bawah stack lalu semua orang menumpuk alat baru di atasnya. Kali ini lebih menyedihkan lagi karena sejarah kesalahan yang sama di masa lalu sebenarnya sudah ada, tetapi ekosistem AI tetap bergerak ke arah yang sama
  • Saat pertama melihat MCP, saya langsung teringat COM/DCOM, dan juga DLL Hell zaman dulu. Saya akan terus melihat bagaimana MCP berkembang nanti
  • Saya masih belum menemukan penjelasan yang membuat saya paham apa sebenarnya MCP itu, dan saya penasaran dalam istilah bahasa pengembangan lama, ini seharusnya disebut apa
  • Saya ingin menyoroti bahwa dalam protokol yang ketat dan deklaratif seperti ini, ruang makna potensial dan kekuatan semantik LLM justru hilang. Mungkin akan lebih intuitif kalau cukup meletakkan file agents.json di web root lalu para agen menyelesaikannya sendiri melalui percakapan semantik secara otomatis. Hasilnya, HTTP menjadi standar input/output agen
  • Saya rasa semua contoh yang diajukan tadi memang tepat
  • Saya penasaran apakah MPC berbasis JSON-RPC
• Saya setuju dengan keseluruhan isi tulisan ini, terutama pengalaman membingungkan saat tidak bisa menemukan informasi yang benar-benar berguna di situs MCP. RFC memang sulit dibaca, tetapi tetap jauh lebih baik daripada pendekatan “pakai SDK saja”
  • Saya berharap lebih banyak orang menyadari pentingnya blog ini. Sebaiknya berhenti sejenak mengadopsi MCP dan lihat lagi apakah fondasi teknisnya benar-benar kokoh. Antusiasmenya memang besar, tetapi ketika benar-benar masuk lebih dalam ke tahap implementasi, orang akan kecewa. Pada fungsi intinya, berbagai keputusan seperti WebSocket pun terasa meragukan, dan meskipun tidak semuanya, ada kesan ini dibuat terburu-buru sebagai semacam solusi sementara
  • Sangat disayangkan tidak ada spesifikasi yang jelas di situsnya. Rasanya setengah spesifikasinya seperti dihasilkan oleh Sonnet, dan cara kerja protokol yang sebenarnya tidak dijelaskan dengan terang. Sebagai perbandingan, spesifikasi GraphQL ditulis jauh lebih baik
• Saat ini sebagian besar pekerjaan di bidang AI dikerjakan terutama oleh matematikawan, ilmuwan (data), mahasiswa, dan penggemar amatir, dan banyak yang belum cukup matang sampai dari standar software engineer profesional terlihat seperti proyek akhir pekan
  • Saya sendiri merasa software engineer profesional sebenarnya memang mengerjakan banyak dari pekerjaan itu
• MCP sejak awal seharusnya memakai stateless HTTP. Sebagian besar server tidak memerlukan state, dan cukup menyimpan state secara global atau hanya memiliki pengenal sesi
  • Saya tidak paham struktur interaksi MCP yang sebenarnya; saya ingin tahu mengapa tidak stateless, dan kenapa koneksi harus dibiarkan tetap terbuka
  • Pengalaman saya sendiri tidak banyak, tetapi jika koneksi ditutup setelah permintaan, maka untuk permintaan berikutnya harus tersambung lagi. Apakah sesi sebaiknya tetap dibuka atau ditutup tergantung pada berbagai variabel seperti pola penggunaan dan pemakaian memori
• Saya sedang membuat layanan MCP berbasis Ruby on Rails bernama ninja.ai, yaitu app store untuk memasang server MCP hanya dengan satu klik. Server Model Context Protocol dipasang di perangkat klien memakai Tauri, dan saya juga menyediakan server MCP cloud dengan Rails. Saya kritis terhadap fitur HTTP+SSE maupun Streamable HTTP; untuk komunikasi real-time dua arah, WebSockets lebih baik, dan dukungan SSE di Rails terbatas sehingga saya akhirnya memigrasikan endpoint ke web server Falcon. Saya penasaran mengapa engineer Shopify memilih Streamable HTTP, mungkin karena keterbatasan infrastruktur/deployment. Perlu juga diperhatikan bahwa lapisan transport MCP memang diabstraksikan, jadi implementasi masa depan tetap sangat terbuka untuk mengadopsi WebSockets atau WebRTC
• Saya adalah operator salah satu registry MCP (glama.ai/mcp/servers). Saya setuju sebagian dengan penulis, tetapi protokol ini masih pada tahap sangat awal sehingga ke depan bisa banyak berubah. Minatnya jauh lebih besar daripada perkiraan; dari yang semula hanya puluhan server pada tahap sangat dini, tiba-tiba tumbuh menjadi ribuan server, tetapi yang benar-benar berfungsi hanya sebagian, jadi saya menghabiskan banyak waktu untuk menyaringnya terus-menerus. Ini terjadi karena MCP mendapat perhatian publik sebelum sempat matang. Namun belakangan, ekosistem seperti framework kode, registry, dan klien yang mendukung MCP tumbuh dengan kecepatan yang mengejutkan. Perubahan sebesar ini hanya dalam setengah tahun nyaris belum pernah terjadi. Jika tren ini berlanjut, saya rasa prospeknya cerah, dan saya juga menyediakan kumpulan materi yang berguna bagi orang yang baru mulai
  • Jika melakukan kesalahan pada tahap awal desain protokol, kesalahan itu harus dibawa selamanya, jadi spesifikasi harus disusun dengan rendah hati. Struktur ala Goldberg seperti SSE bisa saja tidak pernah sempat diperbaiki lalu tertinggal permanen. Di level enterprise, perubahan yang merusak kompatibilitas protokol tidak mudah dilakukan, jadi kita bisa terjebak lama pada keputusan awal tanpa bisa mengubahnya
  • Untuk protokol MCP sendiri, ya wajar kalau ia akan terus berkembang seiring waktu. Justru lebih aneh kalau sejak awal mengharapkan kesempurnaan. Yang paling penting, standarisasi API agentic ini benar-benar perubahan yang kuat. Kalau menulis dan menerapkan kodenya sendiri, lalu AI langsung mengenalinya dan bisa memakainya secara otomatis, sensasinya baru benar-benar terasa setelah mencobanya sendiri
  • Kekhawatiran saya adalah, dengan kecepatan seperti ini, jangan sampai mcp terlalu cepat menerima desain lapisan transport yang seharusnya bertahan lama. Ini mengingatkan pada kasus seperti perang browser era 90-an, ketika perpecahan standar tidak selesai dalam waktu lama, seperti IE11 yang bertahan terlalu lama
• Kontroversi terkait otentikasi sudah sedang diperbarui. Bersama Anthropic dan komunitas keamanan, pemisahan peran resource server (RS) dan authorization server (AS) di MCP sudah diimplementasikan. Untuk sementara, draf spesifikasi dipublikasikan sebelum versi protokol baru diformalkan
  • Saya penasaran berapa persen dari spesifikasi MCP yang merupakan keluaran LLM. Saya ingin tahu apakah saya menangkapnya secara naluriah karena terus melihat tanda-tanda peringatan
  • Posisi saya lumayan netral, tetapi ini terasa seperti cuma menyalin kasar draf OAuth, dan saya tidak suka bahwa ketika memakai HTTP, strukturnya jadi wajib diikuti tanpa pilihan. Sebenarnya ini bisa dirapikan dengan lebih jelas agar klien dan server masing-masing secara opsional bisa mendukung OAuth2 atau tidak
• Terkait rilis Streamable HTTP untuk MCP, saya pernah mengajukan isu apakah semuanya tidak bisa dijadikan sekadar permintaan HTTP biasa. Spesifikasi MCP memang menjanjikan sebagai solusi umum untuk menghubungkan LLM dan tool, tetapi dalam praktiknya ia menghadapi banyak kesulitan seperti autentikasi, streaming, perintah kustom per tool, dan verifikasi keandalan tool. Saya melihat integrasi hanya dengan REST API justru lebih sederhana. OpenAI dan Gemini juga sudah mengatakan akan mengadopsi MCP, tetapi saya memperkirakan spesifikasi ini akan segera terbentur ketidakcocokan pada hal-hal seperti UI atau lapisan interaksi yang sebenarnya tidak diinginkan, sehingga muncul masalah seperti tidak cocok dengan brand atau autentikasi yang dibajak
  • Meskipun Anthropic yang membangun MCP, skalanya tetap jauh lebih kecil dibanding ChatGPT. Saya ragu perusahaan besar seperti OpenAI atau Google akan lama-lama menerima spesifikasi yang ditetapkan satu tim eksternal untuk membatasi pengalaman pengguna. Dulu ada preseden seperti ChatGPT Plugins yang gagal bukan karena engineering-nya tidak keren, tetapi karena batasan pengalaman konsumennya. Meski begitu, saya tetap bersedia berharap pada kekuatan komunitas yang kuat
  • Setelah menulis blog itu, saya juga pernah meninggalkan isu serupa secara langsung. Karena ini sangat penting, saya merasa kalau sampai salah langkah akan sulit untuk dibalikkan
• Saya heran mengapa MCP bisa begitu populer, tetapi bagaimanapun ini sedang jadi tren. Dibanding spesifikasi OpenAPI, saya ingin mendengar penjelasan tentang sisi mana MCP lebih baik
  • Menurut saya, sebagian besar popularitas MCP berasal dari fakta bahwa kegunaan tool pada LLM belakangan ini memang benar-benar membaik. Plugin OpenAI pada 2023 gagal karena saat itu LLM belum cukup bisa diandalkan untuk menggunakan tool, sedangkan MCP datang pada timing yang jauh lebih tepat
  • Faktor besar lainnya adalah memulai server MCP itu sangat mudah dan hambatan masuknya rendah. Ketika tool bertambah banyak, teks yang dikirim ke LLM juga bertambah; tetapi jika menyediakan OpenAPI, lalu mengirim detail setiap path dan pesan deskripsi, Claude pun sebenarnya bisa terintegrasi dengan sangat baik
  • Salah satu alasan MCP penting adalah karena OpenAPI merupakan dokumen statis sehingga LLM harus bertanggung jawab atas seluruh proses pembuatan request, sedangkan server MCP mengurangi beban itu lewat abstraksi. Hasilnya, dari sudut pandang LLM, MCP jadi lebih mudah, lebih cepat, dan lebih aman
  • Saya tidak menganggap MCP sempurna, tetapi memang ada beberapa sisi yang lebih cocok untuk LLM daripada OpenAPI. Pertama, tool MCP bisa dispesifikasikan jauh lebih singkat dan sederhana, sedangkan spesifikasi OpenAPI terlalu besar sehingga memakan konteks LLM secara berlebihan. LLM pada dasarnya tidak benar-benar membuat pemanggilan, melainkan hanya menghasilkan teks output, jadi pendekatan MCP terasa lebih alami. Selain itu, MCP jauh lebih fleksibel terhadap struktur yang dinamis seperti penambahan atau perubahan tool, sehingga keterbatasan statis OpenAPI bisa diatasi. Tentu masalahnya juga nyata, terutama lapisan transport yang masih punya banyak ruang untuk diperbaiki, tetapi library utamanya pun diimplementasikan dengan cukup baik