Kedatangan Web 2.0 2.0: MCP

• Model Context Protocol (MCP) diadopsi dengan cepat dan muncul sebagai standar terbuka baru
• Nilai inti MCP bukan pada kesempurnaan, melainkan pada keterbukaan dan interoperabilitas
• Makna sejati Web 2.0 bukanlah platform tertutup, melainkan API terbuka dan berbagi data
• Muncul arus balik dari era yang serba tertutup menuju nilai web terbuka
• Adopsi MCP memunculkan kemungkinan bahwa para pengembang akan semakin menuntut kendali platform dan transparansi

---

MCP: Munculnya web terbuka yang baru

Dalam beberapa bulan terakhir, minat para pengembang terhadap Model Context Protocol (MCP) meledak. Titik awalnya adalah ketika Anthropic pada 2023 merancangnya agar sistem LLM (Claude) miliknya dapat berinteraksi dengan berbagai aplikasi. Setelah itu, OpenAI mendukung protokol yang sama di ChatGPT dan MCP pun dengan cepat memantapkan diri sebagai standar. Kini, adopsinya juga meluas ke platform besar, termasuk Windows.

Hal yang menarik adalah kekuatan MCP tidak terletak pada kejelasan atau tingkat kematangannya, melainkan pada kemudahan penggunaan dan kecepatannya. Berbeda dari standar tradisional yang dirancang secara ketat, MCP adalah spesifikasi yang agak ambigu dan didefinisikan secara longgar, tetapi justru itulah yang membuatnya efektif di dunia nyata. Yang terpenting, statusnya sebagai protokol terbuka yang bisa dimanfaatkan siapa saja menjadikannya semakin penting.

Makna sebenarnya dari web terbuka

Dalam dunia web nyata, kemajuan sejati justru terjadi ketika standar yang tidak sempurna dan sedikit serba kurang diadopsi dengan cepat. Arus seperti inilah yang melahirkan inovasi seperti "dengarkan di mana pun Anda biasa menikmati podcast".

Semangat Web 2.0 mengarah pada ekosistem terbuka melalui API terbuka, berbagi data, serta meningkatnya kendali bagi pengguna dan pengembang. Penting untuk diingat bahwa platform tertutup seperti Facebook justru merupakan pihak yang mematikan Web 2.0. Dulu, Flickr, del.icio.us, Upcoming dan lainnya memimpin budaya yang menekankan berbagi dan keterhubungan, sementara diskusi tentang standar terbuka untuk API/protokol berlangsung aktif di platform seperti live blog.

Kebangkitan kembali keterbukaan

Setelah satu generasi berlalu, kini harapan terhadap interoperabilitas kembali menguat. Di masa lalu, pengalaman API yang diblokir dan layanan yang menghilang akibat kebijakan tertutup perusahaan teknologi besar terus berulang. Misalnya, alat analisis data jejaring sosial yang dibangun penulis akhirnya harus dihentikan karena API platform diblokir. Kebijakan semacam ini meruntuhkan visi Web 2.0 tentang data terbuka dan kompatibilitas. Akibatnya, masalah seperti ketidakmampuan melakukan embed konten dan terhambatnya portabilitas data menjadi hal yang lumrah.

Namun, dengan hadirnya MCP, ada harapan bahwa AI akan menjadi pemicu kebangkitan kembali kemampuan untuk diprogram dan keterbukaan. Ketika banyak platform mengadopsi protokol yang sama, terbuka peluang terciptanya siklus positif yang didorong fondasi teknis bersama.

Ketika platform menerima protokol apa adanya dan setia pada standardisasi, perubahan positif dapat terjadi di seluruh ekosistem. Penulis menekankan bahwa ambisi pengembang untuk "membuat sesuatu yang lebih baik daripada spesifikasi" justru secara paradoks dapat merugikan ekosistem. HTML dan lainnya juga bukan spesifikasi yang sempurna, tetapi pada akhirnya menjadi fondasi interoperabilitas internet dalam skala besar.

Pentingnya kepatuhan terhadap standar

Generasi pengembang baru sedang mengalami langsung betapa kuatnya inovasi berbasis protokol dan format yang sama. Pengalaman ini kemungkinan besar akan mendorong lahirnya kembali keterikatan kuat pada standar terbuka. Suasananya mirip dengan masa ketika format terbuka seperti RSS, Podcast, OpenID, OAuth, dan OpenSocial benar-benar memberi daya kepada pengguna.

