MCP 2026-07-28: Kenapa Stateless Core Mengubah Cara Server AI Dibangun

Ada jenis perubahan protocol yang kelihatannya kecil di changelog, tapi efeknya terasa sampai ke load balancer, deployment model, caching, observability, dan cara tim backend berpikir. MCP 2026-07-28 masuk kategori itu.

Perubahan headline-nya simpel: core protocol MCP sekarang stateless.

Kalau dibaca cepat, orang bisa salah menangkap: “Oh, berarti server enggak boleh punya state sama sekali.” Bukan itu maksudnya. Yang berubah adalah state di level protocol. MCP 2026-07-28 menghapus protocol-level sessions dan header Mcp-Session-Id dari Streamable HTTP. Handshake initialize dan notifications/initialized juga dihapus. Setiap request membawa informasi protocol version dan capability yang dibutuhkan melalui _meta.

Jadi bukan berarti aplikasi kita tiba-tiba dilarang menyimpan cart, job status, workflow ID, atau approval context. State bisnis masih bisa ada. Yang dipangkas adalah asumsi bahwa koneksi MCP harus dipelihara sebagai satu sesi protocol yang hidup dari request awal sampai request berikutnya.

Buat tim platform, bedanya gede.

Bayangkan percakapan ilustratif di ruang engineering.

“Kalau pod A mati setelah request pertama, request kedua harus balik ke pod A?”

“Kalau protocol-nya mengandalkan session di pod itu, bisa jadi iya atau kita harus replicate state.”

“Kalau stateless?”

“Request berikutnya bisa masuk ke instance lain, selama state yang memang dibutuhkan dibawa eksplisit atau disimpan di layer aplikasi yang benar.”

Di situlah stateless core mulai terasa bukan sebagai cosmetic cleanup, tapi sebagai perubahan arsitektur.

Dari session affinity ke ordinary HTTP infrastructure

Sistem stateless secara umum lebih mudah ditempatkan di infrastruktur HTTP yang sudah matang: reverse proxy, gateway, autoscaling, serverless runtime, multi-region routing, dan load balancer yang tidak perlu “ingat” koneksi mana milik sesi siapa.

MCP sendiri dalam rilis 2026-07-28 menjelaskan pergeseran ini sebagai langkah menuju protocol yang lebih mudah diskalakan di infrastruktur HTTP biasa. Changelog resminya menyebut penghapusan protocol-level sessions dan menjelaskan bahwa server yang membutuhkan state lintas pemanggilan dapat menggunakan handle eksplisit yang dibuat server lalu dikirim sebagai argumen tool biasa.

Ini penting.

State tidak hilang. State dipaksa menjadi lebih eksplisit.

Contoh: sebelumnya sebuah tool mungkin diam-diam bergantung pada session yang dibentuk saat initialize. Setelah stateless core, desain yang lebih sehat adalah memberi workflow handle seperti job_8f31 atau draft_29ab, lalu request berikutnya menyertakan handle tersebut. Dengan begitu, ketergantungan antar-request terlihat dalam kontrak aplikasi, bukan tersembunyi dalam koneksi.

Buat debugging, itu sering jauh lebih enak.

Kalau sebuah action gagal, engineer bisa bertanya: handle apa yang dipakai, siapa yang menerbitkan, kapan dibuat, scope-nya apa, apakah expired. Bukan sekadar, “Session-nya entah kenapa ilang.”

Request sekarang harus lebih mandiri

Dalam MCP 2026-07-28, setiap request membawa protocol version dan client capabilities di _meta. Client juga dianjurkan mengidentifikasi dirinya pada setiap request, sedangkan server mengidentifikasi dirinya pada hasil.

Konsekuensinya adalah request menjadi lebih self-describing.

Itu membantu routing dan interoperability, tetapi juga mengubah cara implementer memikirkan middleware. Middleware tidak lagi bisa mengasumsikan semua konteks penting sudah “dibuka” pada handshake lama.

Validasi protocol version harus dilakukan dengan disiplin.

Capability negotiation perlu tersedia tanpa mengandalkan memori session.

Identity informasi yang relevan perlu diperlakukan sebagai data request, bukan ambient state.

Kalau ada mismatch version, spec 2026-07-28 menetapkan UnsupportedProtocolVersionError. Ini memberi failure mode yang lebih eksplisit dibanding connection behavior yang ambigu.

server/discover jadi pintu depan baru

Bersamaan dengan hilangnya initialize handshake, MCP menambahkan server/discover. Server wajib mengimplementasikan RPC ini untuk mengiklankan protocol versions, capabilities, dan identity yang didukung.

