"Protokol MCP-B" untuk Otomatisasi Browser AI

 (mcp-b.ai)
6 poin oleh GN⁺ 2025-07-11 | 2 komentar | Bagikan ke WhatsApp
  • MCP-B: protokol otomatisasi AI native untuk browser
  • Bukan lagi pendekatan tangkapan layar dan klik seperti sebelumnya, melainkan protokol konteks browser yang mendukung AI mengotomatiskan pekerjaan 1.000 kali lebih cepat dan lebih akurat dengan mengakses langsung API situs web
  • Dengan menambahkan hanya sekitar 50 baris kode, integrasi AI bisa langsung dilakukan menggunakan informasi autentikasi di dalam situs tanpa OAuth terpisah, API key, atau konfigurasi yang rumit
  • Dengan memanfaatkan sesi browser dan sistem autentikasi yang sudah ada, sistem ini langsung berjalan tanpa autentikasi atau pengaturan izin baru, sambil tetap menghormati kebijakan keamanan API tiap web app
  • Melalui ekstensi, asisten AI dapat berpindah antar tab dan aplikasi untuk langsung mengambil data serta menjalankan tugas, dengan peningkatan performa (eksekusi dalam hitungan beberapa ms) dan keandalan yang sangat unggul dibanding otomatisasi lama
  • Karena menggunakan akses API yang terstruktur, sistem ini bebas dari perubahan UI, kesalahan screenshot, dan masalah pengelolaan selector yang kompleks. Instalasi dan penggunaannya pun sangat sederhana

Ikhtisar MCP-B

  • MCP-B (Machine Context Protocol for Browsers) adalah model context protocol untuk browser yang menyediakan standar untuk mengendalikan dan berinteraksi dengan lingkungan browser dengan cara yang mirip otomatisasi terminal berbasis AI
  • Protokol ini secara jelas mendefinisikan komunikasi antara browser dan engine AI, sehingga berbagai otomatisasi dan interaksi model dapat distrukturkan

Perbedaan dari pendekatan lama

  • Otomatisasi browser tradisional: analisis screenshot, klik elemen, rentan terhadap perubahan UI, lambat dan tidak stabil (10~20 detik per tugas, biaya $4~5)
  • Pendekatan MCP yang ada: memerlukan API key dan autentikasi yang kompleks, sehingga hambatan masuk untuk setup awal tinggi
  • MCP-B: memanfaatkan sesi browser, akses API langsung, langsung berjalan tanpa autentikasi dan konfigurasi yang rumit

Prinsip inti dan struktur

  • Server MCP per tab: tiap web app menjalankan server MCP berbasis TypeScript sendiri (transmisi dalam memori, menggunakan ulang autentikasi cookie/JWT yang sudah ada)
  • Ekstensi MCP-B: ekstensi Chrome/Edge/Firefox (content script berkomunikasi dengan server tab melalui postMessage), menggabungkan tool dan API dari semua tab di satu tempat
  • Integrasi asisten AI: otomatisasi browser dimungkinkan melalui MCP-B di Native Bridge dan berbagai klien (Claude Desktop, Cursor IDE, dll.)

Cara penggunaan dan deployment

  • Developer: 1) instal paket 2) tambahkan kode server MCP 3) deployment selesai → tidak perlu API key terpisah, OAuth, atau konfigurasi rumit
  • Pengguna: setelah memasang ekstensi, bisa langsung digunakan; cukup dengan pengaturan AI, otomatisasi bisa segera berjalan

Keunggulan praktis

  • Autentikasi: menggunakan login dan informasi sesi situs web yang sudah ada, tanpa perlu OAuth 2.1/autentikasi terpisah
  • Performa: tugas selesai dalam hitungan ms melalui pemanggilan API langsung (peningkatan 10.000 kali dibanding sebelumnya)
  • Keamanan: berjalan di dalam aplikasi, tetap mematuhi kontrol akses dan kebijakan izin yang sudah ada
  • Skalabilitas: banyak web app, tab, dan tool AI dapat dikelola secara terintegrasi melalui MCP-B
  • Konfigurasi: cukup sekitar 50 baris kode untuk menyiapkan otomatisasi

Ringkasan perbandingan

