WebMCP di Chrome 149: Pertanyaan yang Lebih Aman bagi Situs yang Bersiap untuk Agen AI

Chrome 149 sedang menguji sebuah gagasan yang mengubah asumsi diam-diam tentang web: halaman tidak seharusnya memaksa asisten otomatis menebak setiap tindakan penting dari piksel, label, dan DOM yang rapuh. WebMCP memungkinkan situs mengekspos alat yang terstruktur dan bernama kepada agen, sementara pekerjaannya tetap berlangsung di dalam halaman yang dapat dilihat pengguna. Arah ini masuk akal untuk layanan rumit. Namun ini bukan jalan pintas untuk memperbaiki desain produk, persetujuan, atau keamanan.

Uji coba ini penting karena banyak bisnis sudah ditanya apakah situs mereka “siap untuk agen”. Pertanyaan praktisnya lebih kecil. Tindakan mana yang cukup jelas, cukup terbatas, dan cukup dapat dibatalkan untuk dijelaskan sebagai alat? Eksperimen WebMCP yang dirancang baik dapat menjawabnya tanpa berpura-pura bahwa eksperimen browser adalah standar yang telah selesai.

WebMCP adalah usulan API web untuk mengekspos fungsi aplikasi sebagai alat yang dapat ditemukan dan dipanggil agen. Dokumentasi Chrome menjelaskan dua jalur: API JavaScript imperatif untuk mendaftarkan alat dan jalur deklaratif untuk memberi anotasi pada formulir HTML biasa. Pada keduanya, situs memberikan deskripsi dan skema input terstruktur, bukan menyuruh agen menebak arti sebuah tombol.[1]

Chrome mengumumkan origin trial mulai Chrome 149. Origin trial adalah eksperimen berbatas waktu: pengembang mendaftar, memasang token pada situs yang memenuhi syarat, menguji dengan pengguna nyata dalam batas trial, lalu mengirimkan masukan. Ini adalah bukti eksperimen implementasi, bukan janji bahwa semua browser akan mengirimkan API yang sama atau bahwa layanan produksi boleh bergantung padanya.[2]

Usulan ini terkait dengan Web Machine Learning Community Group. Dokumen terkini menyebut dirinya Draft Community Group Report dan secara tegas mengatakan bahwa ia bukan Standar W3C maupun bagian dari W3C Standards Track.[4] Kalimat itu perlu membentuk percakapan roadmap. Perlakukan WebMCP sebagai progressive enhancement, bukan syarat agar pelanggan dapat mencapai layanan.

Antarmuka untuk manusia membawa banyak makna lewat konteks. Sebuah label mungkin berada dekat satu input, pemilih kalender mungkin menyembunyikan status di balik beberapa kontrol, dan alur checkout dapat berubah setelah pengguna memilih pengiriman. Agen yang memakai otomasi browser umum bisa memeriksa petunjuk itu, tetapi setiap inferensi membuka peluang memilih bidang yang salah atau bertindak pada waktu yang salah.

WebMCP berusaha mempersempit celah tersebut. Sebuah alat dapat mempunyai nama, deskripsi, input JSON Schema, logika eksekusi, dan anotasi. Spesifikasi menyatakan halaman yang menggunakan WebMCP dapat dipandang sebagai server MCP yang diimplementasikan dengan skrip sisi klien, sementara konteks bersama dan kendali pengguna tetap berada di antarmuka web yang ada.[4] Analogi ini berguna hanya bila tetap presisi: alat itu adalah fungsi lokal halaman, bukan konektor jarak jauh tanpa batas.

Pada layanan pemesanan, alat bisa menerima rute, tanggal, jumlah penumpang, dan preferensi kabin. Pada portal dukungan, alat bisa mengumpulkan informasi diagnostik lalu membuka formulir permintaan yang tepat. Pekerjaan utamanya adalah menentukan apa yang boleh dilakukan alat, apa yang harus dikembalikan, dan kapan pengguna harus mengambil alih. Alat bernama tidak memperbaiki alur yang membingungkan. Ia hanya mengekspos asumsi alur itu dengan lebih jelas.