Secara desain, ini menarik.

Discovery dipisahkan dari lifecycle session.

Client bisa bertanya lebih dulu: “Lo bisa ngomong versi berapa? Capability apa yang tersedia?” Setelah itu request bisa berjalan tanpa membangun protocol session seperti sebelumnya.

Untuk environment yang punya banyak server MCP, proxy, gateway, atau catalog internal, server/discover juga memberi titik yang relatif bersih untuk compatibility checks.

Misalnya sebuah perusahaan punya 60 MCP server internal. Sebagian sudah 2026-07-28, sebagian masih revision lama. Daripada upgrade dengan asumsi, orchestrator dapat melakukan discovery dan menentukan jalur kompatibilitas.

Tetapi jangan menganggap server/discover otomatis menyelesaikan governance. Ia memberi data. Organisasi tetap perlu policy: versi minimum apa yang diterima, capability mana yang boleh dipakai, apakah server tertentu boleh dipanggil dari environment produksi, dan bagaimana deprecation ditangani.

Stateless bukan berarti tanpa streaming

Ini salah satu miskonsepsi yang mudah muncul.

MCP tetap punya kebutuhan untuk progress, notifications, dan workflow interaktif. Yang berubah adalah bagaimana kebutuhan itu dimodelkan.

Spec 2026-07-28 mengganti HTTP GET endpoint lama dan resource subscription model dengan subscriptions/listen, sebuah long-lived POST-response stream untuk change notifications yang memang dipilih client. Sementara notification yang terkait request tertentu tetap mengalir pada response stream request tersebut.

Jadi stateless core bukan berarti semua interaksi harus satu request pendek lalu selesai.

Lebih tepatnya: long-lived communication tidak lagi dijadikan fondasi session protocol untuk semua hal.

Streaming dipakai ketika ada alasan streaming.

Subscription dipakai ketika memang ada perubahan yang ingin didengar.

State workflow dipakai ketika aplikasi membutuhkannya.

Layer-layer itu dipisahkan lebih tegas.

Kenapa ini membantu autoscaling

Misalkan sebuah MCP server dipakai 10 orang. Session affinity masih manageable.

Sekarang bayangkan dipakai ribuan agent, setiap agent membuka banyak tool calls, sebagian bursty, sebagian idle, sebagian lintas region. Kalau infrastructure layer harus mempertahankan mapping session ke instance tertentu, kompleksitas tumbuh cepat.

Stateless request memberi scheduler ruang lebih besar.

Instance mana pun yang kompatibel dapat memproses request, selama data yang diperlukan tersedia. Replica dapat ditambah atau dikurangi lebih fleksibel. Crash satu instance tidak otomatis berarti hilangnya “memory protocol” yang hanya hidup di instance tersebut.

Tetapi manfaat ini tidak gratis.

Kalau developer mengambil semua state lama lalu memasukkannya ke database global untuk setiap request, latency bisa naik. Kalau handle terlalu panjang umur, muncul lifecycle problem. Kalau state tidak punya ownership yang jelas, kebingungan pindah dari session layer ke persistence layer.

Stateless bukan magic performance button.

Ia mengubah jenis problem.

Dulu problem-nya bisa berupa sticky session, reconnect, session expiration, atau state sinkronisasi.

Sekarang problem-nya lebih banyak soal explicit state design: handle, expiry, authorization, idempotency, persistence, dan recovery.

Justru itu lebih sehat karena problem tersebut kelihatan.

Batas security ikut bergeser

Session sering menjadi tempat developer “menaruh” asumsi identity dan permission. Setelah request lebih independen, authorization tidak boleh bergantung pada memori informal seperti “client ini tadi sudah lolos di awal sesi”.

Credential dan authorization context harus divalidasi pada boundary yang tepat.

Kalau sebuah tool menerima workflow handle, jangan otomatis menganggap siapa pun yang punya handle boleh memakai workflow tersebut. Handle perlu dibind ke authorization model atau diverifikasi terhadap principal yang benar.

Ada pola sederhana yang perlu dijaga:

handle bukan permission.

ID bukan authentication.

clientInfo bukan proof of identity.

protocol capability bukan authorization grant.

Ini terdengar basic, tetapi agentic infrastructure gampang menjadi kompleks karena banyak layer bertemu: client, host, model, MCP server, third-party API, user credential, enterprise policy.

Stateless architecture yang rapi justru memaksa security boundary dibuat eksplisit.

MRTR menunjukkan bahwa “stateless” tidak berarti “single-turn”

