Belajar MCP - Lifecycle: Initialize, Session & Stateless (2026-07-28)

#Pendahuluan

Di episode 2 kita sudah memahami arsitektur tiga lapis dan primitives MCP. Sekarang pertanyaannya: bagaimana sebuah koneksi dimulai, dirawat, dan berakhir? Jawabannya inilah yang disebut lifecycle — dan di sinilah MCP mengalami perombakan paling besar pada 2026-07-28.

Episode ini membedah dua era yang bersebrangan: era legacy yang butuh handshake initialize dan menyimpan state sesi, melawan era modern yang sepenuhnya stateless. Kalian akan paham mengapa server MCP modern bisa di-deploy di belakang load balancer tanpa sticky session — sesuatu yang menyakitkan di era legacy.

#Era Legacy: Handshake initialize dan Session State

Pada spesifikasi 2025-11-25 ke bawah, setiap koneksi MCP dimulai dengan handshake initialize yang wajib dilakukan:

1. Client mengirim request initialize berisi versi protokol, nama client, dan capabilities.
2. Server membalas dengan versi yang disepakati, nama server, dan capabilities-nya.
3. Client mengirim notifikasi initialized untuk menandai handshake selesai.
4. Baru setelah itu client boleh mengirim request lain seperti tools/list.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {},
    "clientInfo": { "name": "my-host", "version": "1.0.0" }
  }
}

Kunci dari era ini adalah session state: server mengingat informasi handshake per koneksi, dan mengidentifikasi koneksi lewat header Mcp-Session-Id. Semua request berikutnya wajib membawa Mcp-Session-Id ini, karena server butuh tahu siapa yang berbicara dan versi apa yang sedang dipakai.

#Masalah Session State

Session state memunculkan masalah yang tidak nyaman untuk production: request yang sama harus selalu jatuh ke server instance yang sama. Jika ada dua instance server di belakang load balancer, instance kedua tidak akan mengenal session dari instance pertama — hasilnya error atau re-handshake.

Solusi yang biasa dipakai adalah sticky session di load balancer. Masalahnya, sticky session membatasi distribusi beban, menyulitkan restart rolling, dan membuat horizontal scaling tidak leluasa. Inilah PR besar yang dijawab era stateless.

#Era Modern 2026-07-28: Stateless

Pada 2026-07-28, inti protokol dirombak menjadi stateless. Prinsipnya sederhana: tidak ada lagi handshake, tidak ada lagi state sesi. Setiap request berdiri sendiri dan membawa semua informasi yang dibutuhkan server:

• Versi protokol — dikirim per-request, bukan di-negosiasi sekali di awal.
• Identity — siapa client yang berbicara, dikirim per-request.
• Capabilities — kemampuan client dan server, dikirim per-request.

Karena tidak ada state di server, satu request bisa di-route ke server mana pun. Kalian bahkan bisa menaruh beberapa server berbeda di belakang satu endpoint — request dijawab oleh siapa pun yang tersedia. Untuk mencoba pola stateless ini, pastikan SDK kalian versi terbaru dengan npm install @modelcontextprotocol/sdk@latest.

Legacy  : [initialize handshake] -> [session A] -> [request pakai Mcp-Session-Id]
Modern  : [request mandiri + versi + identity + capabilities] -> [response]

#server/discover: Pengganti Handshake

Kalau tidak ada handshake, bagaimana client tahu versi dan capability server? Jawabannya adalah server/discover — sebuah method baru yang menggantikan peran handshake untuk bootstrapping, bukan untuk membentuk sesi.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "server/discover",
  "params": {
    "protocolVersion": "2026-07-28",
    "clientInfo": { "name": "my-host", "version": "1.0.0" }
  }
}

Server membalas dengan daftar protokol yang didukung, capabilities, dan versi yang dipilih. Client kemudian menyimpan hasilnya sebagai konteks — tapi tidak ada session yang "hidup" di server. Request berikutnya tetap membawa informasi versi dan identity masing-masing.

#Konsekuensi Stateless: Round-Robin dan Horizontal Scaling

Keputusan stateless membuka pintu lebar-lebar untuk operasional production:

Dengan stateless, request bisa di-route ke server mana pun — round-robin load balancer cukup membagi request rata tanpa memperhatikan session. Server mati? Request berikutnya langsung dilayani instance lain tanpa re-handshake. Ini fondasi yang membuat deployment MCP berskala besar (episode 9) dan fleet management (episode 16) menjadi masuk akal.

#Mengelola Dua Era Sekaligus

Karena ekosistem masih punya server lama, klien modern disarankan dual-era compatible: tahu cara berbicara dengan server legacy maupun modern. Polanya sederhana:

• Mulai dengan request mandiri (era modern).
• Jika server menjawab dengan kesalahan karena tidak mengenali pola stateless, client bisa fallback ke handshake initialize (era legacy).
• Simpan hasil negosiasi versi di memori client, lalu pakai sesuai era yang terdeteksi.

const discovered = await tryStatelessDiscover();
if (discovered.failed) {
  await initializeLegacyHandshake();
}

Perhatikan: ini hanyalah ilustrasi alur. Implementasi lengkap memakai SDK resmi akan kita bahas di episode 6 (server) dan episode 7 (client), dan strategi kompatibilitas dua era lebih dalam di episode 17.

#Penutup

Pada episode 3 ini kalian sudah memahami dua era lifecycle MCP: era legacy yang memakai handshake initialize plus session state Mcp-Session-Id, dan era modern 2026-07-28 yang stateless dengan versi, identity, dan capabilities dikirim per-request, ditopang server/discover untuk bootstrap.

Inti yang harus dibawa pulang:

• Era legacy butuh handshake initialize dan memakai Mcp-Session-Id untuk menyimpan state.
• Session state memaksa sticky session dan membatasi scaling — masalah utama era legacy.
• Era modern stateless: versi, identity, dan capabilities dikirim per-request.
• server/discover menggantikan handshake untuk bootstrap versi dan capability.
• Stateless memungkinkan round-robin load balancer dan horizontal scaling tanpa sticky session.

Di episode 4 berikutnya kita akan membahas Tools secara mendalam — bagaimana tool didefinisikan dengan JSON Schema, dipanggil lewat tools/call, menghasilkan structured output, dan apa itu tool annotation beserta batasannya. Sampai jumpa di episode 4!