Spesifikasi baharu MCP 2026-07-28 menghapuskan setiap keperluan keadaan sesi (session-state), membolehkan setiap permintaan membawa semua data yang diperlukan. Peralihan kepada protokol tanpa keadaan (stateless) bermakna pembangun boleh menjalankan satu instans bagi setiap panggilan, beroperasi pada nod serverless atau edge, dan menamatkan sistem perpaipan penghalaan melekit (sticky-routing) serta stor kongsi yang selama ini menjadi beban dalam deployment.

Daripada Handshake kepada Panggilan Kendiri

Sehingga kini, Model Context Protocol (MCP) mewajibkan satu handshake yang mengeluarkan ID sesi. Pelayan perlu mengingati ID tersebut sepanjang hayat sambungan, yang dalam praktiknya bermaksud perlu mengekalkan proses tetap hidup, mereplikasi keadaan merentasi kluster Redis, atau mengkonfigurasi pengimbang beban untuk penghalaan "melekit" (sticky). Hasilnya ialah timbunan teknologi yang kompleks dan berat sumber yang membebankan penskalaan serta menjadikan pertumbuhan mendatar (horizontal growth) sangat mahal.

Spesifikasi baharu ini menjadikan setiap permintaan bersifat kendiri. Setiap muatan (payload) menyertakan versi protokol dan identiti pemanggil, supaya pelayan boleh melayan permintaan tersebut sebagai transaksi sekali guna. Tiada stor sesi, tiada proses jangka panjang, dan tiada peraturan penghalaan khas.

Mengapa Stateless Penting untuk Deployment

  • Sedia untuk serverless dan edge – Satu permintaan membawa segala yang diperlukannya, jadi sesuatu fungsi boleh bermula, menjawab, dan ditutup tanpa memerlukan keadaan pemanasan (warm-up state). Penyedia yang mengenakan caj mengikut setiap panggilan (per-invocation) kini menjadi lebih berdaya maju untuk beban kerja MCP.
  • Pengimbangan beban yang dipermudahkan – Pengimbang L4/L7 standard boleh mengagihkan trafik secara seragam; tidak perlu lagi mengikat (pin) pelanggan kepada bahagian belakang (backend) tertentu.
  • Pengurangan beban operasi – Pasukan boleh menamatkan penggunaan kluster Redis atau kod replikasi sesi tersuai, sekali gus mengurangkan kos dan permukaan kegagalan.

Bagi organisasi yang sudah menjalankan MCP di sebalik pengimbang beban, perubahan ini menghapuskan keperluan untuk peraturan "melekit" yang sering memaksa pengagihan trafik yang tidak sekata. Penjimatan adalah sangat ketara bagi perkhidmatan melaluiputan tinggi (high-throughput) yang menerima berjuta-juta panggilan sehari.

Peningkatan Prestasi dan Keselamatan

Spesifikasi ini menambah penambahbaikan konkrit yang memperkukuh protokol melampaui sifat statelessnya:

  • Caching berasaskan TTL – Senarai alatan (tool) dan prompt kini menyertakan medan time-to-live, membolehkan pelanggan menyimpan cache keputusan secara tempatan dan mengelakkan perjalanan balik (round-trips) yang tidak perlu.
  • Penghalaan dipacu pengepala (header) – Pengepala HTTP baharu mendedahkan maklumat penghalaan lebih awal, supaya gerbang (gateway) boleh memajukan trafik tanpa perlu menyemak keseluruhan badan JSON, sekali gus mengurangkan kependaman (latency) sebanyak beberapa milisaat.
  • Pengukuhan OAuth/OIDC – Token identiti menjalani pemeriksaan OAuth dan OpenID Connect yang lebih ketat, mengurangkan pendedahan kepada serangan ulangan (replay) dan kecurian token.
  • Rangka kerja sambungan formal – Tugasan dan Aplikasi kini tergolong dalam model sambungan yang ditakrifkan, menjadikan pelancaran ciri masa hadapan lebih lancar bagi penyenggara SDK.

Impak kepada Pembangun

Ekosistem SDK sudah pun mencerminkan perubahan ini: perpustakaan TypeScript, Python, Go dan C# sudah mengeluarkan format permintaan baharu. Jumlah muat turun gabungan SDK ini menghampiri setengah bilion sebulan, empat kali ganda lebih besar berbanding awal tahun, menunjukkan betapa meluasnya penggunaan MCP.

Pembangun mesti melaraskan sebarang kod yang mengandaikan sesi berterusan. Biasanya, ini bermakna memindahkan data khusus sesi ke dalam muatan permintaan atau ke dalam stor luaran yang dirujuk bagi setiap panggilan. Tempoh migrasi adalah dua belas bulan, memberikan masa kepada pasukan untuk melakukan penstrukturan semula (refactor), menguji, dan melancarkan corak baharu ini.

Kontra: Kerumitan Migrasi

Sifat stateless bukanlah sesuatu yang percuma. Aplikasi yang sebelum ini bergantung pada keadaan di sebelah pelayan (server-side state) untuk perkara seperti sejarah perbualan progresif kini perlu menguruskan keadaan tersebut di sebelah pelanggan (client-side) atau melalui lapisan persistensi yang berasingan.

Perkara untuk Diperhatikan

  • Metrik penggunaan – Pantau kadar penggunaan versi SDK; kelembapan boleh menandakan kesukaran migrasi.
  • Sokongan platform edge – Apabila lebih banyak penyedia mengumumkan runtime yang serasi dengan MCP, manfaat kos sebenar serverless akan menjadi lebih jelas.
  • Laporan insiden keselamatan – Aliran OAuth/OIDC yang diperkukuh sepatutnya mengurangkan serangan identiti, tetapi sebarang pelanggaran akan menguji tahap keselamatan baharu ini.

Rumusan: Dengan menjadikan MCP stateless, spesifikasi ini menyelaraskan protokol dengan corak cloud-native moden, mengurangkan beban operasi pengurusan sesi sambil membuka pintu kepada model deployment yang lebih murah dan elastik. Pertukaran (trade-off) yang perlu dihadapi adalah tempoh singkat penstrukturan semula kod dan saiz permintaan yang lebih besar, tetapi pulangan jangka panjangnya ialah protokol yang boleh diskalakan semudah infrastruktur yang menjalankannya.