MCP Ternyata Punya 5 Versi: Bedanya dari 2024-11-05 sampai 2026-07-28

Banyak orang membahas Model Context Protocol seolah MCP adalah satu standar tetap: pasang server, sambungkan client, lalu semua langsung kompatibel.

Masalahnya, MCP sudah melewati lima revisi spesifikasi yang dipublikasikan. Per 11 Agustus 2026, versi protokol yang tercatat di schema resmi adalah 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25, dan 2026-07-28.

Perubahannya juga bukan sekadar penambahan fitur kecil. Transport HTTP pernah diganti. JSON-RPC batching sempat ditambahkan lalu dihapus. Mekanisme initialize yang sejak awal menjadi pintu masuk koneksi akhirnya dihapus pada versi terbaru. Session ID juga hilang. MCP modern sekarang bergerak ke model stateless dengan metadata versi dan capability pada setiap request.

Jadi ketika dua aplikasi sama-sama mengklaim "support MCP", itu belum otomatis berarti keduanya berbicara dengan cara yang sama.

Jawaban singkat: MCP menggunakan versi berbentuk tanggal YYYY-MM-DD. Hingga 11 Agustus 2026 ada lima revisi protokol yang dipublikasikan. Empat versi sampai 2025-11-25 masuk era legacy berbasis handshake initialize. Versi 2026-07-28 memulai era modern yang stateless, tanpa protocol-level session, dan membawa informasi versi serta capability pada setiap request.

Kenapa versi MCP memakai tanggal?

MCP tidak memakai label v1, v2, atau v3 untuk versi protokolnya. Identitas versi memakai string tanggal, misalnya 2026-07-28.

Menurut panduan versioning resmi MCP, tanggal tersebut menunjukkan kapan perubahan terakhir yang tidak backward-compatible dibuat. Nomor versi tidak dinaikkan untuk perubahan yang tetap kompatibel ke belakang.

Artinya, satu revisi bisa terus menerima koreksi dan penyempurnaan yang kompatibel tanpa mendapat nomor tanggal baru.

Dokumen MCP juga membedakan status revisi:

• Draft: masih dalam proses dan belum siap dijadikan target produksi;
• Current: revisi aktif yang siap dipakai dan masih dapat menerima perubahan kompatibel;
• Final: revisi lama yang sudah selesai dan tidak lagi diubah.

Per 11 Agustus 2026, revisi current adalah 2026-07-28.

Jangan campur tiga jenis versi yang berbeda

Sebagian besar kebingungan bermula karena kata "versi MCP" bisa merujuk ke tiga hal.

1. Versi protokol

Contoh: 2025-11-25 atau 2026-07-28.

Ini menentukan bentuk message, lifecycle, capability, transport behavior, error, dan aturan kompatibilitas antara client dengan server.

2. Versi SDK

Contoh: versi package TypeScript, Python, Go, atau Java SDK.

SDK punya siklus rilis sendiri. Nomor package SDK bukan protocol version. Meng-upgrade package juga tidak selalu berarti aplikasi langsung memakai revisi protokol terbaru. Implementasi tetap perlu mengecek revision support dan perubahan API di SDK tersebut.

Dokumentasi resmi bahkan mengelompokkan SDK ke tier berdasarkan kelengkapan fitur, protocol support, dan komitmen maintenance. Jadi bahasa pemrograman yang berbeda dapat mencapai dukungan revisi baru pada waktu yang berbeda.

3. Versi MCP server

Sebuah server yang dipublikasikan ke MCP Registry juga punya versi software sendiri, biasanya semantic version seperti 1.2.3.

Dokumentasi versioning MCP Registry merekomendasikan agar versi server selaras dengan versi package atau remote API. Nomor ini menjelaskan release produk server, bukan otomatis menjelaskan revisi protokol yang dipakai.

Ringkasnya:

Protocol version : 2026-07-28
SDK version : versi package bahasa pemrograman
Server version : versi aplikasi/integrasi, misalnya 1.4.0

Ketiganya perlu dicatat terpisah saat debugging.

