Wawancara frontend: Bagaimana Anda mengekspos alat WebMCP secara aman ke agen peramban?

Pertanyaan

Sebuah halaman checkout e-commerce ingin menguji coba WebMCP agar agen peramban dapat memfilter produk dan mengisi formulir. Bagaimana Anda mendefinisikan alat, membatasi izin, mempertahankan kendali pengguna, dan memverifikasi bahwa agen tidak memanggil tindakan berdampak tinggi secara keliru?

Konteks dan batasan

WebMCP adalah standar web yang diusulkan. Dokumentasi Chrome menjelaskan alat formulir HTML deklaratif dan alat JavaScript imperatif, dan Chrome 149 menyediakan origin trial. Pertanyaan ini membahas tentang progressive enhancement di dalam tab peramban dengan keterlibatan manusia (human in the loop). WebMCP tidak diposisikan sebagai protokol backend stabil yang berjalan tanpa konteks peramban, maupun sebagai pengganti otorisasi sisi server.

Klarifikasi terlebih dahulu: Tindakan mana yang hanya melakukan pencarian dan pengisian, serta mana yang membuat pesanan atau mengenakan biaya? Haruskah alat terlihat hanya oleh halaman tingkat atas atau juga oleh iframe lintas-asal (cross-origin)? Haruskah pengguna mengonfirmasi kembali sebelum pengiriman akhir? Apa yang terjadi jika agen tidak mendukung WebMCP atau uji coba origin trial berakhir?

Hal yang diuji oleh pewawancara

Pewawancara menguji apakah Anda dapat mengubah aktuasi agen menjadi kontrak frontend: deskripsi alat dan skema input yang jelas, login yang ada, CSRF, otorisasi bisnis, serta konfirmasi pengguna yang tetap berada di jalur proses, paparan lintas-asal dengan hak istimewa terendah (least-privilege), dan evaluasi untuk pemilihan alat, parameter, serta hasil.

Jawaban 30 detik

Bagi alur pengguna menjadi tindakan hanya-baca (read-only), dapat dibatalkan (reversible), dan tidak dapat dibatalkan (irreversible). Gunakan alat deklaratif atau imperatif untuk pencarian dan pengisian formulir, sedangkan pengiriman pesanan tetap mempertahankan otorisasi server dan konfirmasi eksplisit. Ekspos hanya bidang (fields) yang diperlukan, terapkan default ke halaman dan asal (origin) saat ini, dan wajibkan Permissions Policy yang eksplisit untuk iframe lintas-asal. Sebelum perilisan, evaluasi pemilihan alat, validasi parameter, penanganan kesalahan, dan jalur penolakan, sembari mempertahankan UI normal sebagai cadangan (fallback).

Pembahasan mendalam langkah demi langkah

1. Tingkat risiko: search, filter, dan fill berisiko rendah atau dapat dibatalkan; place-order, pay, dan perubahan alamat berdampak tinggi serta tidak boleh berjalan secara otomatis hanya karena agen memiliki alat tersebut.
2. Kontrak: setiap alat mendapatkan nama yang stabil, deskripsi yang ditujukan untuk agen, skema input JSON, dan hasil terstruktur. Enumerasi, rentang, mata uang, dan versi inventaris divalidasi pada klien dan server.
3. Menggunakan kembali logika bisnis: callback memanggil status formulir dan fungsi domain yang ada, alih-alih menyalin jalur permintaan yang melewati UI. Sebelum eksekusi, periksa login, CSRF, versi keranjang, harga, dan inventaris.
4. Batas izin: secara default hanya ekspos ke jendela tingkat atas dan konteks sesama-asal (same-origin). Bagikan dengan iframe lintas-asal hanya jika Permissions-Policy dan atribut allow pada iframe secara eksplisit mengizinkannya, dan jangan mengembalikan data pribadi yang tidak diperlukan.
5. Kendali pengguna: buat pencarian dan pengisian menampilkan perubahan yang terlihat. Wajibkan konfirmasi dan ringkasan di halaman untuk pemesanan, pembayaran, atau penghapusan; hasil alat menyatakan apakah tindakan telah selesai, menunggu konfirmasi, atau ditolak.
6. Peluncuran bertahap: aktifkan akun internal di balik flag lokal atau origin trial terlebih dahulu. Sediakan deteksi kapabilitas, UI normal, dan fallback otomatisasi DOM saat WebMCP tidak tersedia; catat versi alat, hasil, dan alasan penolakan.
7. Evaluasi dan pemantauan: bangun kumpulan tugas untuk akurasi pemilihan alat, tingkat parameter valid, penyelesaian, pemanggilan keliru, ketepatan penolakan, dan cakupan konfirmasi. Tetapkan gerbang nol pemanggilan keliru untuk alat berdampak tinggi dan cabut pendaftaran jika terjadi anomali.

Jawaban teladan

