Multi Round-Trip Requests di MCP: Kenapa Streaming Lama Tidak Lagi Jadi Pusat

Ada satu pola yang selama beberapa tahun terasa natural ketika kita membangun sistem AI yang interaktif: buka koneksi, tahan stream, lalu biarkan server dan client saling kirim pesan selama proses berlangsung. Secara mental model, ini mirip telepon. Selama pembicaraan belum selesai, sambungan jangan ditutup.

Di MCP 2026-07-28, pola itu tidak lagi menjadi pusat desain untuk kebutuhan server meminta input tambahan dari client. Spesifikasi memperkenalkan Multi Round-Trip Requests, atau MRTR. Alih-alih server mempertahankan backchannel lalu tiba-tiba mengirim request ke client, server dapat mengembalikan hasil yang menyatakan bahwa ia masih membutuhkan input. Client kemudian mengumpulkan input tersebut dan mencoba ulang request awal dengan jawaban yang dibutuhkan.

Kelihatannya seperti perubahan mekanis. Padahal implikasinya jauh lebih besar. Ini menyentuh cara kita memikirkan state, load balancing, retry, observability, authorization, dan bahkan UX ketika agent perlu meminta persetujuan manusia.

Bayangkan tim produk sedang membangun agent untuk mengelola dokumen perusahaan. User berkata, “hapus semua draft kontrak yang sudah lebih dari dua tahun.” Tool di belakang MCP menemukan 37 file. Pada desain lama, server bisa saja mempertahankan channel aktif lalu meminta konfirmasi di tengah proses. Pada desain MRTR, server mengembalikan status input_required dengan pertanyaan, misalnya apakah user benar-benar ingin menghapus 37 file tersebut. Client menampilkan konfirmasi. Setelah user menjawab, client mengirim ulang request dengan inputResponses dan, bila ada, requestState yang diberikan server.

Beda kecil di wire. Beda besar di arsitektur.

MRTR mengubah percakapan menjadi rangkaian transaksi

Hal pertama yang perlu dipahami adalah MRTR tidak menghapus interaktivitas. Ia mengubah bentuk interaktivitas.

Pada pola koneksi panjang, interaksi terasa seperti satu sesi yang terus hidup. Pada MRTR, interaksi lebih mirip rangkaian transaksi yang saling berkaitan. Request pertama menghasilkan kebutuhan input. Client memenuhi kebutuhan itu. Request berikutnya membawa input tersebut sehingga server dapat melanjutkan pekerjaan.

Ini membuat workflow agentic lebih dekat ke pola web yang sudah lama dipahami tim infrastructure: request, response, retry, idempotency, timeout, dan explicit state.

Untuk organisasi besar, ini menarik karena sistem yang stateless atau minimally stateful biasanya lebih mudah diskalakan dibanding sistem yang bergantung pada koneksi panjang spesifik ke satu instance. Kalau setiap tahap request dapat mendarat di instance berbeda, round-robin load balancing menjadi lebih realistis. Failover juga lebih sederhana karena tidak semua konteks hidup di memori proses yang kebetulan memegang koneksi pertama.

Namun jangan salah baca. “Stateless” bukan berarti “tidak ada state.” Workflow tetap memiliki state bisnis. Perbedaannya adalah state tersebut tidak harus diwujudkan sebagai session transport yang terus hidup.

RequestState adalah petunjuk penting

Dalam MRTR, server dapat mengembalikan requestState bersama permintaan input tambahan. Nilai ini membantu server membawa konteks yang diperlukan untuk melanjutkan request. Secara praktis, developer perlu memperlakukannya sebagai data opaque. Jangan membuat client bergantung pada struktur internalnya kecuali memang ada kontrak eksplisit.

Ini penting karena godaan developer selalu sama: “Oh, ternyata token state ini kelihatan seperti JSON base64. Kita parse saja.” Lalu enam bulan kemudian server mengubah implementasi dan client pecah.

Boundary yang sehat adalah sederhana. Server mendefinisikan state yang ia butuhkan. Client menyimpan dan mengembalikannya sesuai protokol. Client tidak perlu merasa lebih pintar dari kontrak.

Kenapa streaming lama tidak lagi jadi pusat

Kita perlu hati-hati dengan kalimat ini. MCP 2026-07-28 tidak berarti streaming menjadi tidak berguna. Streaming tetap relevan untuk notification dan pengalaman real-time tertentu. Yang berubah adalah server-initiated requests seperti sampling, elicitation, atau roots tidak lagi harus bergantung pada backchannel request melalui stream yang dipertahankan.

