MCP 2026-07-28 Panduan Migrasi: Server Tanpa Status

TL;DR: MCP 2026-07-28 menghapus sesi pada tingkat protokol dan handshake inisialisasi wajib. Tim produksi harus menemukan dependensi sesi tersembunyi, mengadopsi metadata protokol per permintaan, menerapkan Multi Round-Trip Requests, memperbarui kebijakan gateway, dan melakukan uji canary untuk protokol baru sebelum menghentikan perilaku legacy.

Spesifikasi Model Context Protocol yang dirilis pada 28 Juli 2026 memperkenalkan perubahan arsitektur terbesar pada MCP sejak dukungan transport jarak jauh ditambahkan.

Protokol kini menggunakan inti permintaan-dan-respons tanpa status. Pertukaran initialize dan notifications/initialized yang diwajibkan telah dihapus, Mcp-Session-Id telah dihapus, dan setiap permintaan membawa informasi protokol yang dibutuhkan untuk memprosesnya.

Rilis ini juga memperkenalkan Multi Round-Trip Requests, header perutean HTTP, respons daftar yang dapat di-cache, perilaku otorisasi yang lebih ketat, kerangka ekstensi, dan siklus hidup deprecasi yang formal. Lihat pengumuman rilis MCP 2026-07-28 resmi dan perubahan lengkap spesifikasi untuk detail tingkat protokol.

Perubahan ini membuat server MCP jarak jauh lebih mudah diskalakan di belakang infrastruktur HTTP standar. Perubahan ini tidak secara otomatis membuat aplikasi yang ada menjadi tanpa status.

Server produksi mungkin masih bergantung pada ruang kerja dalam memori, perutean lengket, kredensial terikat sesi, stream berumur panjang, atau interaksi yang diinisiasi server. Panduan ini berfokus pada menemukan dan mengganti dependensi tersebut.

Untuk panduan implementasi yang lebih pengantar, baca Cara Membuat Server MCP untuk Claude Code sebelum memulai migrasi.

Siapa yang Perlu Bermigrasi?

Tingkat usaha bergantung pada bagaimana MCP digunakan di sistem Anda.

Server lokal yang tidak mempertahankan state lintas permintaan mungkin hanya memerlukan peningkatan SDK dan pengujian kompatibilitas.

Penerapan jarak jauh yang menggunakan sesi, OAuth, streaming, atau permintaan yang diinisiasi server memerlukan migrasi bertahap.

Apa yang Berubah di MCP 2026-07-28?

1. Audit Implementasi yang Ada

Sebelum meningkatkan, cari asumsi protokol lama di klien, server, gateway, dan konfigurasi penerapan.

Mcp-Session-Id
initialize
notifications/initialized
sessionId
ctx.sessionId
extra.sessionId
sticky_session
sticky-session
elicitation/create
sampling/createMessage
roots/list
resources/subscribe
resources/unsubscribe
logging/setLevel
tasks/result
tasks/list
Last-Event-ID

Kemudian jawab pertanyaan berikut:

1. Apakah server menolak panggilan sampai inisialisasi selesai?
2. Apakah ID sesi memilih pengguna, kredensial, ruang kerja, atau percakapan?
3. Bisakah instance server lain melanjutkan alur kerja yang dimulai oleh yang pertama?
4. Apakah load balancer memerlukan afinitas sesi?
5. Apakah sebuah alat melakukan efek samping sebelum meminta konfirmasi?
6. Apakah gateway mengurai badan untuk mengidentifikasi metode atau alat?
7. Apakah kredensial OAuth disimpan tanpa server otorisasi penerbitnya?
8. Apakah klien bergantung pada penyambungan kembali SSE atau pengiriman ulang pesan?
9. Apakah daftar alat atau resource bervariasi menurut koneksi?
10. Fitur didepresiasi mana yang masih menerima trafik produksi?

Jangan hapus Mcp-Session-Id sampai Anda memahami apa yang disimpan aplikasi di baliknya.