API imperatif cocok untuk tindakan yang memang sudah berada dalam kode aplikasi: navigasi, perubahan status, diagnostik, atau alur yang bukan formulir sederhana. Pengembang mendaftarkan fungsi dan memberi skema input. Jalur ini memberi tim kendali atas validasi, eksekusi, dan keluaran terstruktur. Ia juga menuntut tim mengembalikan kegagalan yang dapat dipahami klien, alih-alih menyembunyikannya di pesan UI saja.[1][4]

Jalur deklaratif berangkat dari formulir HTML. Dokumentasi Chrome menempatkannya sebagai cara memberi anotasi pada formulir standar sehingga agen dapat memahami tujuan formulir dan bidangnya. Ini bisa cocok ketika formulir sudah aksesibel dan semantiknya benar. Jangan memakainya sebagai alasan untuk menunda label, pesan validasi, penanganan keyboard, atau perjalanan non-agen yang layak.[1]

Kedua jalur memerlukan peninjauan yang sama. Tulis nama alat sebagai kontrak produk. Buat skema sesempit mungkin. Validasi input di sisi server ketika tindakan menjangkau server. Kembalikan hasil yang menjelaskan apa yang terjadi tanpa membocorkan rahasia. Uji pembatalan, sesi kedaluwarsa, persediaan tidak tersedia, harga berubah, dan pengguna yang berubah pikiran di tengah jalan.

Mulailah dengan tugas yang bernilai tetapi berkonsekuensi rendah. Pencarian produk, pencarian ketersediaan janji, pengarah pusat bantuan, atau draf tiket dukungan biasanya lebih aman dibanding pembayaran, penghapusan akun, atau pengajuan kontrak. Rilis pertama harus tetap menyediakan alur biasa yang lengkap bagi pengguna.

Uji pemilihan yang berguna memiliki lima pertanyaan:

• Bisakah tim menjelaskan tujuan pengguna dalam satu kalimat?
• Apakah input yang dibutuhkan eksplisit dan realistis untuk diwakili dalam skema?
• Bisakah alat menolak input tidak lengkap atau saling bertentangan dengan pesan yang berguna?
• Dapatkah hasil ditinjau atau dibatalkan sebelum komitmen yang mahal?
• Dapatkah tim mengamati kegagalan tanpa mengumpulkan data pribadi yang tidak perlu?

Jika satu jawaban saja tidak, fitur mungkin memerlukan pekerjaan produk sebelum memerlukan WebMCP. Ini bukan waktu terbuang. Perapian yang sama sering memperbaiki antarmuka bagi manusia, teknologi bantu, API, dan staf dukungan pelanggan.

Contoh Chrome sendiri mengakui bahwa sejumlah tindakan bersifat sensitif, termasuk pembelian, dan menyebut alat dapat meminta interaksi pengguna melalui dialog konfirmasi.[1] Perlakukan konfirmasi sebagai keputusan produk, bukan modal dekoratif. Halaman harus memperlihatkan apa yang akan berubah, input penting yang akan dikirim, serta harga atau komitmen bila relevan. Pengguna harus dapat menolak dengan mudah.

Pisahkan operasi baca dari operasi yang membawa konsekuensi. Mencari ketersediaan berbeda dari memesan. Membuat penawaran berbeda dari mengirimnya. Menyiapkan formulir terisi berbeda dari menyerahkannya. Pembedaan itu berguna untuk manusia dan agen, dan draf spesifikasi mencakup anotasi seperti petunjuk hanya-baca serta konsekuensial.[4]

Permintaan agen bukan bukti bahwa pengguna memahami akibatnya. Skema juga bukan sistem izin. Pemeriksaan otorisasi yang ada, pembatasan laju, kontrol penipuan, dan validasi sisi server tetap diperlukan. WebMCP seharusnya memanggil logika bisnis aman yang sama seperti antarmuka biasa. Jangan pernah menjadikannya jalur paralel yang kurang ditinjau untuk melewati pemeriksaan tersebut.