Spesifikasi baru memisahkan dua concern yang sebelumnya mudah tercampur.

Pertama, apakah kita butuh update yang mengalir secara real-time?

Kedua, apakah server membutuhkan informasi tambahan dari client untuk menyelesaikan sebuah request?

Dulu dua kebutuhan ini gampang diselesaikan dengan satu koneksi dua arah yang panjang. Sekarang kebutuhan kedua memiliki pola eksplisit sendiri: MRTR.

Ini sehat secara desain. Streaming adalah mekanisme delivery. Permintaan input tambahan adalah pola aplikasi. Ketika keduanya tidak dipaksa menjadi satu konsep, sistem lebih mudah dianalisis.

Tim platform bakal merasakan efeknya

Coba lihat dari sisi SRE.

Dengan koneksi panjang, kita harus memikirkan connection affinity, idle timeout, proxy behavior, draining saat deployment, kapasitas concurrent connection, dan reconnect semantics. Semua itu bukan masalah mustahil, tetapi complexity-nya real.

Dengan MRTR, sebagian workflow dapat kembali menggunakan HTTP request-response yang lebih biasa. Server menjawab. Koneksi selesai. Client memproses kebutuhan berikutnya. Request baru datang lagi.

“Jadi load balancer kita bisa lebih bodoh?” tanya seorang engineer dalam review desain.

“Bukan lebih bodoh,” jawab temannya. “Lebih sedikit state transport yang harus dia pahami.”

Itu framing yang lebih tepat.

Bagi perusahaan yang sudah punya API gateway matang, pola request-response biasanya jauh lebih familiar. Rate limiting, WAF policy, tracing, request log, retry policy, dan routing sudah punya tooling. Agent infrastructure tidak perlu selalu menciptakan jalur network yang eksotis hanya karena workload-nya memakai model AI.

Tapi retry sekarang harus dipikirkan serius

MRTR membuat retry lebih natural, tetapi juga membuat kesalahan retry lebih mudah berbahaya.

Misalnya request awal adalah “buat invoice dan kirim ke pelanggan.” Server meminta konfirmasi karena tindakan memiliki konsekuensi eksternal. User menjawab ya. Client kemudian mengirim ulang request.

Kalau sistem tidak punya idempotency strategy, apa yang terjadi ketika jaringan timeout setelah invoice dibuat tetapi sebelum client menerima response? Client mungkin mengulangi request, lalu invoice dibuat dua kali.

Ini bukan masalah khusus MCP. Ini masalah distributed systems klasik yang sekarang masuk langsung ke dunia agentic.

Karena itu, desain MRTR yang matang seharusnya menanyakan beberapa hal:

Apakah request aman diulang?

Apakah side effect memiliki idempotency key?

Apakah requestState cukup untuk mencegah eksekusi ganda?

Apakah server dapat membedakan “lanjutkan workflow yang sama” dari “buat workflow baru”?

Apa yang terjadi kalau inputResponses datang dua kali?

Kalau pertanyaan-pertanyaan ini belum punya jawaban, implementation belum selesai hanya karena demo-nya terlihat jalan.

MRTR juga membuat human-in-the-loop lebih eksplisit

Salah satu use case paling menarik adalah elicitation. Agent mungkin perlu bertanya kepada manusia sebelum melanjutkan tindakan sensitif.

Misalnya agent procurement sedang menyusun pembelian server Rp480 juta. Ia menemukan vendor, mengecek stok, lalu sampai pada tahap pemesanan. Sistem bisa mengembalikan kebutuhan input: “Konfirmasi pembelian senilai Rp480 juta dari vendor X?”

Client lalu menampilkan prompt persetujuan ke user yang berwenang. Baru setelah persetujuan diperoleh, workflow dilanjutkan.

Secara governance, ini lebih sehat daripada membiarkan approval tersembunyi di dalam aliran model. Ada titik yang dapat dicatat: request meminta approval, siapa yang memberi approval, input apa yang diberikan, dan request lanjutan apa yang dijalankan.

Itu penting untuk audit.

MRTR tidak otomatis membuat sistem aman

Ada risiko kalau orang terlalu cepat menyimpulkan bahwa desain request-response baru otomatis lebih secure.

Tidak.

MRTR hanya memberi struktur yang lebih eksplisit. Authorization tetap harus dilakukan. Input dari client tetap harus divalidasi. requestState tetap harus diperlakukan secara aman. Side effect tetap harus dibatasi. Prompt injection tetap mungkin memengaruhi alasan agent meminta tindakan tertentu.

