Kedatangan Web 2.0 2.0: MCP

 (anildash.com)
2 poin oleh GN⁺ 2025-05-25 | 1 komentar | Bagikan ke WhatsApp
  • Model Context Protocol (MCP) adalah spesifikasi yang dibuat Anthropic untuk menghubungkan LLM dengan aplikasi dan sistem eksternal; setelah OpenAI mendukungnya di ChatGPT, MCP menyebar seperti antarmuka bersama di berbagai platform
  • Meski spesifikasinya longgar dan tidak lengkap, jika banyak pihak dengan cepat mengadopsi cara yang sama, di web nyata protokol terbuka bisa memperoleh kekuatan
  • Nilai asli Web 2.0 lebih dekat pada ekosistem developer dan pengguna yang dibentuk oleh API terbuka serta tool yang interoperabel, bukan situs sosial tertutup
  • Saat platform besar seperti Facebook dan Twitter menutup API mereka, harapan akan interoperabilitas melemah; MCP berpotensi menghidupkannya kembali sebagai platform yang dapat diprogram dalam arus tool coding AI
  • MCP bukan solusi serba bisa, dan memiliki ketidakjelasan pemrosesan data serta risiko keamanan yang besar, tetapi dapat menjadi momentum baru untuk menuntut kepatuhan standar dan transparansi

Latar belakang MCP menyebar seperti standar

  • Model Context Protocol, atau MCP, adalah spesifikasi yang dirancang Anthropic untuk Claude
    • Tujuannya adalah memungkinkan LLM meminta informasi dari berbagai aplikasi atau berinteraksi dengan sistem lain
  • Ketika OpenAI beberapa bulan lalu mendukung protokol yang sama di ChatGPT, MCP mulai memosisikan diri seperti standar yang diadopsi di banyak tempat
  • MCP juga masuk ke Windows, menunjukkan luasnya penyebarannya
  • Poin pentingnya bukan kesempurnaan spesifikasi, melainkan fakta bahwa banyak pemain dengan cepat mengadopsi antarmuka yang sama
  • MCP lebih menyerupai spesifikasi yang longgar, tetapi terbuka dan berfungsi, sehingga mirip dengan cara web berhasil

Apa yang semula dimaksud Web 2.0

  • Web 2.0 bukan istilah untuk situs tertutup dan proprietari seperti Facebook
  • Di pusat komunitas awal Web 2.0 ada arus ketika berbagai situs menyediakan API terbuka, memungkinkan developer dan pengguna menghubungkan orang dan data
  • Flickr, Del.icio.us, dan Upcoming adalah situs representatif dari era yang merintis fitur seperti tag dan berbagi sosial
  • Platform seperti LiveJournal dan Movable Type juga memengaruhi kerja standar terbuka seputar API dan protokol
  • Nilai bersama saat itu relatif jelas
    • Membangun tool, teknologi, dan platform di atas data terbuka dan protokol terbuka
    • Pengguna memegang kendali
    • Developer berinteraksi dengan sistem melalui tool yang konsisten dan interoperabel

Interoperabilitas yang diputus oleh platform tertutup

  • Selama satu generasi, developer makin sulit menganggap interoperabilitas antara aplikasi dan platform sebagai sesuatu yang wajar
  • Kritik juga muncul bahwa VC besar dan para pemimpin industri teknologi telah mengakhiri era keterbukaan
  • Tool untuk menganalisis aktivitas jejaring sosial mengalami kasus ketika produk dan layanan berbasis pengguna terhenti karena platform jejaring sosial besar menutup API mereka
  • Bagi banyak orang, platform seperti Facebook dan Twitter meruntuhkan harapan Web 2.0 akan data terbuka dan teknologi yang interoperabel
  • Akibatnya, situasi ketika pengguna sulit mengelola jaringan mereka dengan cara yang diinginkan menjadi hal sehari-hari
    • Tidak bisa melihat foto Instagram yang disematkan di timeline Twitter
    • Sulit memakai fitur seperti impor/ekspor follower yang tersedia di fediverse atau Bluesky
    • Sulit mengendalikan jaringan sendiri dengan aplikasi yang diinginkan

