MCP Tanpa Session: Apa Keuntungan dan Risiko Arsitektur Baru

“Tanpa session” adalah frasa yang mudah bikin dua kubu salah paham sekaligus.

Kubu pertama menganggap ini kabar bagus tanpa syarat: lebih scalable, lebih simpel, selesai.

Kubu kedua langsung panik: kalau tidak ada session, bagaimana server mengingat workflow?

MCP 2026-07-28 sebenarnya berada di tengah. Protocol-level sessions memang dihapus. Header Mcp-Session-Id tidak lagi menjadi fondasi Streamable HTTP. Initialize handshake juga hilang. Tetapi aplikasi tetap boleh menyimpan state yang memang diperlukan. Bedanya, state itu harus dimodelkan lebih eksplisit lewat resource, tool argument, task handle, database, atau mekanisme aplikasi lain yang jelas.

Jadi pertanyaan yang lebih tepat bukan “MCP sekarang punya state atau tidak?”

Pertanyaannya: “State apa yang masih diperlukan, dan di layer mana state itu seharusnya hidup?”

Itu pertanyaan arsitektur yang jauh lebih penting.

Keuntungan pertama: deployment jadi lebih fleksibel

Mari pakai skenario ilustratif.

Sebuah perusahaan punya MCP server untuk akses CRM. Ada enam instance di belakang load balancer. Pada desain session-heavy, request pertama masuk instance A dan membangun context tertentu. Request kedua idealnya kembali ke A, atau state harus disinkronkan agar instance B memahami konteks yang sama.

Engineer infra lalu punya pilihan yang semuanya punya cost:

sticky session,
distributed session store,
state replication,
atau custom routing.

Stateless core mengurangi kebutuhan agar protocol bergantung pada pilihan itu.

Setiap request membawa protocol version dan client capability yang dibutuhkan. Server yang membutuhkan state lintas pemanggilan dapat memberikan handle eksplisit. Dengan pola ini, load balancer bebas mengirim request ke instance yang tersedia selama instance tersebut dapat mengakses state aplikasi yang relevan.

Untuk horizontal scaling, pola ini lebih natural.

Untuk serverless atau edge deployment, juga lebih cocok karena instance tidak harus hidup lama demi mempertahankan session MCP.

Tetapi jangan berhenti di slide arsitektur yang cantik. Stateless service bisa tetap lambat dan mahal kalau setiap request harus membuka lima database connection, membaca state besar, dan melakukan authentication handshake berat.

Arsitektur baru memberi peluang. Ia bukan jaminan performa.

Keuntungan kedua: failure lebih mudah diisolasi

Session punya efek psikologis yang unik dalam debugging. Banyak state “terasa ada”, tetapi engineer tidak selalu tahu persis state apa yang membentuk outcome tertentu.

Dengan explicit handle, dependency bisa lebih terlihat.

Misalnya tool pertama membuat draft contract dan mengembalikan draft_id. Tool berikutnya melakukan review berdasarkan draft_id itu. Tool ketiga mengekspor PDF berdasarkan revision_id.

Kalau langkah kedua gagal, kita punya objek untuk diperiksa.

Siapa membuat draft_id?
Versi berapa?
Expired atau belum?
User mana yang berhak mengakses?
Apakah revision berubah?

Bandingkan dengan bug report, “Di session user ini draft-nya tiba-tiba beda.”

Explicit state bukan hanya masalah architecture elegance. Ia memperbaiki forensic quality.

Keuntungan ketiga: caching lebih masuk akal

MCP 2026-07-28 juga menambahkan arahan caching yang lebih eksplisit untuk hasil tertentu. Tools/list, prompts/list, resources/list, resources/read, dan resources/templates/list menggunakan ttlMs dan cacheScope untuk memberi petunjuk freshness dan apakah hasil boleh berada di shared intermediary.

Pola seperti ini lebih mudah dipikirkan ketika list endpoint tidak berubah diam-diam berdasarkan koneksi tertentu.

Changelog resmi bahkan menyebut list endpoints tidak lagi bervariasi per connection.

Buat platform yang punya puluhan atau ratusan server, ini matters.

Kalau tool list deterministik dan cacheable, client tidak harus terus-menerus menarik ulang data yang sama. Prompt cache juga bisa mendapat manfaat dari urutan tool yang stabil.

