MCP: Sistem Plugin Universal (yang Tidak Disengaja)

• USB-C bernilai bukan hanya untuk pengisian daya dan transfer file, tetapi karena sifat universalnya yang bisa diperluas untuk berbagai kegunaan
• MCP(Model Context Protocol) awalnya dirancang untuk asisten AI, tetapi dalam praktiknya bisa menjadi sistem plugin universal yang menghubungkan semua sumber data dan alat
• Seperti kasus NFT Base64, protokol dapat berkembang melampaui tujuan awalnya dengan cara menyimpan dan memanfaatkan data dunia nyata secara langsung
• Semakin banyak server MCP, semakin mudah setiap aplikasi memanfaatkan beragam fungsi tanpa integrasi terpisah
• Seperti USB-C, MCP juga akan menjadi 'ruang kemungkinan untuk menghubungkan apa saja', fondasi yang melahirkan inovasi tak terduga

---

MCP: An (Accidentally) Universal Plugin System (Or: The Day My Toaster Started Taking Phone Calls)

USB-C dan universalitas yang tak terduga

• Semua orang mengira USB-C hanya untuk pengisian daya atau transfer file, tetapi berkat strukturnya, ia bisa diperluas ke berbagai kegunaan
• Penulis menunjukkan kemungkinan tanpa batas USB-C lewat contoh temannya, Rex, yang menghubungkan pemanggang roti ke monitor sehingga pemanggang itu memiliki output HDMI
• Ini dimungkinkan karena USB-C adalah struktur yang memungkinkan apa pun terhubung selama port-nya cocok, tanpa terlalu memedulikan spesifikasi daya dan data

Prinsip soket pemantik rokok mobil

• Soket pemantik rokok mobil awalnya dibuat untuk menyalakan rokok, tetapi kini dipakai sebagai port daya serbaguna untuk berbagai keperluan
• Seperti soket tersebut, protokol tidak membatasi pilihan pengguna dan justru memungkinkan banyak kegunaan
• MCP juga memiliki ekspansibilitas serupa

Menemukan kembali MCP: tanpa sengaja menjadi sistem plugin universal

• Umumnya MCP(Model Context Protocol) dikenal sebagai cara agar asisten AI (misalnya Claude) dapat memanfaatkan data
• Dokumentasi resminya juga menyatakan bahwa ia "secara standar menghubungkan model AI ke berbagai sumber data dan alat"
• Namun jika unsur AI disingkirkan, MCP menjadi sarana untuk "apa pun" terhubung ke sumber data dan alat yang berbeda-beda
• Artinya, terlepas dari tujuan awalnya, ia berubah menjadi protokol koneksi universal

The NFT Base64 Revelation

• NFT awalnya digunakan untuk merujuk gambar, tetapi pada suatu titik referensinya sendiri menjadi data
• Saat maksud asli protokol bergeser, kartu perpustakaan pun mulai berperan sebagai buku yang sebenarnya
• Ia berubah menjadi alat yang secara langsung menangani data dunia nyata, jauh lebih luas daripada niat awalnya

Efek jaringan yang tak pernah diperkirakan siapa pun

• Semakin banyak server MCP untuk AI, muncul efek bahwa semua aplikasi memperoleh fungsi baru tanpa pengembangan tambahan
• Misalnya, jika seseorang membuat server MCP Spotify, aplikasi olahraga bisa secara otomatis membuat playlist melalui MCP
• Muncul efek jaringan di mana pengembang dan aplikasi yang tidak saling mengenal terhubung secara alami dan semuanya diuntungkan
• Setiap server MCP bisa digunakan ulang sebagai plugin universal
• Tak ada yang merencanakannya, tetapi ekosistem plugin universal terbentuk secara kebetulan

Makna USB-C dan filosofi MCP

• MCP sering dianalogikan sebagai USB-C untuk AI, dan yang membuat USB-C istimewa bukanlah sekadar port sederhana, melainkan ruang kemungkinan untuk menghubungkan apa saja
• Seperti USB-C yang menerima daya, data, video, dan fungsi lain yang belum diketahui, MCP juga bukan sekadar 'untuk AI', melainkan berperan sebagai 'lubang yang dirancang dengan baik untuk fungsi', sehingga siapa pun dapat menghubungkan fungsi apa pun

The Part Where I Tell You I'm Building Something

• Penulis sedang mengembangkan aplikasi manajemen kerja bernama APM(Actions Per Minute)
• APM berjalan sebagai sistem plugin yang sepenuhnya hanya menggunakan server MCP
• Setiap kali ingin menambahkan fungsi yang diinginkan, pengguna cukup menghubungkan server MCP saja (misalnya pemeriksa ejaan, pemesanan kopi otomatis, reaksi karakter game, dan sebagainya)
• Ini adalah struktur yang memungkinkan aplikasi itu sendiri berubah secara fleksibel ke berbagai bentuk