Lima versi MCP dan perubahan pentingnya

Repositori schema resmi MCP mencatat lima direktori revisi yang sudah dipublikasikan. Berikut perbedaan operasional yang paling penting.

MCP 2024-11-05: fondasi awal

Revisi 2024-11-05 membentuk model MCP yang banyak orang kenal pertama kali:

• message memakai JSON-RPC 2.0;
• client dan server bernegosiasi lewat lifecycle initialize;
• server dapat mengekspos tools, resources, dan prompts;
• client dapat menawarkan sampling;
• transport standar terdiri dari stdio dan HTTP dengan SSE.

Pada transport HTTP+SSE lama, server menyediakan dua endpoint: satu endpoint SSE untuk koneksi masuk dari server ke client, lalu satu endpoint HTTP POST untuk message dari client. Server mengirim event endpoint agar client tahu ke URL mana message berikutnya harus dikirim.

Model ini bekerja, tetapi arsitektur HTTP-nya lebih rumit dan stateful.

MCP 2025-03-26: Streamable HTTP dan OAuth 2.1

Revisi 2025-03-26 membawa perubahan besar pertama:

• authorization framework berbasis OAuth 2.1;
• HTTP+SSE diganti oleh Streamable HTTP;
• JSON-RPC batching ditambahkan;
• tool annotations diperkenalkan;
• audio masuk sebagai content type;
• capability untuk completions ditambahkan.

Streamable HTTP memakai satu MCP endpoint. Message dikirim lewat HTTP POST, sedangkan response dapat berupa JSON biasa atau SSE stream. Ini menyederhanakan bentuk remote server dibanding pola dua endpoint pada HTTP+SSE.

Namun ada jebakan penting: server atau client yang masih mengharapkan pola HTTP+SSE lama tidak otomatis cocok hanya karena sama-sama menggunakan HTTP.

MCP 2025-06-18: structured output, elicitation, dan security lebih ketat

Revisi 2025-06-18 kembali mengubah beberapa asumsi:

• JSON-RPC batching yang baru hadir pada Maret justru dihapus;
• tool result mendapat structured output;
• elicitation ditambahkan agar server dapat meminta informasi tambahan dari user;
• resource links ditambahkan ke hasil tool;
• MCP server diklasifikasikan sebagai OAuth Resource Server;
• client diwajibkan memakai Resource Indicators dari RFC 8707;
• request HTTP setelah negosiasi wajib membawa header MCP-Protocol-Version.

Ini contoh paling jelas kenapa "fitur pernah ada di MCP" belum cukup sebagai dasar implementasi. Batching resmi hanya hidup pada satu revisi sebelum dikeluarkan lagi.

MCP 2025-11-25: tasks, tool calling saat sampling, dan schema lebih matang

Revisi 2025-11-25 memperluas kemampuan agentic:

• experimental tasks untuk pekerjaan durable dan deferred result;
• tool calling di dalam sampling;
• URL mode elicitation;
• metadata icon untuk tools, resources, prompts, dan implementation;
• incremental scope consent lewat WWW-Authenticate;
• OpenID Connect Discovery;
• JSON Schema 2020-12 menjadi dialect default.

Meski fiturnya makin kaya, lifecycle versi ini masih legacy. Client tetap memulai dengan initialize, server menjawab versi serta capabilities, lalu client mengirim notifications/initialized. Pada Streamable HTTP, server juga masih bisa membuat MCP-Session-Id untuk menjaga state antar-request.

MCP 2026-07-28: lahirnya era modern

Revisi 2026-07-28 bukan update kecil. Ini memisahkan MCP menjadi dua era arsitektur.

Perubahan utamanya:

• protocol-level session dan header Mcp-Session-Id dihapus;
• handshake initialize serta notifications/initialized dihapus;
• setiap request membawa protocol version dan client capabilities di _meta;
• server/discover menjadi RPC wajib pada server;
• server tidak lagi memulai JSON-RPC request ke client;
• pola server-initiated request diganti dengan Multi Round-Trip Requests atau MRTR;
• HTTP GET stream lama diganti dengan subscriptions/listen berbasis POST response stream;
• SSE resumability dengan Last-Event-ID dihapus;
• tasks dipindahkan dari core protocol menjadi extension resmi;
• result biasa sekarang membawa resultType: "complete";
• beberapa fitur lama masuk status deprecated, termasuk Roots, Sampling, Logging, Dynamic Client Registration, dan HTTP+SSE.

MCP modern bersifat stateless pada level protokol. Kalau server perlu menyimpan state lintas-call, state tersebut harus direpresentasikan sebagai handle eksplisit yang dikirim sebagai argumen tool biasa, bukan disembunyikan di dalam session koneksi.

Perbedaan era legacy dan modern

Dokumentasi versi terbaru memakai tiga istilah:

• Legacy: revisi 2025-11-25 dan sebelumnya, berbasis initialize;
• Modern: revisi 2026-07-28 dan setelahnya, berbasis metadata per request;
• Dual-era: client atau server yang mendukung keduanya.

Perbedaan praktisnya cukup jauh.

Area	Legacy sampai 2025-11-25	Modern mulai 2026-07-28
Awal koneksi	initialize lalu notifications/initialized	Tidak ada handshake
Negosiasi versi	Dilakukan saat initialization	Versi dibawa pada setiap request
Capability	Dinegosiasikan untuk session	Dikirim sebagai metadata per request
Session HTTP	Dapat memakai MCP-Session-Id	Protocol-level session dihapus
Discovery	Informasi server datang dari initialize	server/discover wajib tersedia
Request dari server	Server dapat mengirim request ke client	Diganti pola MRTR dan retry request
Subscription	Session flag, GET SSE, atau resource subscribe	subscriptions/listen
Task	Fitur experimental di core	Extension io.modelcontextprotocol/tasks
State lintas-call	Dapat bergantung pada session	Gunakan handle eksplisit

Karena perbedaannya sedalam ini, tanggal versi harus diperlakukan sebagai bagian dari kontrak integrasi, bukan metadata dekoratif.

Bagaimana client dan server menyepakati versi?

Pada revisi legacy

Client mengirim revisi terbaru yang ia dukung di request initialize. Kalau server mendukungnya, server menjawab dengan versi yang sama. Kalau tidak, server menjawab versi lain yang ia dukung, idealnya versi terbaru di sisi server.

Jika client tidak mendukung versi jawaban server, client seharusnya memutus koneksi.

Pada revisi modern

Tidak ada negotiation handshake. Setiap request mendeklarasikan protocol version melalui _meta. Pada Streamable HTTP, nilai yang sama juga dikirim pada header MCP-Protocol-Version.

Jika versi tidak didukung, server mengembalikan UnsupportedProtocolVersionError beserta daftar versi yang didukung. Client dapat memilih versi yang cocok lalu mengulang request.

Client juga boleh memanggil server/discover lebih dulu untuk mengambil:

• daftar protocol version yang didukung;
• capabilities server;
• extension yang tersedia;
• identitas server;
• instruksi pemakaian.

Ini membuat diagnosis lebih eksplisit. Daripada menebak kemampuan server dari nama package, client dapat membaca kontraknya langsung.

Transport MCP juga punya generasi berbeda

Istilah versi MCP sering tercampur dengan transport. Padahal transport dan protocol revision adalah dua dimensi berbeda.

stdio

stdio bertahan dari revisi awal sampai versi terbaru. Client menjalankan server sebagai subprocess, mengirim JSON-RPC lewat stdin, menerima response lewat stdout, dan membiarkan log berjalan melalui stderr.

Meski nama transportnya tetap sama, cara mendeteksi era berubah. Client dual-era dapat mengirim server/discover sebagai probe. Jika hasilnya bukan response modern yang dikenali, client dapat fallback ke initialize.

HTTP+SSE

Ini transport remote pada revisi awal 2024-11-05. Ia memakai dua endpoint dan sekarang deprecated. Implementasi baru sebaiknya tidak mengadopsinya.

Streamable HTTP legacy