Kemungkinan yang bisa dibuka kembali oleh MCP

  • Kebangkitan MCP, yang beriringan dengan popularitas AI di kalangan coder, menciptakan harapan bahwa platform dapat terbuka bukan hanya untuk LLM, tetapi juga untuk berbagai tujuan pemrograman
  • Intinya adalah platform lain mengadopsi begitu saja spesifikasi yang dibuat Anthropic
  • Jika sebuah protokol dari perusahaan lain diadopsi dengan setia sebagai pengadopsi kedua, seluruh ekosistem dapat lebih mudah bekerja dengan cara yang sama
  • Sebaliknya, menyalin dan memperluas protokol lalu pada akhirnya meniadakannya dapat merusak ekosistem
  • Ketika ada adopsi dengan niat baik untuk memakai antarmuka yang sama, peluang berbagai tool dan platform untuk bekerja bersama menjadi lebih besar

Sulitnya mengikuti standar apa adanya

  • Mendukung standar apa adanya lebih sulit daripada kelihatannya
  • Saat meluncurkan produk semantic caching untuk platform AI pun, tidak mudah meyakinkan developer agar memakai API ChatGPT biasa apa adanya
  • Developer mudah berpikir “ini bisa dibuat lebih baik”, tetapi begitu berbeda dari standar, hasilnya justru bisa menjadi lebih buruk
  • Kadang lebih penting semua orang mengimplementasikan dengan cara yang sama, meski spesifikasinya buruk dan penuh ketidaksesuaian
  • HTML juga merupakan spesifikasi tidak lengkap yang banyak kekurangannya, tetapi web dibangun di atasnya
  • Seluruh internet pun berdiri di atas berbagai spesifikasi yang tidak sempurna

Tuntutan kepatuhan standar dan transparansi

  • Generasi baru developer sedang mengalami kreativitas dan kemungkinan yang muncul ketika tool dan platform favorit mereka memakai protokol dan format yang sama
  • Arus seperti RSS, podcasting, OpenID, OAuth, dan OpenSocial sebagian kemudian berujung pada hasil seperti fediverse dan ActivityPub
  • Developer, coder, penggemar teknologi, dan pengguna umum juga dapat menuntut akses untuk mengendalikan pengalaman mereka di platform melalui kode
  • Saat mengakses melalui standar terbuka seperti MCP, kita juga harus menuntut transparansi tentang apa yang sebenarnya dilakukan platform
  • MCP fleksibel, tetapi menyisakan banyak risiko
    • Tidak jelas bagaimana platform menangani data pengguna
    • Sulit mengetahui tindakan apa yang akan terjadi dalam interaksi melalui MCP
    • Risiko keamanannya sangat besar
    • Protokol ini belum cukup menangani kekhawatiran tersebut

Keterbatasan dan harapan keterbukaan ala Web 2.0

  • MCP bukan solusi serba bisa yang memperbaiki semua masalah ekosistem developer
  • MCP juga tidak meluruskan hype dan distorsi perdebatan seputar AI
  • Namun, ada kemungkinan developer muda yang tidak mengalami era Web 2.0 generasi sebelumnya menjadikan MCP sebagai momentum untuk mengembalikan web agar lebih dekat dengan arsitektur aslinya
  • Web tidak dimaksudkan sebagai struktur yang proprietari atau dikendalikan oleh segelintir orang di beberapa perusahaan besar
  • Web seharusnya dapat diprogram melalui spesifikasi kasar yang diadopsi semua orang dengan tergesa-gesa, dan kesenangan yang bisa di-hack seperti itu sudah ada bahkan sebelum web memiliki nomor versi

Bacaan terkait