The Toaster Protocol Principle

• Semua protokol besar menciptakan inovasi dengan dipakai untuk kegunaan tak terduga, berbeda dari niat awalnya
  • HTTP: untuk makalah akademik → infrastruktur peradaban
  • Bluetooth: handsfree → membuka kunci pintu depan, dll.
  • USB: perangkat input → mengisi daya kipas portabel, dll.
• MCP juga awalnya untuk pengiriman konteks AI, tetapi pada dasarnya adalah protokol yang menghubungkan segala sesuatu dengan segala sesuatu
• Ditekankan bahwa ini adalah fondasi bagi ekosistem plugin yang menciptakan inovasi tak terduga
• Meski sama sekali tidak disengaja, ini adalah pendekatan yang sangat cocok untuk era ketika pemanggang roti dan monitor bisa dihubungkan lewat HDMI

Penutup

• PS: Jika Anda membuat komputer yang mengeluarkan aroma roti segar lewat server MCP, jangan lupa hubungi saya
• PPS: early access APM telah dibuka, dan penulis mendorong upaya-upaya jenaka serta eksperimen kreatif
• (Di suatu tempat, ada protokol yang masih dipakai sesuai tujuan aslinya. Ini sangat mencurigakan)

[a1eng0]

Respons dari server MCP kemungkinan besar berupa bahasa alami tanpa schema yang ditetapkan.

Akan sulit untuk memproses respons bahasa alami ini secara terprogram tanpa LLM.

[winterjung]

Sebagai referensi, dengan ditambahkannya structured tool output ke spesifikasi mcp 2025-06-18, kini deskripsi schema respons menjadi memungkinkan. Implementasi tool mcp yang sudah ada memang, seperti yang Anda katakan, sebagian besar masih unstructured, tetapi untuk tool mcp ke depannya rasanya cukup layak untuk dinantikan.

[a1eng0]

Senang bertemu lagi dengan Winter-nim di sini hehe

Sepertinya saya belum sempat mengikuti spesifikasi 250618. Terima kasih!

[GN⁺]

Komentar Hacker News

• Saya sangat menyukai tulisan ini dan protokol MCP. Tapi setiap melihat MCP, entah kenapa saya jadi teringat microservices dan SOA. Saya khawatir ini akan mengulang mimpi buruk dengan menciptakan titik kegagalan baru. Di sisi lain, saya juga punya harapan bahwa dengan adopsi agen, peningkatan keandalan bisa terjadi dengan lebih alami

• Saya setuju dengan gagasan dalam tulisan ini, dan menurut saya menarik sekali bahwa penulis memakai MCP dengan cara yang agak melenceng dari maksud aslinya. Inti sebenarnya dari cara berpikir ini bukanlah bahwa kini muncul protokol yang memungkinkan hal-hal baru yang sebelumnya tidak ada. Seperti komentar lain bilang, MCP sendiri bukan ide yang benar-benar baru atau menarik. Bagian yang sungguh menarik adalah bahwa berkat demam agen AI, interoperabilitas menjadi sorotan, sehingga masalah vendor lock-in diperlakukan sebagai sesuatu yang ketinggalan zaman. Saya tidak tahu tren ini akan bertahan berapa lama, tapi untuk saat ini rasanya menyenangkan

  • Ini mengingatkan saya pada saat Winsock diperkenalkan. Dulu, di Windows, semua urusan jaringan memakai antarmuka privat yang berbeda-beda. Lalu ada kisah bahwa para vendor berkumpul dan memutuskan membuat standar bersama yang menguntungkan semua pihak. Lihat Wikipedia Winsock
  • Poin utamanya bukan sekadar interoperabilitas sedang naik daun atau bahwa semuanya bisa disambungkan dengan mudah. Inovasi sejatinya adalah bahwa LLM itu sendiri sudah belajar cara menggunakan tool. Selama backend-nya dibuat, frontend bukan lagi urusan saya, karena AI yang akan menyelesaikannya. Claude dan Gemini juga bisa memanfaatkan tool sendiri kalau kita hanya memberi tujuan. Dulu kita selalu harus menyusun prosedur langkah demi langkah secara jelas untuk mendapatkan hasil yang diinginkan, tapi sekarang LLM jauh lebih baik beradaptasi dengan situasi yang berubah-ubah daripada program yang kaku, dan saya melihat ini sebagai perubahan besar
  • Memang ada nuansa ekspektasi berlebihan. Tapi menurut saya, agen AI benar-benar memberi motivasi kuat untuk interoperabilitas. Dulu, semua orang bekerja lambat di sistem masing-masing dan itu justru menjamin keamanan pekerjaan. Sekarang trennya adalah menghubungkan semuanya. Seperti perubahan ketika lebih murah bagi CEO untuk ikut mengurus pizza di hackathon, agen bergantung pada integrasi. Sebagai orang yang pernah langsung ikut gelombang inovasi integrasi API dulu, rasanya dunia akhirnya mulai menyusul. Saya harap suasana ini bertahan lama
  • Saya tidak sepenuhnya setuju dengan pendapat bahwa demam agen AI mendorong tren interoperabilitas dan menjadikan vendor lock-in sebagai sesuatu yang usang. Tool yang sedang populer seperti Cursor pun hanya memakai MCP secara satu arah dan tidak mengeluarkan riwayat percakapan atau konteks ke luar. Saya suka Cursor, tetapi sikap seperti ini, dimulai dari fork VS Code yang tidak open source, menurut saya akan berdampak buruk pada kepercayaan developer. Pada akhirnya, lock-in masih sangat kuat
  • Ironisnya, pembatasan akses API belakangan justru makin parah terkait pelatihan data AI. Sebenarnya penguncian API seperti ini sudah ada jauh sebelumnya, dan ada juga pandangan skeptis bahwa jika tren keterbukaan baru ini tidak mampu memenuhi ekspektasi berlebihan, semuanya bisa kembali tertutup kapan saja

