MCP Tasks, Apps, dan Extensions: Mana yang Perlu Dipahami Tim Produk

Kalau tim produk membuka changelog MCP 2026-07-28 tanpa konteks, ada risiko semuanya terlihat seperti daftar fitur developer: Tasks, Apps, Extensions, MRTR, capability negotiation, authorization, dan seterusnya.

Padahal buat product manager, founder, solution architect, dan tim enterprise, tiga kata ini sebenarnya menjawab tiga pertanyaan yang sangat berbeda.

Tasks menjawab: bagaimana pekerjaan agent yang lama, asynchronous, atau butuh input tambahan dikelola?

Apps menjawab: bagaimana tool MCP bisa punya interface interaktif, bukan hanya mengembalikan teks atau data mentah?

Extensions menjawab: bagaimana capability tambahan berkembang tanpa membuat core protocol terus membengkak?

Kalau tiga layer ini dicampur, roadmap bisa berantakan. Tim melihat demo UI lalu mengira butuh Tasks. Atau punya long-running job lalu langsung membangun custom extension padahal capability resmi sudah tersedia.

Mari bedah tanpa jargon berlebihan.

Mulai dari core yang sengaja dibuat lebih kecil

MCP 2026-07-28 bergerak ke stateless core. Protocol-level sessions dan initialize handshake dihapus. Bersamaan dengan itu, sejumlah capability yang sebelumnya eksperimental atau terlalu spesifik dipindah ke extension.

Ini bukan tanda MCP kehilangan fitur.

Ini tanda protocol mulai memisahkan “apa yang semua implementasi perlu pahami” dari “capability tambahan yang hanya dibutuhkan sebagian use case”.

Buat product team, analoginya seperti platform yang punya core checkout sederhana, lalu loyalty, subscription, financing, dan marketplace ditempatkan sebagai modul. Semua penting, tetapi tidak semua merchant harus mengaktifkan semuanya.

Extensions adalah mekanisme modularity itu.

MCP 2026-07-28 menambahkan field extensions pada ClientCapabilities dan ServerCapabilities. Dengan demikian, client dan server dapat menyatakan support untuk capability di luar core.

Pertanyaannya bukan lagi, “Apakah MCP punya fitur X?”

Lebih tepat: “Apakah extension X tersedia, apakah kedua sisi mendukung, dan apakah use case kita memang membutuhkannya?”

Tasks: untuk pekerjaan yang tidak selesai dalam satu napas

Bayangkan tim procurement memakai agent untuk membuat vendor assessment.

User meminta:

“Bandingkan 80 vendor dari dokumen ini, cek compliance dasar, lalu siapkan shortlist.”

Itu bukan tool call lima ratus milidetik.

Job bisa membutuhkan beberapa menit, mungkin lebih lama. Bisa ada dependency eksternal. Bisa menunggu data. Bisa perlu user input di tengah jalan.

Di sinilah Tasks relevan.

Dalam MCP 2026-07-28, Tasks keluar dari experimental core dan menjadi extension resmi io.modelcontextprotocol/tasks. Desainnya menggunakan tasks/get untuk polling status dan tasks/update untuk client-to-server input. Server juga bisa mengembalikan task handle ketika pekerjaan harus berlanjut di luar response langsung.

Bagi PM, pikirkan Task sebagai lifecycle object.

Ia perlu status.
Ia perlu ownership.
Ia mungkin perlu cancellation.
Ia perlu result.
Ia bisa butuh input.
Ia punya failure state.

Kalau workflow produk memang asynchronous, menjadikannya first-class task biasanya lebih sehat daripada menahan koneksi lama sambil berharap proses selesai.

Skenario ilustratif:

“Kenapa user harus menunggu spinner 14 menit?” tanya PM.

“Karena prosesnya belum selesai,” jawab engineer.

“Bisa dia tutup halaman?”

“Kalau ditutup, kita kehilangan context.”

Itu alarm.

Long-running job seharusnya tidak bergantung pada user mempertahankan satu koneksi. Task handle memberi continuity yang lebih kuat.

Tetapi Tasks bukan berarti semua tool harus asynchronous.

Lookup sederhana, kalkulasi singkat, atau read operation cepat tetap lebih baik selesai langsung. Kalau semua hal dibuat task, UX justru terasa lambat dan orchestration overhead meningkat.

Gunakan Tasks ketika durasi, retry, waiting, atau human input memang membuat pekerjaan memiliki lifecycle sendiri.