Server yang menghapus header tetapi menyimpan state di memori lokal mungkin bekerja selama pengembangan dan gagal secara intermiten setelah permintaan didistribusikan ke beberapa instance.

2. Ganti State Sesi Tersembunyi

MCP 2026-07-28 menghapus sesi pada tingkat protokol, bukan state aplikasi.

State yang dibutuhkan lintas panggilan harus menggunakan salah satu dari tiga pola.

Handle Eksplisit

Kembalikan handle yang dicetak server dari satu alat dan wajibkan dalam panggilan berikutnya.

{
  "resultType": "complete",
  "content": [
    {
      "type": "text",
      "text": "Workspace created."
    }
  ],
  "structuredContent": {
    "workspaceHandle": "ws_7f93a2"
  }
}

Permintaan berikutnya mengirimkan handle sebagai argumen biasa:

{
  "name": "update_workspace",
  "arguments": {
    "workspaceHandle": "ws_7f93a2",
    "status": "approved"
  }
}

Ini membuat dependensi terlihat dalam kontrak alat dan memungkinkan instance server kompatibel mana pun memproses permintaan.

Penyimpanan Bersama

Gunakan database, cache terdistribusi, object store, atau sistem tugas yang tahan lama saat:

• beberapa pekerja memerlukan state yang sama;
• alur kerja harus bertahan dari restart;
• state terlalu besar untuk sebuah handle;
• alur kerja berlangsung lebih lama dari satu permintaan;
• perilaku transaksional atau sekali pakai diperlukan.

requestState Terproteksi

MRTR dapat mengembalikan nilai requestState buram yang di-echo klien saat mencoba ulang permintaan asli.

Karena nilainya melewati klien, lindungi dengan HMAC atau enkripsi terautentikasi. Ikat ke principal yang terautentikasi, operasi asli, parameter penting, waktu kedaluwarsa, dan nonce saat perlindungan replay diperlukan.

Jangan pernah mempercayai nilai requestState yang tidak ditandatangani hanya karena klien mengembalikannya tanpa perubahan.

3. Adopsi Permintaan Swakelola dan Discovery

Permintaan MCP modern menyertakan konteks protokol dalam _meta.

Panggilan alat Streamable HTTP dapat terlihat seperti ini:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
Authorization: Bearer <token>
{
  "jsonrpc": "2.0",
  "id": "req-101",
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "query": "stateless MCP migration"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "2.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

Server yang menargetkan protokol baru harus mengimplementasikan server/discover, yang mengiklankan versi, kapabilitas, dan identitas server yang didukung. Klien dapat memanggilnya sebelum operasi lain atau menggunakannya untuk menentukan apakah diperlukan fallback legacy.

Baca dokumentasi server/discover resmi untuk kontrak respons.

Negosiasi Versi SDK TypeScript

Meningkatkan SDK TypeScript saja tidak secara otomatis mengalihkan klien ke protokol baru.

Klien yang menggunakan SDK v2 harus secara eksplisit memilih:

const client = new Client(
  {
    name: "my-client",
    version: "1.0.0"
  },
  {
    versionNegotiation: {
      mode: "auto"
    }
  }
);

await client.connect(transport);

Dalam mode otomatis, SDK melakukan probe dengan server/discover dan dapat melakukan fallback ke alur inisialisasi lama saat terhubung dengan server legacy.

Tim yang masih menggunakan @modelcontextprotocol/sdk v1 harus terlebih dahulu mengikuti panduan migrasi SDK TypeScript v1-ke-v2 resmi. Tim yang sudah menggunakan v2 harus menggunakan panduan dukungan protokol 2026-07-28 terpisah.

4. Ganti Permintaan yang Diinisiasi Server dengan MRTR

Implementasi MCP sebelumnya dapat mengirim permintaan seperti elicitation/create, sampling/createMessage, atau roots/list dari server ke klien.

Protokol baru mengganti model tersebut dengan Multi Round-Trip Requests.

Alurnya adalah:

1. Klien mengirim permintaan asli.
2. Server mengembalikan resultType: "input_required".
3. Klien mengumpulkan informasi atau persetujuan yang diminta.
4. Klien mencoba ulang operasi asli menggunakan ID JSON-RPC baru.
5. Percobaan ulang menyertakan inputResponses dan requestState asli.
6. Server menyelesaikan permintaan atau memulai putaran lain.

Respons contoh:

{
  "jsonrpc": "2.0",
  "id": "delete-1",
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "confirm_delete": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Delete project project_123?",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "confirmed": {
                "type": "boolean"
              }
            },
            "required": ["confirmed"]
          }
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