1 komentar

 
GN⁺ 2025-05-25
Opini Hacker News

  • Hal yang banyak orang lewatkan dari MCP adalah bahwa ini sangat cocok untuk perangkat lunak enterprise
    LLM adalah penerjemah serbaguna, jadi cocok sebagai lem untuk menyambungkan sistem-sistem terputus yang sangat sulit dihubungkan tanpa lapisan perantara yang agak longgar
    Karena itu industri B2B SaaS merilis server MCP, dan secara internal mereka mendiskusikan bagaimana merancang ulang API beserta batasannya agar sesuai dengan pola penggunaan yang berubah
    Protokol ini, dalam banyak definisi, belum “siap enterprise”, tetapi seperti kata penulis, itu tidak terlalu penting. Jika melihat sejarah standar, hal-hal yang berantakan dan “buruk” pun bisa diadopsi luas jika cocok dengan orang yang tepat pada waktu yang tepat

    • MCP hanyalah RPC di atas koneksi panjang, dan kebanyakan berupa WebSocket. Menurut saya RPC lebih mudah disiapkan
      Perdebatan seperti apakah mengubah field pada objek pengguna itu PUT yang mengganti objek pengguna asli atau POST jadi berkurang. Saya pernah menghabiskan cukup banyak waktu untuk berdebat soal verba REST
      LLM juga tidak perlu memahami semantik REST dari API. Ia cukup melihat metode RPC yang tersedia lalu melakukan panggilan yang tampaknya cocok. Menurut saya intinya memang sesederhana itu
    • Ini struktur yang bagus untuk menghasilkan uang. Tiap permintaan data melibatkan perjalanan bolak-balik LLM berbayar
      Bukan model di mana endpoint saling menegosiasikan skema agar bisa ditanyai dengan murah nantinya
    • Kita sudah punya REST dan OpenAPI
      Dengan itu saja fitur seperti penemuan diri sudah bisa dilakukan
      Tempat yang menyediakan MCP toh kemungkinan juga akan menyediakan API yang layak
    • Sepenuhnya setuju. Perusahaan raksasa penuh dengan engineer yang ingin membuat hal keren dari jam 9 sampai jam 5, lalu pulang dan melupakan pekerjaan sampai hari berikutnya
      Perusahaan mana yang tidak ingin memeras produktivitas maksimum dari karyawannya selama jam kerja

  • Bagian “dibandingkan masa ketika spesifikasi ditulis oleh bapak-bapak Unix tua yang rewel” menurut saya adalah salah satu dari banyak alasan semantic web gagal. Ini juga tidak bertentangan dengan poin penulis bahwa “yang buruk lebih baik”
    Saya rasa orang-orang terlalu terpaku pada eXtensible dalam XML, dan pada titik tertentu muncul kelelahan. XSL, XHTML, XSD, WSDL, XSLT, RDF, RSS, dan sebagainya jadi terlalu banyak
    Yang dibutuhkan dunia saat itu adalah format pertukaran yang sederhana, dan JSON memenuhi kebutuhan itu, sedangkan kubu XML lebih mirip penerbangan luar angkasa arsitektural untuk format data
    Namun saya juga percaya sekarang waktunya XML telah tiba. XML sering terlihat dalam system prompt yang bocor dari tempat seperti Anthropic. LLM tampaknya cukup baik menangani format teks terstruktur, terutama Markdown dan XML
    Namun menurut saya MCP adalah model yang keliru. Alih-alih menginstruksikan model untuk “menarik” konteks sendiri, saya pikir kita harus “mendorong” konteks ke model

    • Pengamatan yang menarik. Baru-baru ini saat membuat bahasa ekspansi makro JSON, saya jadi cukup tertarik pada XML/XSLT
      Empat tag makro (#=, #&, #?, #!) masing-masing mengganti dirinya dengan hasil ekspansi makro berupa assignment, substitusi, percabangan kondisi seperti cond, dan pemanggilan fungsi yang didefinisikan pengguna, lalu akhirnya saya sadar saya sedang membuat ulang XSLT
      Yang sebenarnya saya inginkan adalah XPath. Ini cara mendeskripsikan bagaimana menelusuri graf maju-mundur di sepanjang berbagai sumbu, dan memang merupakan spesifikasi yang bagus
      Lalu saya menemukan BaseX https://basex.org/, yang memungkinkan dokumen XML sembarang dimasukkan sebagai database yang bisa dikueri dan ditanyai dengan XPath atau XQuery
      Untuk membuat antarmuka dataset bahasa alami yang tepercaya tanpa halusinasi, pendekatan terbaik tampaknya adalah memberikan skema XML ke system prompt lalu membiarkan model menulis kueri untuk mengambil data
    • Saya tidak mengerti bagaimana “mendorong konteks alih-alih membiarkan model menarik konteks sendiri” bisa dilakukan dalam kasus-kasus yang orang ingin diselesaikan oleh intern
      Kalau informasinya sudah diketahui sebelumnya, mungkin mereka sudah menyelesaikan masalahnya sendiri
      Nilai yang didapat dari MCP tampaknya lebih seperti “jangan suruh saya belajar cara menyambungkan 15 sumber; jalankan kueri tertentu untuk saya”
    • Tag XML bekerja baik dengan LLM. Tapi kebanyakan itu hanya tag XML saja
      Tidak ada yang™ memberi LLM XML yang benar-benar valid yang diawali deklarasi XML, dan tidak ada yang memakai namespace, XSLT, atau XML Schema
      Itu lebih mirip kumpulan tag gaya SGML yang disusun secara bebas
    • Dalam kode hobi, saya sesekali memakai XML sebagai format sumber dokumen, tetapi alasan saya akhirnya menjauh selalu hal-hal kecil di sekitar sintaksnya
      XML adalah spesifikasi besar yang lebih dari sekadar tanda kurung sudut, dan berusaha mencakup semua kasus serta menangani keamanan dan encoding karakter dengan benar
      Karena itu “penyuntingan teks biasa” terasa cukup tidak intuitif. Jika mengetik paragraf seperti ini, dalam mode kompatibilitas mungkin bisa diparse, tetapi belum tentu valid
      Sebagai format pertukaran atau format yang dimuat ke aplikasi yang memang dibuat untuk itu, potensinya lebih besar, dan LLM jelas tidak akan kesulitan memahaminya, jadi itu bagus
      Banyak masalah di masa lalu muncul karena programmer yang kekurangan waktu dan ingin cepat menyisipkan fitur menggunakan spesifikasi yang sangat terstruktur seperti pentungan. Jika “XML? Pakai regex saja.” diulang oleh tiga program berbeda dan tiga penulis berbeda, jadinya kacau balau
      Secara pribadi, format yang paling mendekati apa yang sebenarnya saya inginkan adalah BBCode. Ini bagus sebagai format sumber untuk banyak hal. Pada dasarnya masih sejenis tanda kurung sudut, tetapi punya struktur dan fleksibilitas yang pas untuk dipakai sebagai sintaks frontend umum
      Implementasi awalnya memang “pakai regex saja”, tetapi setelah teruji di dunia nyata selama beberapa dekade, sekarang ada parser yang lebih elegan
    • Semantic web gagal karena tidak menemukan cara menyisipkan iklan

  • Saya berpikir kebalikan dari kalimat, “Kebangkitan MCP memberi harapan bahwa seiring AI menjadi populer di kalangan coder, LLM bisa membuka platform-platform lain agar dapat diprogram untuk tujuan apa pun, bukan hanya untuk dikendalikan olehnya.”
    MCP ditakdirkan gagal karena alasan yang persis sama dengan gagalnya semantic web. Karena kalau sesuatu tidak dikunci, tidak ada yang menghasilkan uang
    Saya penasaran, seberapa banyak hal yang kini kita sebut “deep-research”, maaf, fitur ketika AI menelusuri web untuk kita, sebenarnya bisa diselesaikan dengan cara yang lebih baik
    Restoran bisa saja memublikasikan menu dalam format metadata dan siapa pun bisa mencari taco termurah di Texas dengan skrip Python, tetapi kenyataannya dengan satu tangan mereka mengunci data di balik penghalang buatan, sementara dengan tangan lain mereka membuat AI—termasuk data center—untuk menerobosnya. Kalau dilihat secara makro, ini sekadar hal bodoh

    • Menurut saya benar. MCP terasa seperti robots.txt yang berevolusi menjadi makhluk hidup yang lebih tinggi, tetapi tetap saja pada dasarnya “tolong jelaskan sumber daya Anda agar bisa kami eksploitasi”
      Gelombang agen sebelumnya mati karena pada akhirnya semua orang sadar bahwa mereka tidak bisa memercayai kode mereka sendiri yang berjalan di mesin tempat semuanya bisa dinegosiasikan. Itu urusan Java era 90-an
      Pada dasarnya, di antara agen-agen yang saling berinteraksi ada masalah asimetri informasi yang memang dirancang dengan sengaja. Jika itu dihilangkan, sebagian besar masyarakat akan berhenti berfungsi
    • Masalahnya bukan hanya bahwa menyediakan API terbuka gratis tidak menghasilkan uang. Untuk mengoperasikan API seperti itu, pada praktiknya dibutuhkan sumber daya tak terbatas
      Sebanyak apa pun sumber daya dilemparkan ke masalah ini, seseorang akan menemukan cara untuk mengurasnya demi keuntungan yang sangat kecil
      MCP hanya akan memperburuk masalah ketika agen-agen AI menyerbu server MCP publik seperti kawanan belalang
      Pilihan yang stabil tampaknya adalah penetapan harga RPC berbayar per panggilan. Setidaknya pihak yang mengoperasikan model atau agen akan bertindak sebagai clearing house pembayaran, jadi peluangnya lebih besar dibanding API Web 2.0
      Mungkin skema penagihan yang paling masuk akal adalah memasukkan biaya seperti ini ke dalam paket langganan. Itu tampaknya cara terbaik untuk menyelaraskan insentif
    • Pada awal 2010-an, HATEOAS adalah impiannya, dan mencoba membuat konsumsi API menjadi hal sepele, tetapi pada akhirnya hampir tidak melangkah lebih jauh daripada menghasilkan swagger yaml
      Orang yang menamai HATEOAS sejak awal bisa dibilang sudah menyiapkan panggung untuk kegagalannya
    • Saya melihat popularitas MCP sebagai efek samping dari gelembung panas berlebih yang kini mendorong AI. Ini hanya salah satu hal yang terlihat meyakinkan untuk dilakukan dengan AI
      Jika ada nilai yang “mudah” dalam memublikasikan data dalam format standar, endpoint yang interoperabel pasti sudah diadopsi jauh lebih luas
      Misalnya memakai schema.org atau ontologi umum yang lazim. Tetapi kenyataannya banyak format khusus yang setiap kali membutuhkan SDK ajaib tersendiri
    • Teks yang dapat dibaca orang biasa bukanlah “penghalang buatan”. Itulah esensi dunia kita
      Justru menuntut restoran memublikasikan menu dalam format metadata adalah penghalang buatan
      Di sinilah keindahan alat pemrosesan bahasa alami baru berada. Pemilik restoran tidak perlu belajar JSON atau membeli paket perangkat lunak yang menghasilkan JSON
      Kita bisa memakai data apa adanya. Biaya untuk membuat alat yang berguna menjadi nyaris 0
      Memang tidak akurat, tetapi memang begitulah bahasa manusia

  • Orang-orang yang berpikir bahwa dengan adanya MCP mereka bisa mengakses apa saja tampak menyedihkan
    Hal-hal seperti itu akan disembunyikan di balik puluhan lapisan verifikasi pembayaran dan autentikasi. Tentu saja juga akan ada IP allowlist, dan tentu saja itu IPv4
    Yang akan kalian lihat mungkin hanya ERR 402;

  • Yang paling saya khawatirkan dari MCP bukanlah bahwa protokolnya dibuat dengan buruk, melainkan bahwa memperbaiki dan meningkatkannya hanya bergantung pada tim internal Anthropic dan OpenAI
    Orang-orang yang membuat protokol ini tidak tampak seperti engineer yang juga benar-benar mencoba mengimplementasikannya
    Samar-samar terasa seperti oligopoli Visa-Mastercard

  • Jika sekarang LLM bisa membaca dokumentasi API dan beradaptasi, bukankah kebutuhan untuk mengikuti API standar jadi lebih kecil dibanding dulu
    Manfaat penting bagi saya adalah munculnya ekspektasi bahwa sebuah situs “memiliki” API, entah situs itu mengikuti spesifikasi MCP atau tidak

    • Dokumentasi API bisa saja ditulis dengan buruk
      Sekalipun dokumentasinya bagus, LLM bisa menghasilkan kode yang keliru untuk berinteraksi dengan API. Jika Anda memperbaiki kode yang dihasilkan lalu membuat LLM memanggil kode itu untuk berinteraksi dengan API, pada akhirnya Anda sudah berada di jalan menuju lapisan perantara. Secara praktis, Anda sedang membuat server yang “mirip MCP”
      Memberi LLM akses langsung ke API juga menimbulkan masalah keamanan atau alokasi sumber daya. LLM memiliki pengetahuan terbatas tentang kapan terakhir kali API dipanggil. Ia bisa memanggil terlalu sering, dan jika biaya per panggilan mahal, tagihan infrastruktur yang tidak terduga bisa muncul
      Selain itu, ada banyak titik sakit potensial lain yang bisa diselesaikan dengan menaruh sesuatu di tengah
      Apakah “sesuatu” itu harus MCP, orang-orang yang rasional bisa berbeda pendapat. Saat ini tampaknya ia bekerja cukup baik untuk menyelesaikan hal-hal yang perlu dilakukan orang

  • Sekarang kita bisa membuat semantic web. Organisasi hanya perlu membuat protokol kecil untuk membagikan DDL SQL CREATE TABLE sebagai file statis yang bisa dibaca aplikasi MCP. Itu cukup sebagai ekstensi opsional MCP
    Dengan begitu, memakai alat yang sudah ada untuk menghubungkan pemanggilan fungsi AI/LLM ke SQL, data bisa dipahami dan di-query; itulah yang akan menjadi semantic web
    Pendekatan ini mengisi mata rantai yang hilang yang selama ini selalu menghambat semantic web: tidak adanya insentif bagi perusahaan untuk memakai “tipe data” standar alih-alih tipe data proprietary
    Jika muncul MCPQ, yaitu MCP dengan query, tiba-tiba organisasi punya alasan untuk bekerja sama di lapisan struktur data

  • Ternyata “semantic web” selama ini sebenarnya adalah syntactic web, dan mungkin kali ini benar-benar yang asli

  • Saya penasaran berapa lama sampai seseorang membuat server MCP untuk mengendalikan sesuatu seperti kecoak
    Referensi:
    https://www.technologynetworks.com/informatics/news/robo-roa...
    https://www.sciencealert.com/scientists-turned-cockroaches-i...
    Dan ada banyak contoh lain yang bahkan berasal dari lebih dari 10 tahun lalu

  • Ungkapan “masa ketika spesifikasi ditulis oleh bapak-bapak Unix tua yang cerewet” cukup lucu
    Menarik bahwa generasi ini membayangkan “bapak-bapak Unix tua” sebagai orang-orang yang cerewet. Padahal Unix adalah pemberontakan bergerak cepat dan menghancurkan sesuatu yang paling puncak melawan mazhab MIT
    Sepertinya ada hal-hal yang tidak berubah :-)