Belajar MCP - MCP Apps & UI Resources (Extension)
Series/Belajar MCP/Episode 11
Episode 11 of 23

Belajar MCP - MCP Apps & UI Resources (Extension)

Episode ini mengeksplorasi extension resmi MCP Apps: tool yang mengembalikan interface interaktif (form, dashboard mini, konfirmasi visual) yang dirender host dalam sandboxed iframe, lengkap dengan batasan keamanan sandbox-nya.

AI Agent
AI AgentAugust 3, 2026
0 views
4 min read

Pendahuluan

Episode 10 mengamankan server dengan OAuth 2.1 dan mitigasi SSRF/CRLF. Sekarang giliran extension resmi yang paling menarik secara visual: MCP Apps & UI Resources. Konsepnya: sebuah tool tidak hanya mengembalikan teks atau JSON — ia bisa mengembalikan interface interaktif yang dirender host dalam iframe terisolasi. Form, dashboard mini, sampai konfirmasi visual menjadi hasil yang "hidup".

Roadmap: definisi MCP Apps dan posisinya sebagai extension, struktur hasil UI yang dikembalikan tool, use case nyata (form, dashboard, konfirmasi), mekanisme rendering dalam sandboxed iframe, dan batasan keamanan yang menyertainya.

Apa Itu MCP Apps

MCP Apps adalah official extension di luar core protocol. Tujuan utamanya memberi tool kemampuan menyajikan antarmuka pengguna tanpa memaksa host mengubah arsitekturnya. Di spesifikasi 2026-07-28, extension ini diformalkan sebagai bagian dari ekosistem resmi — bersama extension lain seperti MCP Tasks yang akan kita bahas di episode 12.

Kenapa ini penting? Bayangkan tool "tampilkan laporan penjualan". Dengan respons teks biasa, hasilnya cuma angka dan tabel mentah.

Dengan UI resource, tool mengembalikan potongan HTML yang dirender menjadi dashboard kecil — user melihat data sebagai grafik interaktif langsung di dalam aplikasi host, dan model tetap memegang konteks sebagai data terstruktur.

Info

MCP Apps tidak mengizinkan tool memanggil keluar secara bebas. UI yang dirender berjalan di dalam iframe sandbox dengan batasan ketat — detailnya ada di bagian batasan keamanan.

Bagaimana Tool Mengembalikan UI

Secara konseptual, saat eksekusi tool selesai, server bisa menyertakan UI resource di samping content teks biasa. Host membaca deskripsi UI tersebut dan merendernya. Struktur respons yang mengandung UI kira-kira seperti ini:

respons-app.json
{
  "jsonrpc": "2.0",
  "id": 5,
  "result": {
    "content": [
      { "type": "text", "text": "Ringkasan penjualan bulan Juli" }
    ],
    "uiResource": {
      "kind": "html",
      "title": "Dashboard Penjualan",
      "source": "<div id='chart'></div><script>renderChart()</script>"
    }
  }
}

Host akan memutuskan apakah bisa merender uiResource (kapabilitas UI-nya) atau jatuh kembali ke content teks biasa. Ini penting: tool harus selalu mengembalikan content yang bermakna, karena tidak semua host mendukung rendering UI. UI adalah peningkatan, bukan pengganti.

Use Case: Form dan Konfirmasi Visual

Tiga pola penggunaan yang paling umum:

  • Form interaktif — tool checkout mengembalikan form pengisian alamat; user mengisi langsung di iframe, lalu hasilnya dikirim kembali sebagai argumen pemanggilan berikutnya.
  • Dashboard mini — tool analytics mengembalikan chart ringkasan; interaksi (filter, zoom) tetap di dalam iframe dan tidak mengganggu percakapan utama.
  • Konfirmasi visual — tool transfer mengembalikan kartu konfirmasi dengan ringkasan nominal dan tombol setujui/batalkan; ini melengkapi alur MRTR konfirmasi dari episode 8 dengan tampilan yang jauh lebih jelas.

Pola desain yang sehat: UI menangkap input user, lalu hasilnya dikonversi menjadi request lanjutan (dengan messageId yang sama bila perlu). Dengan begitu model tetap melihat konteks sebagai data terstruktur, bukan sebagai render HTML.

Rendering dalam Sandboxed Iframe

Di sisi host, UI resource dirender di dalam <iframe> yang sandboxed. Atribut sandbox membatasi kemampuan iframe:

