MCP 2026-07-28 Sudah Final: Bagian Mana yang Paling Mengubah Infrastruktur AI

Kalau Anda pernah menjalankan MCP server di belakang load balancer lalu mulai berurusan dengan session affinity, reconnect, stream yang putus, atau gateway yang harus memahami body request, perubahan terbesar di MCP 2026-07-28 terasa sangat konkret.

Core protocol-nya menjadi stateless.

Bukan “stateless” sebagai slogan arsitektur. Spesifikasi final 28 Juli 2026 benar-benar memensiunkan initialize/initialized exchange dan Mcp-Session-Id pada level protokol. Setiap request membawa konteks yang dibutuhkan, termasuk protocol version, client identity, dan capabilities melalui metadata. Discovery capabilities dapat dilakukan lewat server/discover, tetapi tidak wajib sebelum setiap operasi.

Di sebuah tim platform, percakapannya mungkin sederhana.

Infra engineer: “Jadi nggak perlu sticky session?”

AI engineer: “Di level protokol, iya. Tapi kalau tool kita punya state aplikasi, tetap harus kita kelola.”

Security engineer: “Bagus. Terus routing sama auth gimana?”

Nah, tiga pertanyaan itu merangkum perubahan MCP kali ini.

MCP 2026-07-28 bukan cuma update format. Ia memindahkan banyak asumsi protokol agar lebih cocok dengan infrastruktur HTTP skala produksi: stateless, routable, cacheable, dan lebih formal soal authorization serta deprecation.

Mari bedah bagian yang paling signifikan.

1. Stateless core mengubah deployment model

Pada versi sebelumnya, MCP punya lifecycle yang lebih stateful. Client dan server melakukan initialize, lalu mempertahankan session identifier di transport.

Sekarang modelnya berubah.

Request bersifat self-describing. Karena request tidak bergantung pada hidden protocol session, request dapat mendarat di instance mana pun di belakang round-robin load balancer tanpa harus memakai shared session storage hanya demi menjaga protocol state.

Ini punya efek langsung untuk cloud deployment.

Autoscaling lebih masuk akal.
Failover lebih sederhana.
Horizontal scaling tidak harus ditemani sticky-session strategy.
Gateway dan edge infrastructure lebih mudah memperlakukan MCP sebagai HTTP workload biasa.

Tetapi jangan salah paham: stateless protocol tidak berarti aplikasi Anda dilarang punya state.

Kalau workflow butuh context jangka panjang, server dapat membuat explicit handle dan meminta client atau model mengirimkannya kembali sebagai argument. Perbedaannya, state itu menjadi bagian dari application contract, bukan tersembunyi di transport session.

Bagi architecture review, ini bagus karena boundary menjadi lebih terlihat.

Anda bisa bertanya:
State ini punya owner siapa?
Berapa lama hidup?
Apakah bisa direplay?
Apakah mengandung data sensitif?
Bagaimana authorization-nya?
Bagaimana invalidation-nya?

Dulu beberapa jawaban bisa terselip di lapisan session.

Sekarang lebih sulit bersembunyi.

2. Multi Round-Trip Requests membuat flow interaktif tetap mungkin tanpa stream dua arah permanen

Masalah berikutnya muncul setelah core menjadi stateless.

Bagaimana kalau server perlu sesuatu dari client di tengah proses?

Misalnya tool sedang memproses refund dan butuh human confirmation.
Atau tool perlu parameter yang belum diberikan.
Atau server ingin sampling atau elicitation.

Spesifikasi baru memperkenalkan Multi Round-Trip Requests atau MRTR sebagai desain untuk skenario seperti ini.

Alih-alih menahan stream dua arah agar server bisa mengirim request balik, server dapat mengembalikan resultType yang menunjukkan input_required beserta request yang perlu dijawab. Client kemudian mengulang original call dengan inputResponses yang dibutuhkan.

Secara operational, ini menarik.

Approval flow menjadi lebih eksplisit.
Retry behavior lebih mudah dipikirkan.
Boundary antara “tool sedang bekerja” dan “tool menunggu input” menjadi lebih jelas.

Untuk agentic system yang melakukan aksi berisiko, clarity seperti ini penting.

Human confirmation bukan modal dialog kosmetik. Ia harus menjadi state yang benar-benar tercatat dan dihormati workflow.

MRTR membantu membuat pola itu kompatibel dengan stateless core.

3. Header-based routing membuat gateway akhirnya bisa “melihat” request MCP tanpa bongkar JSON