Tetapi cache memperkenalkan risiko klasik: stale capability.

Tool sudah dinonaktifkan, cache belum expired.
Resource berubah, client masih melihat versi lama.
Permission berubah, cacheScope keliru.

Karena itu cacheability harus dilihat sebagai contract freshness, bukan sekadar performance hack.

Keuntungan keempat: protocol dan business state tidak tercampur

Ini mungkin manfaat konseptual terbesar.

Dulu mudah sekali membuat sesuatu seperti:

session.current_customer
session.selected_workspace
session.pending_approval
session.last_query

Semua numpuk di satu tempat karena convenient.

Setelah protocol stateless, tim dipaksa bertanya: apakah selected workspace memang business state? Apakah pending approval harus jadi objek yang bisa diaudit? Apakah last query perlu disimpan sama sekali?

Pertanyaan itu sehat.

State yang penting seharusnya punya lifecycle.

Siapa yang membuat?
Siapa yang bisa membaca?
Berapa lama hidup?
Bisa dibatalkan?
Bisa dipakai ulang?
Apa yang terjadi jika dua request datang bersamaan?

Kalau sebuah approval punya konsekuensi keuangan, menyimpannya sebagai field random dalam session jelas bukan standar governance yang bagus.

Sekarang risikonya: handle leakage

Semakin banyak state direpresentasikan oleh handle, semakin penting kita tidak menyamakan handle dengan akses.

URL dengan order_id bukan authorization.
UUID panjang bukan security boundary.
Task handle bukan bukti bahwa caller boleh mengambil task tersebut.

Ini risiko yang sering muncul di sistem API biasa dan bisa terulang di MCP.

Misalnya server membuat handle task_7df9 untuk proses rekonsiliasi data. Kalau endpoint tasks/get menerima handle itu tanpa memastikan principal yang memanggil memang berhak, attacker atau client lain yang mendapatkan handle bisa membaca hasil yang bukan miliknya.

Karena itu object-level authorization tetap wajib.

Untuk enterprise, bind state ke identity dan policy.

Untuk workflow sensitif, pertimbangkan expiry, revocation, audit log, dan scope.

Jangan mengandalkan entropy ID sebagai satu-satunya guardrail.

Risiko kedua: replay dan duplicate action

MCP 2026-07-28 menghapus SSE resumability dan message redelivery lama. Jika response stream putus, client dapat perlu mengulang request sebagai request baru.

Buat read-only tool, biasanya aman.

“Ambil daftar invoice” diulang dua kali hanya menghasilkan dua response.

Buat action tool, cerita berbeda.

“Kirim pembayaran.”
“Buat purchase order.”
“Kirim email kontrak.”
“Cancel booking.”

Jika client tidak tahu apakah action pertama sebenarnya berhasil sebelum koneksi putus, retry bisa menciptakan efek ganda.

Di sinilah idempotency harus masuk ke desain.

Skenario ilustratif:

“Request timeout. Retry aja?” tanya product engineer.

Backend engineer menjawab, “Boleh kalau endpoint-nya idempotent.”

“Kalau enggak?”

“Kita bisa bayar vendor dua kali.”

Ini bukan problem baru karena AI. Distributed systems sudah lama mengenalnya. Agent hanya meningkatkan kemungkinan action dijalankan otomatis dan cepat, sehingga kesalahan retry bisa lebih mahal.

Tool yang punya side effect sebaiknya memiliki transaction ID, idempotency key, deduplication logic, atau status query yang memadai sebelum retry.

Risiko ketiga: hidden state pindah tempat, bukan hilang

Arsitektur bisa mengklaim stateless di diagram tetapi sebenarnya menyimpan semua state di Redis dengan key yang tidak pernah dibersihkan.

Itu bukan kemenangan.

Kalau session object lama dihapus tetapi diganti workflow_blob yang berisi 5 MB context untuk setiap request, kita hanya memindahkan masalah.

State minimization tetap penting.

Simpan yang diperlukan untuk correctness, security, audit, atau user experience.

Jangan simpan hanya karena “mungkin nanti kepakai”.

Untuk agentic workflow, temptation-nya tinggi karena model menghasilkan banyak context. Tetapi protocol state dan conversational transcript bukan hal yang sama. Tidak semua percakapan perlu disimpan oleh MCP server.

Host atau aplikasi bisa memegang conversational context, sementara server hanya menerima parameter yang relevan untuk tool execution.