• Penulis tampaknya menaruh harapan besar pada sifat umum MCP, tapi jujur saja saya bertanya-tanya apa bedanya dengan konsep API itu sendiri. Kalau MCP diganti dengan REST, apakah isi tulisan ini akan berubah banyak? Ada juga kemiripan dengan API sistem operasi, POSIX, atau Unix pipe. Memang MCP jauh lebih sederhana dan lebih umum daripada semua itu. Tapi mungkin solusi yang sebenarnya bukan terus-menerus membuat abstraksi baru, melainkan membuat perangkat lunak yang sederhana dan setia pada dasar-dasarnya

  • MCP berbeda dari REST. Rasanya lebih seperti protokol yang memungkinkan endpoint REST ditemukan secara dinamis saat runtime, lalu pengguna sendiri yang menentukan endpoint REST mana yang akan digunakan. Misalnya, kalau aplikasi ingin memutar lagu di Spotify, tentu ia memakai API Spotify. Kalau nanti ingin mendukung lagu dari Sonofm juga, cara lama berarti harus mengubah kode, menambah kondisi, merilis versi baru, dan memberi tahu pengguna untuk update. Sebaliknya, MCP memungkinkan hal seperti itu dikonfigurasi saat runtime, jadi terasa jauh lebih mudah diperluas
  • Perbedaan kuncinya adalah MCP mewajibkan self-description sejak awal. REST juga punya OpenAPI, tetapi itu tambahan belakangan dan tingkat pemakaian standarnya rendah. Sebaliknya, MCP menuntut deskripsi dibuka terlebih dahulu, jadi aksesibilitasnya berbeda
  • Menurut saya, satu-satunya hal yang benar-benar terasa baru dari MCP adalah bahwa pada level protokol ia mewajibkan penyediaan skema. Tentu, struktur request dan response yang konsisten juga lebih mudah dikelola bagi library yang membungkus dynamic typing dengan static typing. Sebenarnya semua orang sudah melakukan hal serupa di API. Hanya saja kita belum pernah sepakat pada bentuk envelope-nya. Karena penyediaan skema wajib dari awal, dan model AI bisa langsung memanfaatkannya, itulah mengapa MCP mendapat perhatian
  • Perbedaan besar MCP dibanding REST adalah adanya perintah bawaan list-tools. REST API punya banyak cara untuk mencantumkan resource, tetapi MCP hanya menyediakan satu cara yang terstandarisasi
  • Perbedaan besar lainnya adalah MCP punya prosedur discovery bawaan di dalam protokol. REST sama sekali tidak punya unsur yang memberi tahu klien resource apa yang tersedia atau kemampuan API itu sendiri