MCP 2026-07-28 juga memperkenalkan pola Multi Round-Trip Requests atau MRTR. Server dapat mengembalikan InputRequiredResult ketika ia membutuhkan input tambahan. Client kemudian mengirim inputResponses pada retry request yang sama secara konseptual.

Ini berguna untuk approval atau elicitation.

Contoh ilustratif: agent meminta tool membuat project cloud baru. Server menghitung estimasi biaya dan membutuhkan konfirmasi user.

Alih-alih mempertahankan server-initiated interaction yang tergantung session, server dapat berkata: input tambahan diperlukan, ini pertanyaannya, ini data yang perlu disetujui. Client memperoleh jawaban user lalu melanjutkan.

Workflow tetap multi-step.

Tetapi protocol core tidak harus menyimpan satu session ambient untuk membuatnya bekerja.

Bagi product team, ini lebih dari detail SDK. Ini mengubah cara approval flow bisa didesain: state dan user input menjadi bagian yang terlihat dari workflow, bukan side-channel tersembunyi.

Apa yang perlu diaudit sebelum migrasi

Tim yang sudah punya MCP server jangan sekadar bump SDK lalu menganggap selesai.

Cari semua tempat yang bergantung pada session ID.

Apakah ada cache per-session?
Apakah user identity ditaruh di session memory?
Apakah tool list berubah tergantung koneksi?
Apakah authorization pernah “diingat” setelah initialize?
Apakah server-initiated requests bergantung pada koneksi lama?
Apakah reconnect mengandalkan SSE resumability?
Apakah long-running job punya state yang tidak pernah diberi ID eksplisit?

Changelog 2026-07-28 juga menghapus SSE stream resumability dan redelivery berbasis Last-Event-ID. Kalau response stream putus, client perlu mengulang request dengan request ID baru. Ini membuat idempotency menjadi concern praktis.

Bayangkan tool “buat invoice”. Kalau client mengulang request setelah koneksi terputus, apakah invoice kedua akan tercipta?

Kalau jawabannya “mungkin”, problem-nya bukan MCP. Problem-nya action design.

High-impact tool sebaiknya punya idempotency mechanism atau transaction semantics yang jelas.

Stateless core memperbesar pentingnya hal-hal seperti ini karena retry menjadi bagian normal dari distributed systems.

Untuk tim Indonesia, jangan buru-buru rewrite semua

Ada kecenderungan ketika spec besar keluar: semua harus migrasi minggu ini.

Tidak selalu.

Kalau server masih internal, traffic kecil, SDK lama stabil, dan belum ada kebutuhan interoperability dengan client 2026-07-28, migrasi bisa dilakukan terencana. Yang penting adalah memahami deprecation dan compatibility path, bukan panik.

Sebaliknya, kalau produk sedang membangun MCP platform baru pada Agustus 2026, mengadopsi mental model stateless sejak awal jauh lebih masuk akal daripada sengaja membangun ketergantungan pada session pattern yang sudah ditinggalkan core baru.

Buat arsitektur baru, pertanyaan desainnya berubah.

Bukan: “Session MCP ini disimpan di mana?”

Tetapi: “State bisnis apa yang benar-benar dibutuhkan, siapa pemiliknya, bagaimana direferensikan, kapan expired, dan bagaimana diotorisasi?”

Itu pertanyaan yang lebih dewasa.

GEO.or.id melihat perubahan ini sebagai sinyal bahwa agent infrastructure mulai mendekati pola web production yang sudah terbukti: request yang lebih independen, explicit versioning, infrastructure yang lebih mudah dirutekan, dan extension untuk capability tambahan.

Tetapi jangan mengubah observasi itu menjadi klaim berlebihan. Stateless tidak otomatis membuat server aman, cepat, murah, atau scalable. Implementasi tetap menentukan hasil.

Yang jelas, MCP 2026-07-28 menggeser default architecture.

Server AI tidak lagi diperlakukan seperti percakapan panjang yang harus dipelihara sebagai satu sesi protocol. Ia makin diperlakukan sebagai service yang harus bisa menerima request secara mandiri, menyatakan capability dengan jelas, memegang state hanya ketika memang dibutuhkan, dan mengembalikan workflow handle secara eksplisit.

Buat engineer, itu mungkin terdengar kurang “agentic”.

Actually, justru sebaliknya.

Semakin autonomous workflow yang kita bangun, semakin penting infrastructure di bawahnya tidak bergantung pada state tersembunyi yang sulit dilacak.

Agent boleh kompleks.

Protocol core sebaiknya tetap boring, explicit, dan bisa dioperasikan dengan baik.