Saya akan membagi proses checkout menjadi pencarian, pengisian, dan pengiriman. Pencarian dan pengisian dapat dibatalkan, sehingga WebMCP dapat meningkatkan penargetan agen. Pemesanan dan pembayaran tetap tunduk pada otorisasi server yang ada, pemeriksaan harga dan inventaris, serta konfirmasi halaman. WebMCP bersifat eksperimental; origin trial Chrome 149 cocok untuk validasi terkontrol, bukan pengganti izin backend.

Alat-alat tersebut hanya mengekspos bidang yang diperlukan untuk alur saat ini dan menggunakan kembali logika formulir serta domain yang ada di dalam callback-nya. Skema input membatasi ID item, jumlah, dan format alamat; server memeriksa kembali login, CSRF, inventaris, harga, dan idempoten pesanan. Secara default, saya mengekspos alat ke halaman tingkat atas dan agen sesama-asal. Jika iframe lintas-asal diperlukan, saya mengonfigurasi kebijakan izin dan allow iframe, serta tidak pernah mengembalikan seluruh profil akun.

const controller = new AbortController();

document.modelContext?.registerTool({
  name: "cart_set_quantity",
  description: "Set the quantity of one visible cart item; never submits an order.",
  inputSchema: {
    type: "object",
    properties: {
      itemId: { type: "string", minLength: 1 },
      quantity: { type: "integer", minimum: 1, maximum: 10 }
    },
    required: ["itemId", "quantity"]
  },
  async execute({ itemId, quantity }) {
    const result = await setVisibleCartQuantity(itemId, quantity);
    return { content: [{ type: "text", text: result.summary }] };
  }
}, { signal: controller.signal });

Bahkan jika alat pesanan ada, alat tersebut mengembalikan "konfirmasi pengguna diperlukan" dan tidak dapat menagih uang secara langsung. Setiap pemanggilan mencatat versi alat, hasil validasi parameter, dan status halaman. Kumpulan evaluasi mencakup item yang salah, jumlah berlebih, harga kedaluwarsa, konfirmasi yang ditolak, dan ketidaktersediaan WebMCP. Oleh karena itu, WebMCP adalah progressive enhancement yang dapat dicabut; otorisasi bisnis dan niat pengguna tetap berada di jalur yang sudah ada.

Kesalahan umum

• Mendeskripsikan fitur WebMCP uji coba awal sebagai API backend yang stabil.
• Mengekspos alat universal yang dapat membayar, menghapus akun, atau mengubah alamat apa pun secara langsung.
• Memvalidasi skema hanya di peramban dan melewatkan pemeriksaan server untuk login, inventaris, harga, dan idempoten.
• Membagikan alat ke iframe lintas-asal secara default atau mengembalikan profil pengguna lengkap sebagai hasil alat.
• Tidak menyediakan UI normal, deteksi kapabilitas, jalur pencabutan, atau kumpulan evaluasi agen.

Jawaban yang kuat mencakup kontrak alat, otorisasi server, isolasi asal, konfirmasi pengguna, fallback, dan evaluasi kuantitatif. "Menambahkan deskripsi ke tombol" tidak menunjukkan aktuasi yang aman.

Pertanyaan lanjutan dan tanggapan

Mengapa tidak mendaftarkan penempatan pesanan sebagai alat WebMCP juga?

Anda dapat mendaftarkan alat yang menyiapkan ringkasan pesanan, tetapi pengiriman akhir harus memerlukan konfirmasi halaman dan otorisasi server. Pemanggilan alat tidak membuktikan bahwa pengguna setuju untuk membayar dan tidak dapat melewati pemeriksaan harga, inventaris, atau penipuan (fraud).

Bagaimana cara Anda membatasi paparan alat ke iframe lintas-asal?

Jangan ekspos ke konteks lintas-asal secara default. Jika diperlukan, gunakan konfigurasi Permissions-Policy dan allow iframe yang eksplisit, lalu batasi data yang dapat dibaca dan ditulis pada lapisan alat. Catat asal, siklus hidup halaman, dan pencabutan.

Bagaimana jika agen mengirimkan parameter yang valid menurut skema tetapi tidak valid secara bisnis?

Tolak item yang tidak terlihat, status kedaluwarsa, dan nilai di luar cakupan pengguna saat ini di klien, lalu ulangi validasi bisnis di server dan kembalikan penolakan terstruktur. Jangan mengubah string menjadi tindakan arbitrer atau menulis ulang parameter secara diam-diam.

Bagaimana cara Anda membuktikan bahwa agen memahami alat tersebut?

Gunakan kumpulan tugas tetap dan halaman nyata untuk mengukur pemilihan alat, tingkat parameter valid, penyelesaian, pemanggilan keliru, dan ketepatan penolakan. Tetapkan gerbang nol pemanggilan keliru untuk pembayaran dan penghapusan, serta jalankan kembali evaluasi setelah perubahan API.