Pendekatan Autentikasi dan konfigurasi Cara kerja Performa dan keandalan
Otomatisasi lama Autentikasi rumit, API key Screen scraping, klik Lambat dan tidak stabil (10~20 detik)
MCP lama Perlu API key, OAuth Akses API Hambatan masuk tinggi
MCP-B Tanpa konfigurasi, memakai sesi browser Pemanggilan API langsung Hitungan ms, sangat cepat/stabil

Kesimpulan: otomatisasi AI berbasis browser generasi berikutnya

  • MCP-B adalah protokol otomatisasi AI yang dioptimalkan untuk lingkungan browser, dan bersifat revolusioner dalam autentikasi, keamanan, skalabilitas, dan performa
  • Tanpa autentikasi tambahan atau konfigurasi rumit, otomatisasi AI skala besar dapat diwujudkan hanya dengan pemanggilan API langsung berbasis browser
  • Lisensi MIT, berpusat pada komunitas, mendukung semua browser utama

Bacaan terkait

2 komentar

 
shindalsoo 2025-07-12

Visi inti dari teknologi MCP-B tampaknya adalah sebagai berikut.
"Melalui perantara tepercaya berupa extension Chrome, memanfaatkan informasi pengguna yang sudah dikelola browser dengan aman (cookie, sesi, autentikasi, dan sebagainya),
memanggil dan mengendalikan 'alat (Tools)' yang telah didefinisikan sebelumnya oleh pengembang di halaman web dari jendela chat AI dengan perintah bahasa alami."

Namun, saya merasa "teknologi ini tampaknya tidak punya ruang untuk berkembang", dan saya kira alasannya adalah sebagai berikut.

  1. Resistensi pengguna: Ini adalah hambatan terbesar. Pengguna memiliki penolakan naluriah dan kekhawatiran keamanan terhadap pemasangan extension yang mengakses informasi browser mereka. Jika kenyamanan yang ditawarkan teknologi ini tidak cukup luar biasa untuk melampaui kekhawatiran tersebut, pengguna akan ragu untuk memasangnya.
  2. Beban bagi pengembang web: Selain membuat API yang sudah ada, pengembang situs web juga harus menanggung beban tambahan untuk mendefinisikan dan mengelola 'alat (Tools)' khusus untuk MCP-B secara terpisah. Jika manfaat yang diperoleh dari adopsi luas teknologi ini tidak besar, pengembang tidak akan mau melakukan upaya ganda seperti itu.
  3. Tanggung jawab atas masalah keamanan: Jika insiden keamanan terjadi melalui teknologi ini, bisa menjadi tidak jelas apakah tanggung jawab ada pada pengembang situs web, pengembang extension, atau penyedia model AI. Kompleksitas seperti ini membuat perusahaan enggan mengadopsi teknologi tersebut.
  4. Ketiadaan platform terpusat: Saat ini belum ada direktori atau platform terstandarisasi yang memberi tahu "situs web mana menyediakan alat apa". Pengguna sulit mengetahui fungsi AI apa yang tersedia sampai mereka benar-benar mengunjungi situs web tersebut.

Kesimpulannya,
ide MCP-B sendiri memang sangat menarik dan inovatif secara teknis, tetapi tampaknya tidak dapat memberikan jawaban yang jelas atas pertanyaan mendasar dari pengguna maupun pengembang: "Mengapa harus memakai cara ini?" Dibandingkan pendekatan API yang ada, manfaat yang diperoleh tidak jelas, sementara kekurangan berupa kekhawatiran keamanan dan kompleksitas pengembangan justru jelas terlihat.

Karena itu, untuk saat ini teknologi ini mungkin bisa digunakan secara eksperimental di kalangan sebagian penggemar atau pengembang dengan tujuan tertentu, tetapi tampaknya masih akan menghadapi banyak kesulitan untuk meluas ke seluruh ekosistem web.
 