Saat ini, ini bukan lagi domain eksklusif perusahaan besar; komunitas pengembang dan pengguna dapat menggunakan hak tuntut mereka sendiri. Semua orang harus bisa menuntut kendali atas pengalaman dan transparansi dari platform, dan ketika standar terbuka seperti MCP diadopsi, transparansi atas cara kerja internal platform dan pemanfaatan data harus menyertainya. MCP memang terbuka, tetapi masih kurang dalam hal mekanisme internal dan isu keamanan, sehingga perbaikan lanjutan tetap diperlukan.

Potensi kebangkitan semangat Web 2.0

MCP bukan solusi ajaib yang menyelesaikan semua masalah, tetapi tampaknya bisa menjadi pemicu kebangkitan kembali ekosistem terbuka ala era Web 2.0. Keterbatasan seperti berlebihan dalam diskusi AI dan kurangnya kritik tetap ada.

Namun, terutama di kalangan pengembang muda, nilai web yang dapat diprogram dan lepas dari sifat tertutup sedang kembali mendapat sorotan. Web bukan milik segelintir perusahaan raksasa, melainkan ruang terbuka yang bisa dimanfaatkan setiap orang dengan cara yang mereka inginkan, dan MCP dinilai berpotensi menghidupkan kembali filosofi tersebut.

[GN⁺]

Opini Hacker News

• Ada pandangan bahwa banyak orang cenderung melewatkan inti MCP yang cocok untuk software enterprise; karena LLM dapat berperan sebagai lapisan perantara yang fleksibel, semacam penerjemah universal yang menyambungkan sistem-sistem yang sulit dihubungkan satu sama lain, adopsi server MCP juga benar-benar sedang aktif terjadi di industri B2B SaaS, dan di dalam perusahaan sendiri juga makin banyak diskusi untuk menyesuaikan batasan atau struktur sesuai pola penggunaan API, serta ada pendapat bahwa meskipun protokol ini belum “enterprise ready” dalam banyak arti, itu tidak terlalu penting, karena dalam sejarah standar sering ada spesifikasi yang belum rapi atau agak “berantakan” tetapi tetap diadopsi jika sesuai dengan kebutuhan pasar
  • MCP dipahami terasa seperti RPC yang berjalan pada koneksi panjang dan umumnya berbasis WebSocket, dan secara pribadi RPC dianggap lebih mudah karena, pertama, mengurangi perdebatan yang tidak perlu dalam desain endpoint REST seperti apakah seluruhnya diganti dengan POST atau hanya field tertentu diubah dengan PUT, dan kedua, LLM tidak perlu memahami istilah/semantik REST, cukup melihat metode RPC lalu langsung memanggilnya, yang pada akhirnya menjadi dua keunggulan besar
  • Dari sudut pandang perusahaan, MCP layak dicatat sebagai model bisnis yang sangat bagus, karena setiap permintaan data langsung terhubung dengan eksekusi LLM berbayar; di sisi lain, tetap ada rasa sayang karena dengan adopsi MCP belum ada optimasi seperti negosiasi skema yang bisa membuat kueri di masa depan menjadi lebih murah
  • REST dan OpenAPI sebenarnya sudah ada dan secara bawaan mendukung hal seperti self-discovery, dan ada keyakinan bahwa perusahaan yang menyediakan MCP pun pada akhirnya akan tetap menyediakan API yang baik
  • Ini benar-benar terasa relatable: di perusahaan besar ada banyak engineer yang fokus penuh mengerjakan hal keren dari jam 9 sampai 5 lalu sama sekali tidak memikirkan kantor setelah pulang, sehingga dari sisi perusahaan, hasil yang paling masuk akal adalah menangkap peluang untuk memaksimalkan produktivitas karyawan selama jam kerja saja