Klien mencoba ulang operasi asli:

{
  "jsonrpc": "2.0",
  "id": "delete-2",
  "method": "tools/call",
  "params": {
    "name": "delete_project",
    "arguments": {
      "projectId": "project_123"
    },
    "inputResponses": {
      "confirm_delete": {
        "action": "accept",
        "content": {
          "confirmed": true
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

Implementasi MRTR produksi harus mendefinisikan:

• jumlah putaran maksimum;
• kedaluwarsa state permintaan;
• perilaku pembatalan dan penolakan;
• validasi skema respons;
• pemeriksaan otorisasi pada setiap percobaan ulang;
• perlindungan replay;
• idempoten untuk efek samping;
• perilaku saat klien tidak mendukung kapabilitas yang diminta.

Hindari menyelesaikan pembelian, penghapusan, pengurangan kredit, atau penulisan eksternal sebelum mengembalikan input_required.

Gunakan operasi bertahap atau kunci idempoten agar percobaan ulang tidak menggandakan tindakan. Lihat spesifikasi MRTR resmi untuk model interaksi lengkap.

5. Perbarui Gateway, Caching, dan Otorisasi

Perubahan infrastruktur saling terkait dan harus diuji bersama.

Validasi Header Perutean MCP

Permintaan POST Streamable HTTP kini menyertakan:

• MCP-Protocol-Version
• Mcp-Method
• Mcp-Name

Header ini memungkinkan gateway merutekan, mengukur, mengotorisasi, dan membatasi laju trafik tanpa mengurai setiap badan JSON.

Header dapat mendukung kontrol seperti:

• batas laju khusus alat;
• kebijakan terpisah untuk metode daftar dan eksekusi;
• kumpulan pekerja khusus untuk alat mahal;
• akses terbatas ke operasi berisiko tinggi;
• metrik latensi dan kesalahan per alat;
• atribusi biaya infrastruktur.

Nilai tetap disuplai oleh klien. Bandingkan dengan badan JSON-RPC sebelum menerapkan kebijakan.

Permintaan tidak boleh mengklaim alat berisiko rendah di Mcp-Name sambil memanggil alat berbeda di badan. Ketidaksesuaian header dan badan harus ditolak dan dicatat.

Gunakan Kunci Cache yang Sadar Otorisasi

Protokol baru menambahkan ttlMs dan cacheScope ke hasil yang dapat di-cache termasuk:

• tools/list
• prompts/list
• resources/list
• resources/templates/list
• resources/read

Kunci cache biasanya harus menyertakan:

protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version

Jangan menggunakan kembali entri cache privat lintas pengguna atau tenant hanya karena TTL belum kedaluwarsa.

Pengurutan alat yang deterministik juga penting. Katalog yang stabil menghindari miss cache yang tidak perlu dan dapat meningkatkan pemanfaatan prompt-cache model saat definisi alat dimasukkan ke dalam prompt.

Perkuat Penanganan Issuer OAuth

Selama migrasi otorisasi:

• validasi nilai iss yang dikembalikan terhadap issuer yang dicatat untuk alur;
• kunci kredensial klien yang disimpan berdasarkan issuer;
• jangan pernah menggunakan kembali kredensial dengan server otorisasi lain;
• tetapkan application_type yang sesuai selama DCR;
• siapkan integrasi baru untuk Client ID Metadata Documents.

Dynamic Client Registration tetap tersedia untuk kompatibilitas mundur, tetapi didepresiasi sebagai pendekatan pendaftaran yang disukai.

6. Migrasikan Notifikasi, Tasks, dan Fitur Didepresiasi

Jalur notifikasi HTTP GET lama dan alur resources/subscribe atau resources/unsubscribe telah diganti oleh subscriptions/listen.

Klien membuka stream respons POST berumur panjang dan memilih kategori notifikasi yang dibutuhkan. Progres dan log spesifik permintaan tetap terlampir pada stream respons untuk permintaan yang mereka jelaskan.

Untuk penerapan multi-instance, gunakan bus event bersama saat notifikasi yang dihasilkan pada satu instance server harus mencapai langganan yang terhubung ke instance lain.

Ekstensi Tasks

Pekerjaan jangka panjang telah dipindahkan dari protokol inti eksperimental ke:

io.modelcontextprotocol/tasks

Ekstensi menggunakan:

• tasks/get untuk polling;
• tasks/update untuk pembaruan dari klien ke server;
• handle tugas yang tahan lama;
• subscriptions/listen untuk pembaruan yang diopt-in.

Pola tasks/result dan tasks/list lama tidak boleh dibawa ke implementasi baru.

Fitur Didepresiasi

Fitur berikut didepresiasi:

Fungsionalitas yang didepresiasi tetap tersedia selama jendela deprecasi, tetapi implementasi baru tidak boleh mengadopsinya. Kebijakan siklus hidup MCP menyediakan periode deprecasi minimum dua belas bulan; ini tidak berarti setiap fitur memiliki tanggal penghapusan yang sama.

Tinjau registri fitur didepresiasi resmi sebelum menetapkan tenggat pensiun.

7. Luncurkan Migrasi dengan Aman

Jangan mengubah klien, server, gateway, caching, dan otorisasi dalam satu rilis tanpa observasi.

Urutan Migrasi yang Direkomendasikan

1. Inventaris versi protokol, SDK, sesi, trafik SSE, klien DCR, dan metode didepresiasi.
2. Tingkatkan SDK non-produksi.
3. Tambahkan server/discover dan negosiasi versi.
4. Ganti dependensi sesi tersembunyi.
5. Implementasikan dan amankan MRTR.
6. Tambahkan header perutean tervalidasi dan cache yang terukur.
7. Uji batas issuer otorisasi.
8. Lakukan canary protokol modern berdampingan dengan jalur legacy.
9. Pensiunkan perilaku lama hanya setelah meninjau telemetry.

Kompatibilitas Selama Canary

Modern client + modern server
→ Use MCP 2026-07-28

Modern client + legacy server
→ Probe and fall back when supported

Legacy client + dual-version server
→ Continue on the legacy path

Unsupported combination
→ Return a clear protocol-version error

Rilis spesifikasi MCP baru bukanlah saklar seluruh ekosistem. Klien, server, SDK, dan platform terhos akan bermigrasi dengan kecepatan berbeda.

Telemetry yang Dicatat

Keberhasilan permintaan tools/call sekali-jalan tidak cukup untuk mengukur migrasi. Alur kerja yang berulang kali timeout, meminta input yang tidak perlu, atau menggandakan penulisan eksternal tetap merupakan kegagalan produksi.

Bagaimana CometAPI Cocok dalam Arsitektur MCP

MCP tidak menggantikan API model. Dua lapisan ini menyelesaikan masalah integrasi yang berbeda.

Arsitektur produksi tipikal terlihat seperti ini:

Application or agent
        ↓
MCP clients and servers
Tools, resources, approvals, tasks
        ↓
Unified model API
GPT, Claude, Gemini, DeepSeek, and other models

MCP menstandarkan cara agen berinteraksi dengan alat dan konteks. MCP tidak menstandarkan penetapan harga model, kredensial penyedia, endpoint inferensi, atau failover penyedia.

Pemisahan ini menjadi sangat berguna saat bermigrasi dari kapabilitas Sampling yang didepresiasi. Jika server MCP atau agen yang mengkonsumsinya masih membutuhkan inferensi model, aplikasi dapat memanggil API model secara langsung alih-alih bergantung pada alur Sampling MCP sebelumnya.

Kapan Gateway Model Terpadu Membantu

Gateway model terpadu dapat mengurangi pekerjaan operasional saat:

• beberapa server MCP memerlukan akses ke penyedia model yang berbeda;
• alat berbeda membutuhkan model berbeda;
• tim ingin beralih model tanpa menulis ulang integrasi spesifik penyedia;
• kredensial, penggunaan, dan penagihan perlu dikelola secara terpusat;
• akses model harus tetap independen dari perubahan transport MCP.

CometAPI menyediakan endpoint kompatibel OpenAI yang dapat digunakan sebagai lapisan akses model di belakang aplikasi MCP. Ini menjaga logika penyedia model terpisah dari alat MCP, resource, dan orkestrasi tugas.

Misalnya, sebuah alat MCP dapat memanggil model melalui klien kompatibel OpenAI yang sama seperti yang digunakan di tempat lain dalam aplikasi:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.COMETAPI_KEY,
  baseURL: "https://api.cometapi.com/v1"
});

export async function summarizeResource(content: string) {
  const response = await client.chat.completions.create({
    model: "your-selected-model",
    messages: [
      {
        role: "system",
        content: "Summarize the supplied resource clearly and concisely."
      },
      {
        role: "user",
        content
      }
    ]
  });

  return response.choices[0]?.message?.content ?? "";
}

Server MCP tetap bertanggung jawab atas kontrak alat, otorisasi, state, dan penanganan hasil. Gateway model menangani pemilihan model, akses penyedia, dan respons inferensi.

Menjaga lapisan ini tetap terpisah memberikan dua manfaat praktis:

1. Klien dan server MCP dapat bermigrasi ke protokol baru tanpa mengubah lapisan integrasi model.
2. Penyedia model dapat diubah tanpa mendesain ulang alat MCP atau perilaku transport.

Untuk detail implementasi lebih lanjut, lihat CometAPI Quickstart, dokumentasi API, dan panduan aplikasi AI multi-model.

Daftar Periksa Migrasi MCP 2026-07-28

Klien

• Tingkatkan ke SDK yang kompatibel.
• Aktifkan negosiasi versi modern.
• Dukung server/discover.
• Sertakan metadata protokol pada setiap permintaan.
• Tangani resultType.
• Dukung atau secara eksplisit tolak MRTR.
• Gunakan ID JSON-RPC baru untuk percobaan ulang.
• Pertahankan dan kembalikan requestState.
• Validasi issuer OAuth.
• Simpan kredensial berdasarkan issuer.
• Hormati petunjuk cache.
• Dukung subscriptions/listen saat diperlukan.

Server

• Hapus gerbang inisialisasi permintaan modern.
• Hapus dependensi pada Mcp-Session-Id.
• Implementasikan server/discover.
• Ganti state tersembunyi dengan handle atau penyimpanan bersama.
• Kembalikan resultType.
• Ganti permintaan yang diinisiasi server dengan MRTR.
• Lindungi requestState.
• Validasi semua inputResponses.
• Tambahkan idempoten untuk efek samping.
• Kembalikan daftar deterministik.
• Publikasikan petunjuk cache yang konservatif.
• Migrasikan pekerjaan jangka panjang ke ekstensi Tasks.

Gateway dan Infrastruktur

• Validasi header permintaan MCP.
• Bandingkan header dengan badan permintaan.
• Hapus perutean lengket yang tidak perlu.
• Uji permintaan lintas beberapa instance.
• Partisi cache menurut batas otorisasi.
• Tambahkan bus notifikasi bersama bila diperlukan.
• Lacak trafik legacy dan didepresiasi.
• Pertahankan jalur rollback selama canary.

FAQ

Apa itu MCP 2026-07-28?

MCP 2026-07-28 adalah spesifikasi Model Context Protocol yang dirilis pada 28 Juli 2026. Spesifikasi ini memperkenalkan inti protokol tanpa status, Multi Round-Trip Requests, header perutean HTTP, hasil yang dapat di-cache, perubahan otorisasi, ekstensi, dan siklus hidup deprecasi yang formal.

Apakah Mcp-Session-Id dihapus?

Ya. Protokol Streamable HTTP baru tidak lagi menggunakan Mcp-Session-Id.

Aplikasi tetap dapat mempertahankan state melalui handle eksplisit, penyimpanan bersama, tugas yang tahan lama, atau nilai state permintaan yang terlindungi.

Apakah handshake inisialisasi MCP dihapus?

Ya. Permintaan modern tidak lagi membutuhkan pertukaran initialize dan notifications/initialized.

Server harus mengimplementasikan server/discover, meskipun klien tidak perlu memanggilnya sebelum setiap operasi.

Apakah MCP tanpa status berarti alat tidak dapat mempertahankan state?

Tidak. Tanpa status merujuk pada lapisan protokol.

Alat tetap dapat menyimpan state, tetapi pemrosesan permintaan tidak boleh bergantung pada afinitas transport yang tersembunyi atau satu proses server tertentu.

Apa itu MRTR?

Multi Round-Trip Requests memungkinkan server meminta input tambahan dari klien atau pengguna tanpa mengirim permintaan yang diinisiasi server melalui koneksi dua arah yang terus terbuka.

Server mengembalikan input_required, dan klien mencoba ulang operasi asli dengan respons yang diminta.

Apakah HTTP+SSE dihapus segera?

Tidak. Fitur tersebut didepresiasi alih-alih langsung dihapus.

Server baru harus menggunakan Streamable HTTP, sementara sistem yang ada harus mengukur dan memigrasikan trafik HTTP+SSE yang tersisa.

Apakah klien SDK TypeScript v2 secara otomatis menggunakan MCP 2026-07-28?

Tidak. SDK v2 TypeScript memerlukan konfigurasi negosiasi versi eksplisit untuk menggunakan protokol modern.

Gunakan negosiasi otomatis saat klien harus bekerja dengan server modern dan legacy.

Rekomendasi Akhir

MCP 2026-07-28 membuat infrastruktur MCP jarak jauh lebih mudah untuk diskalakan, dirutekan, di-cache, dan diamati. Risiko migrasi utama bukan sekadar penghapusan header atau handshake. Risiko utamanya adalah state aplikasi tersembunyi dan logika interaksi yang mungkin masih bergantung padanya.

Sebelum menerapkan protokol baru:

Temukan setiap dependensi pada inisialisasi dan Mcp-Session-Id.

1. Pindahkan state yang dibutuhkan ke handle eksplisit atau penyimpanan bersama.
2. Implementasikan MRTR dengan kedaluwarsa, perlindungan replay, dan idempoten.
3. Validasi header MCP terhadap badan JSON-RPC.
4. Partisi cache menurut tenant dan cakupan otorisasi.
5. Perkuat validasi issuer OAuth.
6. Ukur metode didepresiasi dan trafik transport legacy.
7. Lakukan canary jalur protokol modern dan legacy sebelum pensiun.

Perlakukan migrasi sebagai perubahan infrastruktur, bukan peningkatan SDK rutin.

Setelah lapisan MCP menjadi tanpa status dan dapat diamati, pertahankan akses model di balik antarmuka terpisah. Ini memungkinkan protokol alat dan lapisan penyedia model berkembang secara independen.