• Banyak orang bilang MCP luar biasa, tapi saya belum banyak melihat contoh yang benar-benar membuat sesuatu yang keren. Rasanya mirip seperti saat demam blockchain. Saya akhirnya merasa MCP ini cuma solusi sementara sampai AI menjadi lebih pintar. Mungkin dua tahun lagi, alih-alih MCP, kita akan langsung memasukkan dokumentasi tool atau OpenAPI, dan AI akan secara alami menyerap seluruh konteksnya sendiri

  • Misalnya, saya ragu sekadar memasukkan dokumentasi Ableton Live akan benar-benar membantu Claude membuat lagu sendiri
  • Sehebat apa pun model nantinya, kegunaannya tetap akan sangat terbatas jika kita tidak memberinya akses tool yang deterministik dan informasi langsung tentang keadaan dunia. Dan kalau mempertimbangkan masalah keamanan, kita juga tidak bisa membiarkan model mengirim request sembarangan di production tanpa kontrol. Saya rasa euforia MCP memang agak berlebihan, tapi masalah yang dibahas di sini tetap penting. Kalau protokol ini membuat developer membuka kapabilitas mereka dengan jelas lewat API, itu sesuatu yang sangat saya nantikan
  • Demam blockchain dan MCP cukup berbeda. Saya juga awalnya skeptis, tapi setelah sedikit mengimplementasikan server MCP sendiri, saya sadar pengalamannya benar-benar berbeda. AI percakapan/suara dan LLM saat ini, ditambah MCP dan berbagai tool serta fungsi, bisa digabungkan dengan API dan data/layanan privat, sehingga rasanya seperti memasuki frontier yang benar-benar baru. Memang belum 100% sempurna, tetapi untuk hampir semua use case nyata sudah lebih dari cukup, dan cara kita membuat aplikasi ke depan kemungkinan akan berubah besar
  • Saya sendiri penasaran dengan aktivitas para legislator negara bagian saya minggu ini, dan karena tidak ada cara mudah untuk mencari informasinya, saya mendengar bahwa MCP dan API congress.gov terdengar menarik lalu membuat server MCP. Kodenya saya buka di sini. Sekarang saya benar-benar memakainya dengan baik untuk melacak perkembangan Kongres AS secara real-time
  • Selama arsitektur model AI terus berevolusi, menurut saya lapisan middleware perantara seperti MCP tidak akan mudah hilang

• Saya merasa strategi lama Microsoft, "Embrace, Expand, Extinguish", juga sedang diterapkan di sini. Dengan alasan stabilitas dan keamanan sistem, agen yang menemukan tool secara dinamis tanpa pengelolaan jelas memang berisiko menimbulkan konflik. Memang ada alternatif seperti PydanitcAI, tetapi pada akhirnya Microsoft mendorong MCP secara resmi di 'Build 2025' dan memimpin industri mengikuti ritmenya sendiri. Anthropic merilis standar ini dalam keadaan tool-nya lemah dan tanpa governance, sehingga mudah bagi Microsoft untuk mengambil alih. Langkah berikutnya mungkin Microsoft menjadikan registry miliknya sebagai standar industri dan menggabungkannya dengan perintah yang spesifik untuk Windows. Pada akhirnya, ada gambaran bahwa mereka akan mengarahkan standar 'keamanan' agar menguntungkan dirinya sendiri dan menyingkirkan pesaing

• Bagaimana kalau unsur AI dihapus sama sekali? Jika kita langsung bergantung pada server MCP tanpa middleware AI, saya khawatir kita akan segera menghadapi masalah kompatibilitas ke belakang. Soalnya, server MCP mengasumsikan pihak yang memanggil adalah algoritma AI, jadi perubahan yang merusak kompatibilitas pada tool atau skema input/output bisa muncul kapan saja

• Saya juga sempat berpikir serupa, tetapi kemudian merasa bahwa sebagian besar server MCP sebenarnya hanya klien baru untuk API yang sudah ada. Misalnya, server MCP Kagi hanya memanggil API Kagi. Kalau begitu, bukankah lebih baik langsung memakai API-nya saja? Selain itu, jumlah interpreter Python di sistem akan terus bertambah sebanyak jumlah server MCP, jadi saya penasaran apakah nantinya akan muncul layanan 'hosting' yang menjembatani semuanya sekaligus

  • Dari yang saya pahami, MCP itu pada dasarnya seperti menambahkan satu endpoint API lagi, /list-tools, ke API yang sudah ada. Semua klien pertama-tama mengakses /list-tools untuk mendapatkan daftar tool yang tersedia, lalu memanggil API masing-masing sesudahnya
  • Pendekatan saya begini. Kalau sudah ada API dengan spesifikasi OpenAPI, bukankah tinggal dibungkus saja dengan FastMCP? Saya pernah menghubungkannya ke Goose sambil menangani permintaan autentikasi, dan pada akhirnya Goose cuma perlu mengirim perintah curl ke route API yang sudah ada. Kalau spesifikasi OpenAPI-nya cukup bagus, mungkin MCP memang tidak selalu diperlukan. Tentu, kalau belum ada API, server MCP itu sendiri bisa berkembang menjadi tempat implementasi perilaku intinya