• Ada rasa penasaran berapa lama lagi sampai muncul eksperimen mengendalikan makhluk seperti kecoak dengan server MCP; kenyataannya selama lebih dari 10 tahun terakhir sudah ada banyak contoh seperti eksperimen robo-roach dan kecoak cyborg
• Dulu para developer Unix menulis dokumen spesifikasi dengan sangat ketat, tetapi zaman berubah, dan ada pendapat bahwa kelelahan terhadap kekakuan serta sifat extensible ini menjadi salah satu penyebab gagalnya arsitektur berbasis XML; saat itu ada arsitektur yang terlalu rumit seperti XSL, XHTML, XSD, WSDL, RDF, RSS, dan pada akhirnya latar belakang itulah yang membuat format sederhana seperti JSON menjadi populer, tetapi belakangan juga terlihat tren pemanfaatan XML kembali meningkat, terutama terasa dari seringnya teks terstruktur seperti XML atau Markdown dipakai dalam system prompt LLM seperti Anthropic, namun model MCP dianggap keliru: alih-alih menyuruh model untuk "menarik" informasi, pendekatan yang lebih baik dinilai adalah model "mendorong", yaitu memberi konteks lebih dulu
  • Hal yang menarik, saat membuat bahasa ekstensi makro berbasis JSON baru-baru ini, ternyata rasanya seperti menemukan kembali XSLT atau XPath, dan dari situ ada pengalaman mengagumi spesifikasi XPath yang sangat unggul untuk penelusuran graph; dengan tool seperti BaseX, XML arbitrer bisa dimasukkan ke DB lalu dikueri dengan XPATH/XQUERY, yang sangat berguna, dan jika ingin membuat antarmuka data yang andal untuk mencegah halusinasi LLM, solusi terbaik dianggap adalah memasukkan XML schema ke system prompt lalu membiarkan model menghasilkan kueri data
  • Ada keraguan sejauh mana “model yang lebih dulu mendorong konteks” bisa menangani masalah di dunia nyata; jika pengguna sudah tahu informasinya lebih dulu, mereka akan langsung menyelesaikan masalahnya sendiri, dan terasa bahwa sebagian besar permintaan terhadap MCP adalah kebutuhan seperti “tolong proses kueri tanpa saya harus belajar cara menghubungkan 15 sumber”
  • LLM memang pandai menangani XML berbentuk tag, tetapi kenyataannya kebanyakan yang dipakai bukan potongan XML yang benar-benar proper (dimulai dengan <?xml version="1.0" encoding="UTF-8"?>, namespace, schema, dan seterusnya), melainkan sekadar kumpulan tag bergaya SGML
  • Ingin ditekankan bahwa alasan sebenarnya semantic web gagal adalah karena tidak berhasil menyisipkan iklan atau terhubung dengan model bisnis
  • Ada sikap kritis terhadap pendekatan “push context”; karena kapasitas pemrosesan konteks LLM (context window) sangat terbatas, yang optimal justru menyampaikan hanya informasi yang benar-benar diperlukan seminimal mungkin, dan ketika tiap model bisa memilih sendiri konteks yang dibutuhkannya lalu melakukan pull, kemungkinan untuk mengatasi keterbatasan itu jauh lebih besar
• MCP memang tampak menanamkan harapan bahwa berkat popularitas AI, berbagai platform akan menjadi bisa diprogram untuk tujuan apa pun, tetapi justru dianggap ditakdirkan gagal, karena alasan semantic web gagal juga sama: tidak berhasil membangun struktur pendapatan; fitur “research” AI yang menelusuri web secara mendalam sebagai pengganti pengguna pun menghadapi hal serupa, misalnya restoran bisa saja memublikasikan menu sebagai metadata sehingga otomatisasi seperti “cari taco termurah di Texas” menjadi mungkin, tetapi realitasnya justru adalah penguncian data dan persaingan infrastruktur antara crawler AI yang berusaha mengakalinya, dan dalam gambaran besar kesimpulannya sistem saat ini memang tidak efisien
  • MCP pada akhirnya dinilai hanya bentuk evolusi dari robots.txt; pada dasarnya ini model “kalau kamu menjelaskan resource-mu dengan baik, saya akan memanfaatkannya”, sementara sistem agen berbasis Java pada era 90-an juga gagal karena masalah asimetri informasi antaragen, dan ada kekhawatiran bahwa jika batas desain ini dihilangkan, seluruh masyarakat atau bisnis justru bisa berhenti berfungsi
  • Penilaian berdasarkan pengalaman adalah bahwa open API, bahkan sebelum masalah pendapatan finansial, secara praktis akan membuat bangkrut jika tidak ada investasi resource yang nyaris tak terbatas, karena gelombang bot permintaan dari agen AI akan menguras resource; dalam jangka panjang, skema RPC pay-per-call dinilai akan menjadi alternatif yang stabil, dengan operator model/agen bertindak sebagai clearing house pembayaran dan biayanya kemungkinan dibenamkan ke dalam biaya langganan atau sejenisnya
  • Cita-cita arsitektur REST seperti HATEOAS sempat sangat populer pada awal 2010-an, tetapi selain tool otomatisasi seperti swagger yaml, nyaris tidak berkembang lebih jauh dan akhirnya menghilang; bahkan istilahnya sendiri dinilai terlalu sulit sehingga ikut mengundang kegagalan
  • Ada ketidaksetujuan terhadap pandangan yang menganggap teks yang dibaca manusia sebagai hambatan buatan; justru menuntut restoran memiliki kemampuan menghasilkan JSON atau mengadopsi software-lah yang merupakan hambatan buatan di dunia nyata, dan berkat tool NLP, data yang sudah ada bisa dipakai apa adanya sehingga biaya pengembangan menyusut nyaris ke nol; memang ada ketidakakuratan bahasa, tetapi itu dianggap sifat dasar bahasa manusia sehingga tidak terlalu dipermasalahkan
  • Walau agak hati-hati karena ini muncul saat mengkritik semantic web, ada pandangan bahwa pemilik restoran yang benar-benar menginginkannya sebenarnya bisa saja kapan pun memublikasikan metadata dan itu dapat menjadi jalan untuk menghubungkan pembeli dan penjual dengan mudah; ambil contoh plugin WordPress, metadata seperti schema.org/Restaurant, Menu, MenuItem, dan Offer sudah didukung, sehingga hambatan terbesar pada akhirnya diduga justru gatekeeping seperti Cloudflare, yang memang menjadi faktor nyata yang menghalangi ide otomatisasi Python