Apps: ketika hasil tool perlu interface

Sekarang problem berbeda.

User meminta agent menyusun campaign. Tool menghasilkan 20 opsi headline. Menampilkan semuanya sebagai teks masih oke.

Tetapi bagaimana kalau tool harus menunjukkan dashboard interaktif, chart, map, form konfigurasi, approval table, atau preview desain?

MCP Apps hadir untuk membuat tool dapat menghadirkan UI di dalam host yang mendukungnya.

Secara product language, ini mengubah tool dari “function di belakang percakapan” menjadi “interactive surface di dalam percakapan”.

Use case-nya luas.

CRM tool bisa menampilkan tabel leads yang dapat difilter.
Design tool bisa menampilkan preview.
Finance tool bisa menampilkan breakdown biaya sebelum approval.
Travel tool bisa menampilkan pilihan itinerary.
Internal ops tool bisa menampilkan form dengan field terstruktur.

Tetapi product team harus hati-hati dengan asumsi.

MCP Apps bukan alasan memindahkan seluruh aplikasi web ke chat.

Ada task yang lebih baik tetap di full-screen product.
Ada interface kompleks yang tidak cocok di conversational host.
Ada workflow yang membutuhkan keyboard-heavy editing, comparison besar, atau visual canvas luas.

Pertanyaan yang sehat bukan, “Bisa enggak dibuat MCP App?”

Pertanyaannya, “Apakah interface embedded ini mengurangi friction dan menjaga user memahami konsekuensi action?”

Untuk approval berisiko, UI bisa membantu.

Agent berkata, “Saya siap mengubah 47 record.” App dapat menampilkan tabel perubahan, diff, filter, dan tombol konfirmasi. Itu jauh lebih informatif dibanding satu kalimat “Proceed?”

Dalam konteks agentic safety, visual clarity punya nilai operasional.

Extensions: jangan bikin core jadi gudang

Protocol yang tumbuh cepat punya masalah klasik. Semua orang punya fitur penting versi mereka sendiri.

Kalau semuanya masuk core, setiap implementer harus membawa complexity yang mungkin tidak pernah dipakai.

Extension framework memberi ruang evolusi yang lebih modular.

Product implication-nya cukup besar.

Tim tidak perlu menunggu seluruh spec core berubah untuk capability spesifik. Mereka juga tidak harus membuat proprietary fork hanya karena punya kebutuhan tambahan.

Tetapi extension juga membawa governance problem baru.

Siapa yang mendefinisikan extension?
Versi berapa yang didukung?
Apa semantics-nya konsisten?
Apakah extension wajib atau opsional?
Apa yang terjadi kalau client tidak support?
Bagaimana security review dilakukan?
Bagaimana deprecation-nya?

Jangan menganggap kata “extension” berarti bebas bikin field sesuka hati.

Semakin banyak agent interoperable lintas vendor, semakin penting namespace, versioning, documentation, dan conformance.

Kalau extension hanya dimengerti satu client dan satu server proprietary, itu mungkin tetap berguna, tetapi jangan dipasarkan sebagai interoperability universal.

Tasks dan Apps bisa bertemu

Ini bagian yang menarik buat product design.

Sebuah workflow bisa menggunakan keduanya.

Misalnya agent menjalankan analisis dataset besar.

Task dibuat dan berjalan asynchronous.

Beberapa menit kemudian status berubah menjadi membutuhkan input. User diminta memilih treatment untuk outlier tertentu.

Daripada menjawab lewat teks panjang, host menampilkan MCP App berisi chart dan tiga opsi tindakan.

User memilih satu opsi.

Client mengirim input tersebut ke task.

Job lanjut.

Hasil akhir tampil sebagai report.

Di sini Task mengelola lifecycle. App mengelola interaction surface. Extension framework memungkinkan capability itu dinegosiasikan.

Tiga layer berbeda, satu experience.

MRTR juga perlu dipahami, tetapi jangan dicampur

MCP 2026-07-28 memperkenalkan Multi Round-Trip Requests. Server dapat mengembalikan InputRequiredResult ketika butuh informasi tambahan, lalu client melanjutkan dengan inputResponses.

Untuk flow singkat seperti approval, clarification, atau elicitation, MRTR bisa cukup.

Untuk job yang benar-benar long-running dan perlu survive lintas waktu, Task lebih cocok.

Garisnya tidak selalu absolut, tetapi product team bisa memakai rule of thumb:

Jika pekerjaan masih satu logical request yang butuh satu atau beberapa input tambahan dalam prosesnya, lihat MRTR.

Jika pekerjaan memiliki lifecycle independen yang bisa dipoll, ditunda, atau berlangsung lama, lihat Tasks.

Jika user butuh interaction surface yang kaya, lihat Apps.

Jika capability itu tidak core dan perlu dinegosiasikan, lihat Extensions.

Jangan desain dari nama fitur. Desain dari user journey.

Apa yang perlu diputuskan PM sebelum engineer coding

Pertama, klasifikasikan waktu.

Apakah action selesai hampir langsung, beberapa detik, beberapa menit, atau bisa berjam-jam?

Kedua, klasifikasikan interruption.

Apakah user perlu tetap hadir? Bisa pergi lalu kembali? Apakah job harus survive restart?

Ketiga, klasifikasikan input.

Apakah agent bisa menyelesaikan dengan parameter awal, atau akan ada human confirmation, file tambahan, pilihan, atau correction?

Keempat, klasifikasikan UI.

Apakah teks cukup? Atau user perlu melihat structured diff, chart, preview, tabel, atau form?

Kelima, klasifikasikan risiko.

Apakah hasil hanya informatif? Atau action mengubah data, mengirim pesan, membuat biaya, atau memicu transaksi?

Dari lima pertanyaan itu biasanya kebutuhan Tasks, Apps, dan extension mulai terlihat.

Governance produk tidak boleh kalah cepat dari protocol

Salah satu risiko era agent protocol adalah tim terlalu cepat mengejar demo.

“Competitor punya MCP App, kita juga harus.”

“Semua workflow bikin Task.”

“Kita bikin extension custom biar kelihatan advanced.”

Itu kebalik.

Protocol adalah alat. Product requirement datang lebih dulu.

Untuk organisasi Indonesia yang baru masuk MCP, prioritasnya seharusnya boring tetapi penting:

Tool punya scope jelas.
Input tervalidasi.
Authorization benar.
High-impact action punya confirmation.
Task punya owner dan expiry.
App tidak menyembunyikan konsekuensi action.
Extension terdokumentasi dan versioned.
Observability tersedia.
Fallback tersedia ketika client tidak support fitur tertentu.

Kalau fondasi itu belum ada, UI cantik di dalam chat tidak menyelamatkan system design.

Satu hal lagi: capability detection harus masuk ke acceptance criteria

Di dunia produk biasa, acceptance criteria sering berhenti pada “fitur tampil dan bisa dipakai”. Untuk ecosystem MCP yang modular, itu kurang. Tim juga perlu menguji apa yang terjadi ketika host tidak mendukung extension tertentu.

Kalau Task extension tidak tersedia, apakah tool menolak dengan error yang jelas atau diam-diam berubah menjadi synchronous call yang rawan timeout?

Kalau Apps tidak didukung, apakah ada text fallback yang tetap membuat user memahami hasil?

Kalau client mengenali extension tetapi versinya berbeda, apakah ada negotiation atau hard failure?

Ini penting karena interoperability bukan cuma kondisi ketika semua capability cocok. Interoperability yang matang juga mengatur mismatch. Produk yang hanya bekerja pada “happy path stack kita sendiri” belum benar-benar interoperable, meskipun memakai protocol terbuka.

Buat QA, test matrix sebaiknya memasukkan supported, unsupported, partially supported, stale version, dan permission denied. Dengan begitu product behavior tetap predictable ketika ecosystem heterogen, yang justru menjadi alasan utama protocol seperti MCP dibutuhkan.

MCP 2026-07-28 justru memberi sinyal yang sehat: core dibuat lebih sederhana, capability khusus dipisahkan, dan extensibility diberikan struktur.

Buat product team, jangan hafal semua nama method.

Pahami mental model-nya.

Core untuk interoperability dasar.

Tasks untuk lifecycle pekerjaan.

Apps untuk interaction surface.

Extensions untuk capability modular.

MRTR untuk kebutuhan input tambahan dalam flow.

Authorization untuk memastikan siapa boleh melakukan apa.

Begitu mental model itu jelas, diskusi roadmap jadi jauh lebih konkret.

Bukan lagi, “Kita harus implement MCP Apps karena lagi hot.”

Tetapi, “User kita perlu review dan approve perubahan kompleks di dalam conversation, dan interface terstruktur akan mengurangi salah eksekusi. Jadi Apps relevan.”

Itu keputusan produk yang matang.