Streamable HTTP request sekarang membawa Mcp-Method dan Mcp-Name header.

Contohnya, gateway dapat mengetahui bahwa request adalah tools/call untuk tool tertentu melalui header, bukan dengan melakukan deep parsing terhadap JSON body.

Buat platform engineer, ini salah satu perubahan paling practical.

Rate limiter bisa membuat policy per method atau tool.
WAF dapat punya rule yang lebih spesifik.
API gateway dapat melakukan routing berdasarkan header.
Telemetry bisa mengelompokkan traffic dengan lebih murah.
Authorization layer dapat mengevaluasi route sebelum payload masuk lebih dalam.

Bayangkan perusahaan punya MCP server berisi dua tool:
read_customer_profile
issue_refund

Keduanya tidak seharusnya diperlakukan sama.

Dengan routing signal yang eksplisit, infrastructure policy bisa lebih granular.

Tentu saja header bukan pengganti authorization di application layer. Jangan membuat rule “nama tool aman berarti request aman”. Identity, scope, input validation, dan business permission tetap perlu diverifikasi.

Tetapi observability dan policy enforcement mendapat permukaan yang jauh lebih bagus.

4. List results menjadi cacheable

tools/list, prompts/list, resources/list, dan resources/read sekarang dapat membawa cache hint seperti ttlMs dan cacheScope, dengan ordering yang dibuat deterministik.

Kelihatannya kecil.

Dalam sistem dengan ribuan tool atau banyak reconnect, ini bisa berarti cukup besar.

Client tidak perlu terus-menerus meminta ulang catalog yang sama.
Prompt cache upstream lebih stabil.
Bandwidth dan latency bisa turun.
Gateway punya peluang memanfaatkan caching dengan lebih disiplin.

Tapi cache membawa problem klasik: invalidation.

Kalau permission user berubah, apakah catalog lama masih valid?
Kalau tool dinonaktifkan, berapa lama cache boleh hidup?
Kalau resource sensitif berubah, cache scope-nya apa?

Jadi fitur caching harus dibaca bersama authorization dan lifecycle data, bukan sebagai “aktifkan TTL lalu selesai”.

5. Authorization makin serius

MCP 2026-07-28 memperkeras posture authorization.

Authorization server dianjurkan mengembalikan issuer parameter sesuai RFC 9207, dan client harus memvalidasinya sebelum menukar authorization code. Client credential juga dibind ke issuer yang menerbitkannya sehingga tidak boleh dipakai lintas authorization server.

Dynamic Client Registration mulai masuk jalur deprecation, dengan arah menuju Client ID Metadata Documents atau CIMD.

Buat enterprise, ini menandakan sesuatu.

MCP tidak lagi bisa diperlakukan sebagai “tool protocol internal yang nanti security menyusul”.

Begitu MCP dipakai untuk akses data perusahaan, menjalankan action, atau berinteraksi lintas sistem, identity dan authorization menjadi bagian inti desain.

Kalau POC Anda masih memakai satu token global yang punya akses ke semuanya, versi protokol terbaru tidak otomatis memperbaiki arsitektur itu.

Protocol hardening membantu.

Security model tetap tanggung jawab implementer.

6. Extensions framework memisahkan core dan capability tambahan

Tasks dipindahkan dari experimental core ke extension io.modelcontextprotocol/tasks. Framework extensions juga menjadi lebih formal, bersama extension lain seperti MCP Apps dan Enterprise Managed Authorization.

Ini mungkin salah satu keputusan desain yang paling sehat.

Core protocol tidak perlu menyerap semua kebutuhan ekosistem.
Use case yang lebih specialized dapat berkembang sebagai extension.
Client dan server dapat menegosiasikan capability tanpa membuat semua implementasi membawa feature yang sama.

Untuk vendor, ini berarti compatibility testing perlu lebih detail.

“Support MCP 2026-07-28” belum tentu menjawab:
Extension apa yang didukung?
Versi extension berapa?
Apa fallback behavior?
Apa yang terjadi jika peer tidak mendukung capability?
Apakah security assumption berubah ketika extension aktif?

Logo compatibility saja tidak cukup.

7. Deprecation sekarang punya aturan waktu

MCP memperkenalkan formal deprecation policy dengan minimum window dua belas bulan.

Roots, Sampling, dan Logging dinyatakan deprecated. Legacy HTTP+SSE transport juga berada di jalur deprecation. Mereka masih bekerja selama transition window, tetapi implementasi baru tidak dianjurkan memulai dari sana.

Ini bagus untuk ekosistem yang bergerak cepat.