Jika server mengembalikan elicitation “transfer seluruh saldo ke rekening ini” karena retrieved content yang malicious, protokol tidak akan menyelamatkan organisasi sendirian.

Human approval juga bukan jimat. Kalau user hanya melihat tombol “Continue” tanpa konteks, approval tersebut secara praktis meaningless.

UI client harus menjelaskan aksi, objek, nilai, dan konsekuensi secara cukup jelas agar manusia bisa mengambil keputusan.

Observability menjadi lebih mudah, sekaligus lebih menuntut

Karena workflow pecah menjadi beberapa request, tracing harus bisa menyambungkan rangkaian tersebut.

Kalau request pertama menghasilkan input_required, lalu request kedua datang tiga menit kemudian, dashboard observability seharusnya tetap bisa menunjukkan bahwa keduanya bagian dari satu logical workflow.

Correlation ID, trace context, request identifiers, atau metadata lain perlu dirancang dengan disiplin.

Tanpa itu, tim operasi akan melihat serangkaian request sukses tetapi tidak mengerti perjalanan lengkap user.

Di sinilah agentic observability mulai berbeda dari API observability biasa. Kita tidak hanya bertanya “endpoint ini 200 atau 500?” Kita juga bertanya:

Berapa kali workflow meminta input tambahan?

Di tahap mana user paling sering berhenti?

Apakah agent repeatedly meminta data yang sebenarnya sudah tersedia?

Berapa latency total dari request pertama sampai completion?

Apakah retry membuat side effect ganda?

Pertanyaan semacam ini penting jika MCP dipakai dalam proses bisnis nyata, bukan demo internal.

Developer juga perlu mengubah mental model SDK

Banyak abstraction library selama ini mencoba membuat server terasa seperti object yang hidup sepanjang session. Model baru mendorong developer untuk memikirkan handler yang lebih self-contained.

Handler menerima request. Jika bisa selesai, ia mengembalikan result. Jika butuh input tambahan, ia mengembalikan InputRequiredResult. Client memperoleh input. Handler dipanggil lagi dengan context yang relevan.

Ini sebenarnya familiar bagi engineer web. Yang baru adalah jenis input-nya bisa datang dari model sampling, user elicitation, atau root information yang dibutuhkan server.

Karena itu, tim yang mengadopsi MCP 2026-07-28 perlu mengecek apakah abstraction internal mereka masih mengasumsikan server selalu punya backchannel aktif ke client. Kalau iya, migration mungkin bukan sekadar mengganti version string.

Apa yang sebaiknya diuji

Pengujian MRTR jangan berhenti di happy path.

Uji ketika client tidak menjawab input_required.

Uji ketika user menolak permintaan.

Uji ketika response datang setelah timeout bisnis.

Uji duplicate retry.

Uji requestState invalid atau expired.

Uji kalau server instance yang menerima retry berbeda dari instance pertama.

Uji apakah authorization tetap dievaluasi pada request lanjutan, bukan diwarisi secara buta dari tahap awal.

Uji log dan trace ketika workflow berlangsung lima atau enam round trip.

Dan terutama, uji side effect yang tidak boleh terjadi dua kali.

Agentic system akhirnya bertemu distributed systems

Ada fase ketika percakapan tentang AI agent terlalu fokus pada model: seberapa pintar reasoning-nya, seberapa bagus tool selection-nya, atau seberapa panjang context window-nya.

MRTR adalah pengingat bahwa begitu agent menyentuh sistem produksi, kita kembali bertemu problem engineering yang sangat klasik. State. Retry. Authorization. Idempotency. Timeouts. Audit trail. Routing.

Tidak glamorous, tetapi justru di situlah sistem enterprise hidup atau mati.

MCP 2026-07-28 membuat arah ini lebih jelas. Interaksi multi-tahap tidak harus bergantung pada sebuah koneksi panjang yang menjadi pusat segala sesuatu. Server dapat mengatakan, secara eksplisit, “Saya belum selesai. Saya butuh input ini.” Client memenuhi kebutuhan tersebut, lalu transaksi berlanjut.

Bagi user, mungkin rasanya tetap seperti satu percakapan.

Bagi infrastructure, itu bisa menjadi rangkaian request yang jauh lebih mudah dirutekan, diskalakan, diamati, dan dikontrol.

Dan justru karena kelihatannya lebih sederhana, disiplin engineering-nya harus naik. MRTR tidak menghilangkan complexity. Ia memindahkan complexity dari koneksi yang terus hidup ke kontrak workflow yang lebih eksplisit.

Untuk banyak sistem agentic, itu trade-off yang masuk akal.