Chrome mendokumentasikan dua gerbang: isolasi origin dan Permissions Policy. WebMCP hanya tersedia pada dokumen yang origin-isolated, dan halaman harus secara eksplisit mengaktifkan kebijakan izin yang relevan, bukan mewarisi izin secara kebetulan.[1] Tim perlu menguji persyaratan ini sejak dini karena ia dapat membuka asumsi lama tentang subdomain, layanan tertanam, dan header.

Alat harus mengungkap kemampuan minimum yang menyelesaikan tugas. Jangan membuka “aksi admin” luas hanya karena lebih mudah dibuat daripada beberapa alat spesifik. Jangan menerima instruksi bebas ketika enum, pengenal, atau objek skema yang terkendali dapat menyatakan pilihan sebenarnya. Jangan mengembalikan detail akun, token, atau jejak diagnostik internal hanya karena agen memintanya.

Perlakukan isi halaman sebagai input yang mungkin tidak tepercaya. Sistem dukungan, ulasan, dokumen unggahan, dan teks yang diambil dapat memuat instruksi yang ditujukan kepada agen. Alat yang membaca materi seperti itu tidak boleh membiarkan isinya mendefinisikan ulang kewenangan alat. Anotasi untrusted content dalam usulan adalah isyarat untuk menegaskan batas, bukan pengganti threat modelling.[4]

Metrik trial terbaik bukan “jumlah alat yang didaftarkan”. Ukur apakah tugas yang tepat selesai dengan lebih sedikit koreksi, apakah pengguna memahami perpindahan kendali, dan di mana kontrak terstruktur masih menyisakan ambiguitas. Bandingkan proses dengan bantuan agen dan alur biasa. Catat kegagalan validasi alat, pembatalan, penolakan konfirmasi, serta waktu untuk pulih dari input yang keliru.

Gunakan lingkungan pengujian untuk tindakan destruktif. Simpan jejak audit yang memungkinkan tim menyusun kembali nama alat, kategori input yang tidak sensitif, hasil server, dan status konfirmasi pengguna. Tinjau catatan ini bersama dukungan pelanggan dan keamanan, bukan hanya pengembang. Pola kegagalan sering mengungkap kebijakan atau model data yang membingungkan, bukan semata masalah agen.

Chrome merujuk pengembang ke ekstensi inspector yang dapat memperlihatkan alat terdaftar, memanggilnya secara manual, dan memeriksa keluaran atau kesalahan terstruktur.[1] Ini berguna untuk pengembangan. Tetapi itu bukan pengganti riset kegunaan bersama orang yang memiliki tujuan nyata, informasi tidak lengkap, dan kebebasan untuk berhenti.

Dokumentasi Chrome menyatakan WebMCP terutama dirancang untuk alur browser lokal dengan manusia dalam lingkaran, meskipun skenario headless mungkin dapat berjalan. Dokumentasi juga mencatat bahwa antarmuka rumit mungkin perlu direfaktor untuk mengelola status aplikasi dan antarmuka, serta klien harus mengunjungi situs secara langsung agar mengetahui alat yang dapat dipanggil.[1] Batas ini bertentangan dengan fantasi bahwa situs mendadak dapat dioperasikan mesin di mana-mana.

Interoperabilitas belum selesai. Spesifikasi publiknya aktif, dan daftar isu memuat pertanyaan terbuka tentang eksekusi, kesalahan, serta integrasi formulir deklaratif.[4] Tim yang membuat abstraksi di sekeliling logika tugas akan lebih siap daripada tim yang menanam aturan bisnis langsung ke callback khusus trial. Pisahkan UI manusia, API backend, dan adaptor alat.

Ada pula pelajaran aksesibilitas. Antarmuka terstruktur bisa membantu teknologi bantu maupun agen, tetapi hanya bila produk dasarnya memiliki nama jelas, status valid, dan kesalahan yang dapat dipahami. WebMCP tidak dapat menggantikan formulir yang tidak bisa diselesaikan orang. Audit aksesibilitas yang baik karenanya adalah prasyarat masuk akal, bukan prioritas yang bersaing.