Tanpa deprecation policy, developer punya dua pilihan buruk: selalu upgrade dalam keadaan panik atau menahan versi lama terlalu lama karena takut breaking change.

Window formal membuat migration planning lebih realistis.

Namun “masih bekerja” jangan dibaca sebagai “aman dijadikan default untuk project baru”.

Kalau Anda membangun greenfield implementation setelah 28 Juli 2026, sebaiknya desain sudah mengikuti arah baru.

Apa yang harus dimigrasikan dulu?

Kalau sistem Anda sudah memakai MCP versi sebelumnya, jangan langsung rewrite semua.

Buat inventory.

Apakah Anda bergantung pada Mcp-Session-Id?
Apakah server menyimpan protocol state berdasarkan session?
Apakah client mengharuskan initialize handshake?
Apakah gateway melakukan routing dari body?
Apakah Anda memakai legacy HTTP+SSE?
Apakah workflow bergantung pada Roots, Sampling, atau Logging versi deprecated?
Apakah auth memakai DCR?
Apakah tool catalog di-fetch ulang setiap reconnect?
Apakah approval flow perlu MRTR?

Lalu klasifikasikan berdasarkan risk.

Session dependency menyentuh architecture.
Transport dependency menyentuh connectivity.
Auth dependency menyentuh security.
Deprecated capability menyentuh future compatibility.
Caching menyentuh performance.
Header routing menyentuh gateway dan observability.

Jangan migration berdasarkan urutan dokumentasi. Migration berdasarkan blast radius.

Satu hal yang juga perlu diingat: protocol upgrade bukan product upgrade.

MCP 2026-07-28 tidak membuat agent otomatis lebih pintar.
Ia tidak membuat tool otomatis aman.
Ia tidak menjamin model memilih tool yang benar.
Ia tidak menyelesaikan prompt injection.
Ia tidak membuat authorization policy untuk bisnis Anda.

Yang ia lakukan adalah menyediakan foundation yang lebih matang untuk komunikasi client-server dan ekosistem agentic.

Itu sudah sangat besar.

Dalam dunia AI 2024–2025, banyak demo agent bekerja karena semua komponen berada di laptop developer yang sama.

Di 2026, problem-nya berubah.

Bagaimana menjalankan ratusan atau ribuan MCP server?
Bagaimana melewati gateway?
Bagaimana scale out?
Bagaimana cache discovery?
Bagaimana melakukan authorization lintas environment?
Bagaimana memperkenalkan extension tanpa membuat core meledak?
Bagaimana mematikan feature lama tanpa merusak semua client?

MCP 2026-07-28 adalah jawaban terhadap kelas problem itu.

Jadi kalau harus memilih satu perubahan paling penting, jawabannya tetap stateless core.

Bukan karena paling flashy.

Justru karena ia membuat MCP lebih mirip infrastruktur web yang sudah kita tahu cara mengoperasikannya.

Request bisa diroute.
Instance bisa diskalakan.
State aplikasi bisa dibuat eksplisit.
Gateway bisa mengamati method.
Catalog bisa dicache.
Auth bisa diperkeras.
Extension bisa tumbuh di luar core.
Deprecation punya jalur.

Itulah tanda protokol mulai dewasa.

Buat organisasi yang sedang membangun agentic infrastructure, pekerjaan berikutnya bukan sekadar “upgrade SDK”.

Pekerjaan sebenarnya adalah mengecek ulang assumption architecture yang dibangun di atas versi lama.

Karena breaking change paling berbahaya bukan error compile.

Breaking change paling berbahaya adalah sistem tetap jalan, tetapi kita masih mengoperasikannya dengan mental model yang sudah tidak berlaku.

Ada konsekuensi organisasi yang sering lebih mahal daripada perubahan code: documentation debt. Ketika core berubah dari session-oriented ke stateless, diagram arsitektur, runbook incident, observability field, security review, dan onboarding engineer bisa tetap membawa mental model lama.

Karena itu migration checklist sebaiknya memasukkan artefak non-code. Update sequence diagram. Hapus asumsi sticky session dari runbook. Tambahkan Mcp-Method dan Mcp-Name ke telemetry bila memang dipakai. Dokumentasikan explicit state handle. Review threat model untuk MRTR dan authorization. Tandai capability yang deprecated beserta target removal date.

Protocol migration dianggap selesai bukan ketika unit test hijau, tetapi ketika tim on-call juga tahu bagaimana sistem baru gagal dan bagaimana cara mendiagnosisnya.