Mulai 2025-03-26, remote MCP beralih ke satu MCP endpoint. Sampai 2025-11-25, transport ini masih dapat memakai initialization, session ID, HTTP GET SSE stream, dan resumption lewat Last-Event-ID.

Streamable HTTP modern

Pada 2026-07-28, namanya tetap Streamable HTTP tetapi behavior-nya berubah:

• setiap message dikirim sebagai POST;
• response bisa JSON atau request-scoped SSE;
• tidak ada protocol-level session ID;
• tidak ada GET endpoint untuk general server-to-client message;
• stream yang putus tidak dilanjutkan dengan Last-Event-ID;
• subscription perubahan memakai subscriptions/listen.

Jadi label streamable-http saja belum cukup untuk membuktikan kompatibilitas. Implementasi perlu tahu apakah endpoint berbicara dalam era legacy atau modern.

Kenapa integrasi bisa gagal walau sama-sama bilang support MCP?

Ada beberapa pola kegagalan yang masuk akal.

Client legacy bertemu server modern

Client mengirim initialize, tetapi server modern tidak lagi mengenal lifecycle itu. Pada HTTP, request juga bisa ditolak karena metadata atau header modern tidak ada. Client legacy tidak punya mekanisme otomatis untuk melompat ke era baru.

Client modern bertemu server legacy

Client mengirim metadata per request atau server/discover, tetapi server lama tidak mengenali method dan semantics tersebut. Client modern murni dapat gagal kecuali ia punya fallback legacy.

Versi cocok, capability tidak cocok

Kedua pihak bisa memahami revisi yang sama tetapi berbeda capability. Contohnya, server punya tools tetapi client tidak mendukung extension tasks. Protocol version bukan jaminan semua fitur aktif.

Transport benar, semantics salah

Sama-sama memakai HTTP POST bukan berarti cocok. Server mungkin masih menunggu initialization dan session ID, sementara client menganggap setiap request stateless.

SDK terbaru, implementasi masih lama

Package SDK dapat diperbarui tetapi kode aplikasi tetap mengaktifkan compatibility mode lama, memakai adapter lama, atau belum memigrasikan lifecycle. Nomor package tidak boleh dijadikan satu-satunya bukti.

Checklist migrasi MCP yang aman

Kalau sedang membangun atau meng-upgrade MCP client maupun server, gunakan urutan berikut.

1. Catat protocol revision secara eksplisit. Jangan hanya menulis "MCP supported".
2. Pisahkan protocol version, SDK version, dan server version di log serta dokumentasi.
3. Tentukan target era. Legacy, modern, atau dual-era.
4. Untuk implementasi remote baru, gunakan Streamable HTTP. Jangan memulai proyek baru dengan HTTP+SSE.
5. Jangan mengandalkan JSON-RPC batching. Dukungan itu dihapus sejak 2025-06-18.
6. Jika target modern, hapus asumsi tentang initialize dan MCP-Session-Id. Pindahkan state ke handle eksplisit.
7. Kirim protocol version dan capabilities pada setiap request modern. Untuk HTTP, sinkronkan juga header versi.
8. Implementasikan server/discover pada server modern. Client dual-era dapat memakainya sebagai probe.
9. Migrasikan server-initiated request ke MRTR. Jangan memaksakan pola lama pada revisi modern.
10. Perlakukan tasks sebagai extension pada era modern. Negosiasikan io.modelcontextprotocol/tasks.
11. Audit daftar deprecated. Roots, Sampling, Logging, HTTP+SSE, dan beberapa mekanisme auth punya jalur pengganti.
12. Tes matriks, bukan satu happy path. Uji modern-modern, legacy-legacy, serta fallback dual-era.

Untuk debugging, MCP Inspector versi terbaru sudah menyediakan pilihan protocol era legacy, auto, dan modern. Mode ini berguna untuk memastikan kegagalan berasal dari revision mismatch, capability, transport, atau implementasi tool.