Itu separation of concerns yang lebih sehat.

Risiko keempat: observability harus dibangun ulang dengan mindset request

Session ID sering dipakai sebagai correlation key. Setelah protocol session hilang, tim perlu strategi tracing yang lebih eksplisit.

Untungnya MCP 2026-07-28 mendokumentasikan propagation OpenTelemetry trace context melalui _meta, termasuk traceparent, tracestate, dan baggage.

Ini sejalan dengan cara distributed systems modern ditrace.

Satu workflow bisa melewati banyak request, server, dan tool. Daripada satu session ID menjadi jawaban untuk semuanya, trace dan business correlation ID dapat memberi struktur yang lebih tepat.

Tetapi implementer tetap harus memutuskan mana yang menjadi trace, mana yang menjadi user session di aplikasi host, mana yang menjadi job ID, dan mana yang menjadi audit record.

Jangan mencampur semua ID menjadi satu.

Risiko kelima: compatibility jadi pekerjaan nyata

Client dan server yang pindah ke 2026-07-28 tidak hidup di vacuum. Ecosystem masih punya versi lama.

Karena itu server/discover dan protocol versioning penting. Client bisa mengetahui versi yang didukung sebelum menjalankan flow baru.

Tetapi tim harus merencanakan fallback.

Apa yang terjadi jika server hanya mendukung 2025-11-25?
Apakah client masih punya initialize path?
Apakah fitur baru seperti MRTR tersedia?
Apakah task extension didukung?
Apakah tool schema sama?

“Stateless” bukan flag deployment tunggal. Ia datang bersama revision protocol dengan breaking changes lain.

Migration plan harus berbicara tentang version matrix, bukan cuma mengganti session code.

State yang benar-benar perlu dipertahankan

Ada tiga kelas state yang berguna dibedakan.

Pertama, state protocol. Ini yang dipangkas besar dalam 2026-07-28.

Kedua, state aplikasi. Contohnya draft, cart, task, workflow, approval, pagination cursor, atau result yang belum selesai.

Ketiga, state pengguna atau organisasi. Contohnya account, permission, policy, subscription, preference, dan credential binding.

Kesalahan terjadi ketika ketiganya dicampur.

Protocol core tidak perlu mengingat semua hal tentang user.

Aplikasi tidak boleh menganggap business object otomatis authorized hanya karena dibuat di interaction sebelumnya.

Identity system tidak boleh bergantung pada model conversation memory.

Dengan pemisahan seperti ini, “tanpa session” justru membuat design review lebih jelas.

Checklist praktis untuk tim yang migrasi

Sebelum deploy, audit lima area.

Pertama, cari dependency pada Mcp-Session-Id dan initialize handshake.

Kedua, inventaris semua state lintas call. Putuskan apakah harus menjadi handle eksplisit, persistent object, atau sebenarnya bisa dihapus.

Ketiga, review retry semantics untuk semua tool yang punya side effect.

Keempat, pastikan authorization dilakukan pada setiap boundary yang relevan, bukan diwariskan secara informal dari interaction sebelumnya.

Kelima, bangun tracing yang tidak bergantung pada session protocol.

Tambahkan satu pertanyaan keenam untuk product team: apa yang user lihat ketika workflow terputus?

Arsitektur stateless bagus di backend, tetapi user tetap butuh continuity.

Kalau approval pending, UI harus bisa menunjukkan status.
Kalau task berjalan lama, client harus bisa mengambil statusnya.
Kalau request harus diulang, jangan membuat user mengulangi seluruh intent tanpa alasan.

Stateless protocol tidak boleh menghasilkan stateless experience.

Itu distinction yang paling penting.

GEO.or.id melihat MCP 2026-07-28 sebagai pergeseran menuju infrastructure discipline yang lebih familiar bagi tim web dan platform. Request menjadi lebih mandiri. State menjadi lebih explicit. Scaling menjadi lebih mudah dirancang. Compatibility menjadi lebih formal.

Tetapi risiko juga lebih kelihatan: replay, object authorization, stale cache, handle lifecycle, observability, dan migration complexity.

Jadi jangan menjual stateless core sebagai simplifikasi total.

Ia menyederhanakan satu layer dengan memaksa layer lain menjadi lebih benar.

Dan untuk production system, itu trade-off yang masuk akal.