Bentuk eksperimen pertama yang praktis

Pilih satu alur kerja, sebaiknya permintaan yang bisa disiapkan sebelum menjadi komitmen. Petakan input, batasan, hasil, kesalahan, dan momen konfirmasinya di atas kertas. Buat alur biasa bekerja baik terlebih dahulu. Lalu implementasikan alat terkecil yang skemanya cocok dengan peta itu.

Gunakan kasus uji yang disengaja: input wajib hilang, rentang tanggal tidak sah, sumber daya hilang setelah ditemukan, sesi kedaluwarsa, server time-out, pembatalan, dan pengiriman yang sudah dikonfirmasi. Pastikan setiap hasil memiliki respons yang jujur dan dapat ditindaklanjuti. Pesan sukses kosong bukan kontrak.

Pasang di balik persyaratan origin trial hanya setelah header keamanan, permission policy, dan pemantauan diperiksa. Undang kelompok pengguna terbatas. Baca tiket dukungan dan hasil sesi. Hapus alat bila ia menciptakan lebih banyak kebingungan daripada manfaat. Kerja platform web eksperimental bernilai ketika mengubah keputusan berdasarkan bukti.

WebMCP paling menarik sebagai disiplin untuk menjelaskan tugas nyata. Ia meminta situs menyatakan apa arti sebuah tindakan, input apa yang diterima, status apa yang relevan, dan keputusan mana yang tetap milik manusia. Pertanyaan ini tetap berguna apakah usulan menjadi standar, berubah bentuk, atau berhenti sebagai eksperimen Chrome.

Bagi organisasi kecil, tindakan segera bukan menambahkan “dukungan agen AI” ke setiap halaman. Pilih satu perjalanan yang sulit tetapi terbatas lalu buat eksplisit. Perkuat formulir biasa, izin, dan konfirmasi. Pertahankan eksperimen sebagai pilihan. Jika WebMCP mengurangi ambiguitas pada tugas pengguna yang nyata, pekerjaannya sudah memperbaiki layanan bahkan sebelum agen memanggil alat.

Rancang alat di sekitar keputusan yang nyata

Kesalahan termudah adalah mengubah satu layar menjadi alat tanpa bertanya apakah layar itu menggambarkan keputusan yang koheren. Bayangkan permintaan dukungan teknis. Seseorang dapat datang dengan gejala, versi produk, status akun, tenggat, dan ketidakpastian tentang fakta mana yang penting. Alat yang berguna belum tentu submit_ticket. Ia mungkin identify_support_path, dengan skema kecil yang meminta produk, kategori gejala, tingkat keparahan, dan rujukan diagnostik yang sudah disetujui. Keluaran alat dapat menyarankan formulir berikutnya, menjelaskan informasi yang kurang, atau menyatakan bahwa peninjauan manusia diperlukan.

Desain itu mencegah agen menciptakan klasifikasi yang belum disetujui tim produk. Ia juga memberi kesempatan untuk menguji apakah taksonomi situs sendiri dapat dipahami. Jika skema sulit ditulis karena setiap permintaan dukungan punya belasan pengecualian, organisasi mungkin baru saja menemukan masalah produk. Jangan menyembunyikannya di balik deskripsi kabur seperti “tangani permintaan dukungan”.

Prinsip sama berlaku di perdagangan. Find compatible accessories dapat menjadi alat terbatas ketika katalog memiliki model kompatibilitas dan hasilnya adalah kandidat produk dengan batas yang jelas. Purchase everything I need bukan spesifikasi teknis. Di dalamnya ada anggaran yang belum didefinisikan, substitusi yang tidak diketahui, pilihan pengiriman, otoritas pembayaran, dan penilaian subjektif. Alat dapat membantu menyiapkan keranjang sambil membiarkan keputusan itu terlihat.

Skema membuat ambiguitas dapat diperiksa