GN⁺ 2025-07-11
Opini Hacker News

  • Prediksi: akan menempuh jalan yang sama seperti RSS. Perusahaan cenderung tidak suka jika pengguna bisa mengontrol sendiri cara data mereka dimanfaatkan

    • REST API juga serupa; dulu sempat diharapkan menjadi masa depan otomatisasi dan integrasi layanan seiring tren desain 'API-first'. Namun bisnis cepat sadar bahwa menyediakan kemampuan seperti ini mengancam struktur pendapatan mereka, sehingga arah tersebut segera berbalik. Pada akhirnya mereka kembali menyadari bahwa semua sumber uang bergantung pada pengguna yang tidak memiliki kendali seperti ini

    • Menurut saya RSS bukan gagal, justru sukses besar. Setelah Google Reader hilang, saya pindah ke reader lain dan feed RSS tetap berjalan baik tanpa masalah selama lebih dari 20 tahun. Saya hampir tidak pernah menemukan situs yang tidak mendukung RSS

    • Sebagian besar situs web masih mendukung RSS, dan beberapa bahkan punya feed secara default meski tidak ditampilkan di halaman. Walaupun hanya sebagian yang membuka teks lengkap, RSS tetap sangat bernilai sebagai notifikasi pembaruan atau pemicu otomatisasi. RSS masih hidup dan sangat berguna, rasanya seperti microwave: ada begitu saja dan sudah dianggap biasa

    • Struktur pasar telah berubah, dan sekarang perusahaan besar lebih fokus pada 'lapisan intelijen' daripada konten itu sendiri. Konten makin terkomoditisasi. Google harus menguasai perhatian dan tatapan pengguna, serta teknologi pintar yang membuat mereka tetap terpikat, agar bisa terus menjual iklan. Google tidak menginginkan RSS karena RSS bisa melewati Google Search

    • Saat AI segera mampu mengklik dan menggulir seperti manusia, akan terjadi lagi satu putaran persaingan tanpa akhir

  • Riwayat kontribusi proyek Github ini sangat menarik (kutipan langsung dari tautan). MiguelsPizza melakukan 3 commit, Claude 2 commit, tetapi jumlah perubahan kode dari Claude nyaris mendominasi

    • Ada sedikit perbedaan dengan riwayat sebenarnya karena ekstensi sempat dijadikan privat untuk sementara sambil menyesuaikan git history. Meski begitu, memang benar sekitar 85% keseluruhan kode ditulis oleh Claude

    • Ke depan pola seperti ini (kontribusi kode besar berbasis AI) tampaknya akan makin sering muncul

    • Grafik commit Claude sangat unik. Memang terlihat seperti Claude Code melakukan commit secara langsung, tetapi sebenarnya hampir tidak begitu. Lihat juga profil claude

    • Jika melihat daftar commit sebenarnya, semuanya tercatat atas nama MiguelsPizza / Alex Nahas (tautan). Terlihat agak aneh

  • Mengacu pada kutipan dari blog, mereka membahas masalah autentikasi di MCP. OAuth2.1 tampak baik untuk jangka panjang, tetapi kita sedang berada dalam situasi harus menemukan ulang autentikasi yang cocok untuk agen yang bertindak atas nama pengguna. Risiko kebocoran data di aplikasi multi-tenant masih belum terselesaikan

    • Membatasi jangkauan dampak dan data yang bisa diakses model bisa menjadi keunggulan besar MCP. API sisi klien pada aplikasi multi-tenant kemungkinan sudah dibatasi ke cakupan pengguna, jadi jika hanya itu yang diberikan ke model, dampaknya tidak akan besar. Disebut juga masalah kompatibilitas antara sistem autentikasi internal Amazon dan OAuth2.1 (di Amazon, autentikasinya berbeda)

    • Ada yang penasaran apakah sebagian fitur OAuth2.1 sebenarnya sudah dibahas dalam RFC 8693 tentang delegation vs impersonation

    • Pada akhirnya, cakupan yang bisa diakses model sama dengan pengguna, jadi implementasi keamanan yang solid tetap menjadi tanggung jawab pengelola situs web

    • Saya rasa contoh Amazon yang OAuth-nya tidak diterapkan dengan benar bukan inti masalahnya. Akses model pintu belakang yang melampaui cakupan izin pengguna sangat berbahaya. Jika semua tindakan aplikasi MCP dicatat dalam kategori yang sama dengan akses pengguna, bisa timbul banyak isu kepatuhan. Dari sudut pandang ini memang sangat menarik, tetapi dari sisi keamanan tampaknya bisa bermasalah sebagai jalur bypass

  • Ada yang mengusulkan ide: bukankah hampir semua implementasi ini bisa digantikan hanya dengan mempublikasikan spesifikasi Swagger(OpenAPI) dan memiliki klien swagger mcp generik? Pengguna cukup membuka sesi autentikasi sendiri secara manual. Mereka juga menyarankan bahwa jika Claude bisa memahami API key dari prompt/pengaturan dan memakai klien API berbasis swagger, hasilnya bukankah akan sama

    • Ini adalah pendekatan pertama yang terpikirkan semua orang saat MCP muncul. Namun kenyataannya terungkap bahwa ada terlalu banyak tool sehingga tidak bekerja dengan baik. Meski begitu, eksperimen menarik di area ini tetap berlanjut

    • Ada juga pengingat agar tidak menaruh API key di prompt

    • Claude Code jadi sangat nyaman untuk pengujian API bahkan jika di CLAUDE.md hanya diberi tautan swagger.json

    • Ada yang mendorong untuk langsung mencobanya

  • Tidak terlalu jelas siapa pengguna sasarannya. Dalam pengujian frontend, justru bergunanya ketika tes gagal jika UI berubah besar. Untuk tujuan otomatisasi di luar itu, saya rasa lebih baik menyediakan API yang sesungguhnya

    • Para crawler dan saya sendiri yang membeli susu dengan VLM adalah pengguna nyatanya

  • Menanggapi analogi "kalau mau membuat meja di Home Depot justru akan lebih sulit", ada yang mempertanyakan itu dengan menunjukkan bahwa Home Depot juga penuh dengan kayu

    • Home Depot juga menjual meja yang sudah jadi

    • Home Depot bahkan punya perkakas presisi yang lebih baik, juga tenaga ahli, jadi pekerjaan itu justru bisa lebih mudah

    • Lalu ada candaan dengan nuansa, "kayunya harus kamu bayangkan lalu ciptakan sendiri"

    • Mereka menyatakan sudah merevisi kalimat itu dengan mempertimbangkan masukan tersebut

  • Saya belum pernah memakai MCP secara langsung, tetapi dari sudut pandang penyandang disabilitas, MCP tampak punya potensi besar untuk penggunaan terkait aksesibilitas dalam otomatisasi browser dan smartphone. Namun teknologi seperti ini juga bisa disalahgunakan oleh pihak jahat, jadi saya ragu apakah web/aplikasi besar akan benar-benar mengadopsinya. Saya penasaran apakah sudah ada contoh penggunaan nyata untuk peningkatan aksesibilitas

    • Ada yang ingin tahu lebih spesifik bagaimana tool aksesibilitas bisa disalahgunakan

  • Saya berterima kasih karena MCP-B dirilis sebagai open source. Banyak hal memang terjadi di browser, tetapi MCP punya asumsi yang sedikit berbeda, yakni klien AI yang melakukan pekerjaan. Secara mendasar saya penasaran, apa bedanya MCP-B dengan langsung menghubungkan JS API aplikasi web ke server LLM untuk digunakan? Apakah pada akhirnya sama saja, atau ada gambaran yang lebih besar

    • Dalam jawabannya dijelaskan bahwa perbedaan mendasarnya adalah MCP-B memungkinkan pemilik situs menggunakan model yang diinginkan pengguna dengan berbagai tool situs melalui protokol standar, tanpa perlu mengimplementasikan atau mengelola fitur chat AI terpisah sendiri

  • Hanya dari isi halaman utama saya kurang paham, dan saya menganggapnya seperti versi browser dari Selenium, lalu bertanya

    • Mirip, tetapi sama sekali tidak sama. Playwright atau Selenium adalah framework otomatisasi browser, dan di server Playwright-MCP agen bisa memakai Playwright untuk otomatisasi. Sebaliknya, MCP-B menempatkan server MCP di dalam situs web, lalu menjalankan klien MCP-B lewat ekstensi browser atau injeksi JS. Playwright mem-parsing layar secara langsung, sedangkan MCP-B adalah cara pemanggilan fungsi yang terstandarisasi. Disarankan melihat contoh kode blog

  • Ada yang memperkirakan bahwa jika otomatisasi browser lewat MCP mulai digunakan oleh pengguna LLM gratis, maka kita akan masuk ke dunia di mana model gratis pun diminta menyelesaikan captcha. Masalahnya, captcha tidak terlalu efektif terhadap LLM, sehingga pada akhirnya bisa muncul era perang robot yang aneh, ketika LLM saling bertarung untuk menghalangi akses LLM otomatisasi lain

    • Dalam cerita seperti ini, akhirnya selalu mengarah pada kesimpulan bahwa para robot menyadari mereka punya tujuan yang sama lalu mulai bekerja sama