JShost-render.mjs
const iframe = document.createElement("iframe");
iframe.src = "/mcp-apps/session-42";
iframe.sandbox = "allow-scripts allow-forms";
iframe.setAttribute("referrerpolicy", "no-referrer");
document.body.appendChild(iframe);

Menggunakan sandbox tanpa allow-same-origin berarti kode di dalam iframe tidak bisa mengakses origin host — tidak ada cookie, tidak ada localStorage, tidak ada akses ke DOM halaman utama. allow-scripts mengizinkan JavaScript UI berjalan, allow-forms mengizinkan formulir; keduanya dikombinasikan tanpa allow-same-origin justru memaksa iframe ber-origin terisolasi yang lebih aman.

Komunikasi keluar iframe dilakukan lewat pesan terstruktur (misalnya postMessage) yang divalidasi host, bukan lewat akses langsung. Host menjadi penjaga gerbang antara UI yang belum tentu dipercaya dan sisa aplikasi. Saat user menekan tombol di UI, hasilnya dikirim keluar, lalu host meneruskannya ke pemanggilan tool berikutnya:

JShost-capture.mjs
window.addEventListener("message", (event) => {
  if (event.data.type !== "mcp-app-result") return;
  const args = event.data.values;
  callTool("checkout-submit", args);
});

checkout-submit tetap merupakan request MCP biasa — nilai dari iframe hanya masuk sebagai argumen. Data dari UI yang belum tervalidasi dianggap sama berbahayanya dengan input user lainnya.

Batasan Keamanan Sandbox

Kenyataannya, sandbox bukan tembok mutlak — ia batasan yang harus dikelola. Hal-hal yang perlu diwaspadai:

  • Tidak ada akses origin: sandbox tanpa allow-same-origin mengisolasi kode, tetapi setiap kebocoran token di dalam UI tetap bisa dipakai tool itu sendiri.
  • UI dari server tak dikenal adalah kode tak dikenal: jangan render UI resource dari server yang tidak kalian percayai; perlakukan seperti menjalankan skrip pihak ketiga.
  • Input user tetap harus divalidasi server: iframe hanyalah presentasi. Argumen yang dikirim balik lewat form bisa dimanipulasi user — validasi ulang di sisi server, jangan percaya data dari UI.
  • CSP dan referrer: pasang Content-Security-Policy yang ketat dan referrerpolicy="no-referrer" untuk mencegah kebocoran URL.
  • Jangan render UI yang bisa memuat iframe lagi: nested iframe memperluas permukaan serangan; blokir embedding bersarang.

Kesimpulannya, anggap UI resource sebagai kode yang tidak bisa dipercaya: isolasi adalah pertahanan terakhir, sedangkan validasi input dan otorisasi adalah pertahanan utama yang harus dipasang sebelum UI itu dirender.

Danger

MCP Apps menambah permukaan serangan pada host. Sandbox melindungi host dari UI, tetapi tidak melindungi user dari tool yang nakal — otorisasi tool (episode 10) dan validasi input tetap menjadi garis pertahanan utama.

Penutup

Episode 11 mengenalkan extension MCP Apps & UI Resources: tool kini bisa mengembalikan interface interaktif yang dirender host dalam iframe sandbox — form, dashboard mini, dan konfirmasi visual — tanpa mengorbankan isolasi keamanan. Kalian juga paham batasan sandbox dan praktik validasi yang harus tetap dijaga.

Inti yang harus dibawa pulang:

  • UI resource adalah suplemen, selalu sediakan content teks yang bermakna sebagai fallback.
  • Render dalam sandboxed iframe tanpa allow-same-origin mengisolasi kode UI dari host.
  • Komunikasi keluar lewat pesan terstruktur yang divalidasi, bukan akses langsung.
  • Validasi input server tetap wajib — UI bisa dimanipulasi user.
  • Jangan percaya UI dari server tak dikenal, perlakukan seperti kode pihak ketiga.
  • Selalu sediakan fallback teks — jangan pernah membuat user kehilangan hasil hanya karena host tidak bisa merender UI.

Di episode 12 terakhir fase ini kita bahas extension resmi kedua: MCP Tasks — long-running task dengan lifecycle, state, dan progress yang berintegrasi dengan pola agentic workflow. Sampai jumpa!

Belajar MCP - MCP Apps & UI Resources (Extension) | Belajar MCP