• Karena LLM dapat membaca dokumentasi API dan beradaptasi secara otomatis, ada pemikiran bahwa kepatuhan pada standar spesifikasi API tidak lagi sepenting dulu; terlepas dari adopsi spesifikasi MCP, fakta bahwa tiap situs kini diharapkan untuk “menyediakan API” sendiri sudah merupakan perubahan besar
  • Di lingkungan nyata, dokumentasi API bisa saja buruk sehingga LLM menghasilkan kode atau panggilan yang salah, lalu pengguna memperbaikinya dan mengirimkannya kembali ke LLM, yang pada akhirnya sama saja dengan membuat lapisan perantara (server bergaya MCP); saat memberi LLM hak akses langsung ke API, juga muncul risiko dari sisi keamanan dan pengelolaan resource (misalnya ledakan biaya karena panggilan berlebihan), dan ada banyak pain point tambahan, sebagian di antaranya justru terselesaikan jika ada antarmuka perantara seperti MCP di tengah; apakah “perantara” itu harus MCP atau tidak adalah soal lain, tetapi pada saat ini ini tetap solusi yang cukup praktis
• Hal yang paling dikhawatirkan dari MCP bukanlah level protokol yang belum matang, melainkan fakta bahwa kewenangan untuk memperbaiki atau merevisi terlalu terkonsentrasi pada tim di perusahaan seperti Anthropic dan OpenAI; juga ada kewaspadaan bahwa spesifikasinya masih berhenti di tahap brainstorming, bukan benar-benar berpusat pada para developer dan operator, sehingga terasa seperti bayangan duopoli Visa-Mastercard
  • Ada juga contoh Microsoft bergabung ke steering committee
• Ada harapan bahwa “semantic web” pada dasarnya hanyalah struktur tata bahasa, dan mungkin MCP justru punya kemungkinan nyata untuk benar-benar mewujudkannya
• Ada anggapan bahwa “para developer Unix lawas utama terlalu ribet dan rewel”, tetapi ironisnya justru Unix bisa dibilang pelopor budaya “coba cepat lalu bongkar”, sehingga terasa bahwa meskipun generasi berubah, esensinya tetap sama
• Ada kekhawatiran realistis bahwa MCP bisa disalahgunakan seperti SEO Google Search, yaitu untuk menyebarkan iklan dan spam yang ditujukan ke AI
• Perlu berhati-hati terhadap ilusi bahwa berkat MCP semua orang akan dengan mudah mengakses berbagai jenis data; kenyataannya justru lebih terasa dunia di mana semuanya terikat pada lapisan autentikasi pembayaran, white list IP yang diizinkan, dan pengaman lain, lalu pengguna nyata hanya menerima error “ERR 402”