JSON Schema bernilai karena memaksa pembedaan muncul ke permukaan. Apakah tanggal berarti hari kalender lokal atau satu titik waktu dengan zona waktu? Apakah nomor telepon opsional? Mungkinkah produk yang dipilih habis ketika tindakan dijalankan? Apakah sebuah ID milik orang, organisasi, atau sesi browser? Kontrak alat harus menyatakan pertanyaan tersebut, lalu aplikasi harus menegakkan jawabannya.

Pastikan deskripsi dekat dengan bahasa yang dipakai pelanggan. Namai input berdasarkan tujuan, bukan hanya nama kolom basis data. Beri enum label yang dapat dibaca. Jelaskan satuan. Nyatakan batas atas bila daftar atau jumlah memilikinya. Kembalikan kesalahan terstruktur yang menunjukkan kondisi dapat dipulihkan tanpa membocorkan detail implementasi internal. Pesan seperti “janji tidak lagi tersedia; minta pengguna memilih slot lain” membantu agen dan manusia. “Error 500” tidak membantu keduanya.

Desain skema juga membawa konsekuensi privasi. Kumpulkan set informasi terkecil yang menyelesaikan langkah itu. Pencarian produk tidak membutuhkan nomor identitas nasional. Pencarian pemesanan mungkin tidak membutuhkan alamat email hingga seseorang benar-benar meminta reservasi. Simpan dan kirim data pribadi sesuai kebijakan yang sama dengan formulir biasa. Adopsi alat adalah alasan untuk meninjau minimisasi data, bukan pengecualian.

Sifat praktis terkuat WebMCP ialah tindakan dapat tetap berada di pengalaman web yang terlihat. Pengguna dapat melihat hasil ketersediaan, memeriksa alamat, menyadari perubahan harga, atau menolak pengajuan yang diusulkan. Ini berbeda secara mendasar dari proses latar belakang yang menerima instruksi luas lalu menghasilkan akibat tak dapat dibatalkan di tempat lain.

Buat perpindahan kendali mudah dibaca. Ketika agen telah menyiapkan informasi, tunjukkan apa yang disiapkan dan apa yang belum diserahkan. Ketika pengguna harus mengonfirmasi, letakkan fakta relevan di permukaan konfirmasi, jangan berasumsi mereka mengingat pesan percakapan. Ketika tindakan selesai, tampilkan nomor referensi, status yang berubah, dan langkah berikutnya. Ketika gagal, pertahankan data yang sudah dimasukkan bila aman dan jelaskan apakah percobaan ulang dapat menggandakan permintaan.

Desain human-in-the-loop juga membantu tim dukungan. Mereka dapat menanyakan apa yang muncul di halaman pelanggan. Mereka dapat mereproduksi hasil alat yang sama di antarmuka. Mereka tidak perlu mendiagnosis rantai tindakan jarak jauh yang tidak transparan. Ini adalah model operasional yang lebih baik bahkan jika organisasi tidak pernah menawarkan pengalaman agen di luar trial.

Bangun untuk perubahan, bukan API yang dianggap beku

Origin trial memiliki umur terbatas dan sebuah usulan dapat berubah ketika tim sedang belajar darinya. Letakkan kode khusus trial di balik adaptor kecil, simpan aturan bisnis di lapisan layanan, dan dokumentasikan versi perilaku browser yang sudah diuji. Hindari membuat catatan basis data, janji pelanggan, atau kontrak mitra bergantung pada nama alat yang semantiknya masih dibahas.

Rencanakan fallback sebelum peluncuran. Jika API tidak tersedia, tombol, formulir, dan endpoint server yang sama harus tetap dapat digunakan seseorang. Jika klien browser tidak menemukan alat, situs masih harus mengungkap tindakan itu lewat navigasi biasa dan kontrol aksesibel. Jika token trial berakhir, perjalanan pelanggan harus turun ke jalur biasa, bukan ke layar rusak.

Disiplin ini juga membuat evaluasi lebih adil. Tim dapat membandingkan alur manusia yang stabil dengan enhancement yang jelas, bukan membandingkan alur lama dengan produk eksperimental yang terpisah. Ini juga menghindari pembersihan mahal ketika kode platform sementara terjalin dengan pembayaran, izin, atau catatan pelanggan.

Libatkan orang yang menjalankan layanan