• Banyak komentar yang skeptis, dan saya bisa memahaminya. Minggu lalu saya mencoba mengimplementasikan server MCP sendiri, dan jujur menurut saya pujian bahwa ini 'dirancang dengan baik' agak berlebihan. Salah satu tujuan MCP adalah 'agar mudah dibuat', tetapi dalam praktiknya ternyata tidak semudah itu. Meski begitu, yang penting adalah sekarang perhatian begitu banyak developer sedang terfokus ke arah yang sama. Dalam momentum seperti ini, kecepatan penyelesaian masalah bisa sangat tinggi. Selain itu, sebuah ekosistem memang butuh massa kritis untuk terbentuk, dan saya merasa titik belok itu benar-benar sedang datang sekarang. Semoga semua orang diberi kesabaran dan keberuntungan

  • Kalau hanya memakai library MCP Python, sebenarnya sangat mudah. Tinggal pasang decorator pada fungsi, dan tool langsung jadi. Saya sendiri bahkan tidak tahu protokol MCP sama sekali, tetapi dengan cara itu semuanya berjalan baik. Tentu, ceritanya bisa berbeda kalau harus mengimplementasikan protokolnya sendiri
  • Server MCP cukup mengekspos kembali "API publik atau semi-publik yang sudah ada". Pandangan bahwa implementasinya seharusnya bisa dilakukan dengan perubahan sekecil mungkin pada endpoint asli terasa meyakinkan
  • Upaya seperti ini juga pernah ada dulu, tetapi pada akhirnya setelah beberapa tahun aplikasi akan mengunci endpoint sehingga hanya server tertentu seperti chatgpt, claude, dan sejenisnya yang bisa mengakses. Interoperabilitas pada dasarnya juga berarti portabilitas pengguna, dan dalam kenyataannya banyak perusahaan teknologi lebih memilih lock-in dan monopoli daripada portabilitas

• Penting untuk ditekankan bahwa sepanjang sejarah, menurunkan hambatan akses selalu memainkan peran besar dalam adopsi dan penyebaran teknologi. MCP juga bagian dari kelanjutan itu, jadi tidak boleh diremehkan. Bahkan di tim kami, orang yang sama sekali tidak punya latar belakang teknis bisa langsung memakai agen untuk mengotomatisasi pekerjaan berbagi file. Dulu hal seperti itu hanya mungkin lewat ratusan bahasa pemrograman, library, dan API, tetapi berkat MCP, kini orang nonspesialis pun bisa langsung menyelesaikannya tanpa perlu memikirkan semua itu. Dari sisi performa mungkin bukan yang terbaik, dan implementasinya juga belum tentu optimal, tetapi nilai yang dibawa cara baru ini benar-benar belum pernah ada sebelumnya pada tingkat sumber daya dan teknologi saat ini. Menurut saya, itulah inti yang sebenarnya

  • Saya rasa cerita bahwa rekan tim yang bukan teknisi berhasil membereskan file sharing sendirian itu agak dilebih-lebihkan. Kalau cuma merapikan ribuan file mungkin lain cerita, tapi dari pengalaman saya hampir semua upaya merapikan file sharing selalu sulit bahkan untuk sekadar mendapatkan kerja sama dari departemen terkait. Orang yang bertanggung jawab atas pekerjaannya sendiri pun sering tidak mau, apalagi kalau itu bukan tugas mereka. Kadang sampai harus melibatkan eksekutif senior untuk membujuk, atau duduk bersama hanya untuk memeras struktur folder selama satu jam pun sulit. Dari total pekerjaan, 50% adalah politik antarbagian, 20% pembaruan prosedur, 20% pelatihan, dan hanya 10% masalah teknis. Saya sudah mengalami kekacauan tanpa akhir dan bencana besar maupun kecil, jadi saya sulit percaya kenyataannya sesederhana itu hanya karena tool AI membuatnya lebih mudah. Prediksi saya, beberapa bulan kemudian orang malah akan sibuk memulihkan backup

• Candaan bahwa "akan menyenangkan kalau agen AI di Warcraft 3 menerima perintah dan menjawab seperti Peon", dan saya lebih memilih naik kapal layar

  • Saya ingin menambahkan bahwa "I'd rather be sailing" itu dialog dari Warcraft 2, sedangkan di Warcraft 3 jawabannya adalah "I'd rather be flying"