Pendekatan tersebut sejalan dengan prinsip di artikel Lima Lapisan Engineering AI Agent: integrasi agent yang sehat tidak cukup dinilai dari prompt atau demo satu kali. Contract, harness, state, loop, dan jalur error harus diuji sebagai sistem.

Versi mana yang sebaiknya dipakai?

Untuk implementasi baru, revisi current 2026-07-28 adalah target teknis yang paling masuk akal karena membawa model stateless, discovery yang eksplisit, dan kontrak per-request yang lebih mudah dipahami oleh proxy serta infrastructure modern.

Namun keputusan produksi tidak boleh berhenti di kalimat "pakai yang terbaru".

Kalau produk harus terhubung ke client atau server lama, dukungan dual-era bisa lebih realistis selama masa transisi. Client perlu probe lalu fallback dengan batas timeout yang jelas. Server dapat melayani semantics modern ketika request membawa metadata modern dan melayani initialization legacy pada jalur kompatibilitas yang terpisah.

Yang perlu dihindari adalah compatibility semu: menerima koneksi tetapi diam-diam menjalankan behavior era berbeda. Lebih baik gagal dengan error versi yang jelas daripada berhasil setengah jalan lalu kehilangan state, notification, atau hasil task.

FAQ tentang versi MCP

Apakah MCP sudah punya versi 1.0?

Versi protokol MCP tidak memakai skema 1.0, 2.0, dan seterusnya. Format resminya berbasis tanggal YYYY-MM-DD.

Berapa versi MCP yang sudah dipublikasikan?

Hingga 11 Agustus 2026, schema resmi memuat lima revisi: 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25, dan 2026-07-28.

Apakah server MCP lama masih bisa dipakai?

Bisa, selama client mendukung revisi dan transport yang dipakai server tersebut. Untuk menjangkau ekosistem lama serta baru, dibutuhkan implementasi dual-era atau adapter yang memang mengerti kedua lifecycle.

Apakah HTTP+SSE sama dengan Streamable HTTP?

Tidak. HTTP+SSE adalah transport lama dengan pola dua endpoint. Streamable HTTP menggantikannya mulai revisi 2025-03-26 dan memakai satu MCP endpoint. HTTP+SSE sekarang deprecated.

Apakah Streamable HTTP 2025 sama dengan Streamable HTTP 2026?

Namanya sama, tetapi semantics pentingnya berbeda. Era legacy masih memakai initialization, dapat memakai session ID, dan mendukung GET SSE serta resumption. Era modern 2026-07-28 menghapus session protokol, initialization, GET stream umum, serta Last-Event-ID resumption.

Apakah upgrade SDK otomatis meng-upgrade protocol version?

Belum tentu. SDK version dan protocol version adalah dua hal berbeda. Periksa dukungan revision SDK, configuration yang aktif, serta traffic aktual saat connection atau request.

Kesimpulan operasional

Hal yang jarang dibahas bukan cuma bahwa MCP punya beberapa versi. Yang lebih penting: versi-versi tersebut sudah membentuk dua era protokol dengan lifecycle yang berbeda.

Empat revisi pertama memakai initialization dan connection-scoped negotiation. Revisi 2026-07-28 memindahkan versi serta capability ke setiap request, menghapus session protokol, menambahkan server/discover, dan mengganti beberapa pola komunikasi lama.

Kalau sedang menilai sebuah MCP integration, jangan tanya satu pertanyaan saja: "support MCP atau tidak?"

Tanyakan ini:

• protocol revision mana yang didukung;
• transport apa yang dipakai;
• legacy, modern, atau dual-era;
• capability dan extension apa yang benar-benar dinegosiasikan;
• bagaimana fallback serta error version mismatch ditangani.

Itu yang menentukan kompatibel atau tidak. Label MCP saja belum cukup.

Sumber resmi

• MCP Versioning
• Schema resmi Model Context Protocol
• Changelog 2025-03-26
• Changelog 2025-06-18
• Changelog 2025-11-25
• Changelog 2026-07-28
• Versioning and Compatibility 2026-07-28
• Transport MCP 2026-07-28
• Deprecated Features Registry
• MCP Inspector: Protocol Eras