WebMCP menyentuh lebih dari kode frontend. Pemilik proses bisnis perlu menyetujui batas tindakan. Tim dukungan perlu tahu bagaimana mengenali hasil alat dan kapan meneruskan kasus. Tim keamanan perlu memeriksa otorisasi, log, dan dampak data. Penanggung jawab aksesibilitas perlu memastikan alur biasa tidak menjadi warga kelas dua. Libatkan mereka sebelum tool pertama dibuka kepada pengguna, bukan setelah keluhan mulai masuk.

Buat contoh konkret untuk peninjauan lintas fungsi. Tunjukkan input yang diminta alat, keluaran yang dikembalikan, tindakan yang mungkin dilakukan, serta layar konfirmasi. Tanyakan siapa yang bertanggung jawab ketika alat salah mengartikan data, ketika inventaris berubah, atau ketika pelanggan membatalkan di tengah proses. Jawaban yang kabur menandakan kontrak produk belum siap.

Bahasa yang konsisten juga penting. Jika situs menyebut satu tindakan “permintaan”, jangan alat menyebutnya “pesanan” tanpa alasan. Jika operator manusia tidak diizinkan mengubah alamat setelah pengiriman dikonfirmasi, agen tidak boleh memiliki kemampuan tersirat untuk melakukannya. Kontrak yang dapat dibaca tim nonteknis lebih mudah diuji dan lebih sulit berkembang menjadi jalur khusus yang luput dari kebijakan.

Dokumentasikan kontrak yang diuji

Dokumentasi trial perlu cukup ringkas untuk dipakai, tetapi cukup lengkap untuk ditinjau. Untuk setiap alat, catat tujuan pengguna, nama dan versi skema, data yang dibaca atau ditulis, pemeriksaan otorisasi, momen konfirmasi, kode kesalahan yang diharapkan, dan pemilik layanan. Tambahkan contoh input valid dan tidak valid tanpa memakai data pelanggan asli.

Catatan itu memberi tim pijakan ketika perilaku berubah. Pengembang dapat melihat apakah perubahan API browser memengaruhi adaptor atau logika bisnis. Dukungan dapat membandingkan laporan pelanggan dengan hasil yang diharapkan. Keamanan dapat menilai apakah keluaran baru memperluas data yang diungkapkan. Tanpa catatan seperti ini, “kami sudah menguji agen” hanya menjadi ingatan yang sulit diaudit.

Tetapkan pula batas keberhasilan sebelum trial dimulai. Misalnya, alur harus menyelesaikan tugas tertentu tanpa meningkatkan permintaan eskalasi, atau konfirmasi harus dipahami sebagian besar peserta uji. Jangan mengubah definisi berhasil setelah melihat hasil yang nyaman. Bukti negatif, termasuk pengguna yang memilih jalur biasa, dapat menunjukkan bahwa alat belum menambah nilai di tahap sekarang.

Di akhir trial, ambil keputusan yang sempit. Lanjutkan hanya bila alat secara berarti memperbaiki tugas yang sudah diverifikasi tanpa menaikkan biaya dukungan, privasi, atau keamanan secara serius. Revisi bila alur dasarnya baik tetapi skema, penanganan kesalahan, atau titik konfirmasi membuat bingung. Hentikan bila eksperimen tidak dapat menunjukkan tujuan yang jelas. Menghentikan adalah hasil yang valid dari eksperimen platform.

Pertahankan pekerjaan yang tidak bergantung pada WebMCP: semantik formulir yang aksesibel, status kesalahan yang lebih jelas, antarmuka tugas bertipe, catatan audit, dan batas logika bisnis yang lebih aman. Perbaikan ini dapat melayani situs biasa, API internal, implementasi browser masa depan, atau alur dukungan. Ia mungkin kurang menarik daripada lencana “siap agen”, tetapi itulah bagian yang sungguh dialami pelanggan.

Sumber: pengumuman origin trial dan dokumentasi WebMCP dari Chrome for Developers; draf Community Group WebMCP; repositori GitHub WebMCP; Chrome Status.