Roadmap MCP Bukan Rilis atau Janji Kompatibilitas
MCP bergerak dengan kecepatan berbeda di seluruh spesifikasi, ekstensi, SDK, dan transportasinya. Prioritas roadmap tidak membuat dua produk menjadi interoperabel.
Roadmap Model Context Protocol (MCP) menyebutkan lima area yang ingin dimajukan oleh para pemeliharanya, mulai dari pesan antar-agent dan perubahan transportasi hingga identitas workload serta konsistensi SDK. Roadmap itu tidak menjadikan kemampuan-kemampuan tersebut satu rilis.
Perbedaan itu bersifat operasional. Spesifikasi 2026-07-28 MCP sudah tersedia, tetapi beberapa item dalam roadmap 22 Agustus masih berupa desain yang diusulkan, ekstensi yang sedang dimatangkan, atau pekerjaan yang belum masuk ke protokol inti. Bahkan perilaku yang sudah dirilis dapat memerlukan pengaturan SDK secara eksplisit, alih-alih hadir ketika versi paket berubah.
Aturan deployment yang aman adalah: setujui kemampuan MCP hanya ketika status protokol, perilaku SDK yang persis, client dan server target, fallback, bukti konformansi, serta jalur rollback semuanya selaras. Letakkan perilaku yang sudah dirilis tetapi belum seragam di balik feature flag. Jangan masukkan maksud roadmap ke dalam dependensi produksi.
Satu fitur MCP dapat memiliki empat label kematangan yang berbeda
Roadmap resmi menyatakan bahwa isinya adalah pemikiran terkini para pemelihara untuk enam hingga dua belas bulan ke depan, bukan komitmen yang pasti. Prioritas dapat bergeser, desain dapat berubah, dan pekerjaan dapat ditunda. Lima areanya berguna karena menunjukkan tempat tinjauan spesifikasi dan upaya kelompok kerja akan dipusatkan. Namun, roadmap itu tidak memberi tahu operator bahwa client dan server tertentu dapat berinteroperasi hari ini.
Rilis spesifikasi 2026-07-28 adalah jenis artefak yang berbeda. Rilis itu mengganti handshake sesi dan inisialisasi tingkat protokol dengan request yang mendeskripsikan dirinya sendiri, memperkenalkan server/discover, menambahkan header routing HTTP standar dan petunjuk cache, memformalkan ekstensi, serta memperkuat otorisasi. Semua itu adalah keputusan protokol yang sudah dirilis.
SDK tetap dapat mengekspos default yang lebih sempit. Panduan migrasi TypeScript saat ini menyatakan bahwa client menggunakan handshake 2025 warisan kecuali negosiasi versi dipilih. mode: 'auto' melakukan probe dengan server/discover dan dapat melakukan fallback; pinning 2026-07-28 menolak server yang tidak menawarkan revisi tersebut. Jadi, memasang SDK modern tidak membuktikan bahwa koneksi yang ter-deploy menggunakan perilaku wire modern.
Keempat label harus tetap terpisah:
| Label | Apa yang ditetapkannya | Apa yang tidak ditetapkannya |
|---|---|---|
| Prioritas roadmap | Pemelihara berniat mengalokasikan upaya tinjauan dan desain di sini | Desain final, tanggal rilis, atau implementasi interoperabel |
| Status spesifikasi atau ekstensi | Proyek telah menetapkan kontrak berversi pada tahap siklus hidup yang dinyatakan | Dukungan dalam bahasa, versi, host, gateway, dan peer yang di-deploy tim |
| Dukungan SDK | Satu lini library mengekspos sebagian implementasi kontrak | Konfigurasi defaultnya, perilaku SDK lain, atau kompatibilitas end-to-end |
| Bukti deployment | Pasangan client-server yang dipatok melewati fixture dan tes rollback tim | Kompatibilitas setelah endpoint, ekstensi, gateway, atau policy mana pun berubah |
Badge paket meratakan label-label tersebut. Catatan deployment harus mempertahankan perbedaannya.
Fitur MCP yang sudah dirilis dan yang direncanakan berada pada tahap berbeda
Matriks berikut menerjemahkan roadmap saat ini dan spesifikasi yang sudah dirilis menjadi keputusan default yang konservatif. “Rilis” tidak berarti aman secara universal. Artinya, perilaku dasarnya sudah dirilis dan dapat masuk ke produksi setelah gerbang implementasi dan interoperabilitas yang disebutkan lolos.
| Kemampuan dan bukti saat ini | Hal yang didukung oleh bukti |
|---|---|
2026-07-28 core stateless, request yang mendeskripsikan diri sendiri, dan server/discover. Dirilis dalam spesifikasi core bertanggal; didukung oleh lini SDK resmi saat ini, dengan perilaku migrasi yang spesifik untuk tiap bahasa. | Rilis, untuk pasangan yang dipatok. Catat versi SDK client dan server, aktifkan mode protokol yang dimaksud, verifikasi discovery atau error versi langsung, uji header routing, dan pertahankan fallback warisan atau kebijakan penolakan yang disengaja. |
Negosiasi dua era selama migrasi. Diimplementasikan pada client TypeScript v2 melalui mode legacy, auto, atau pin modern yang eksplisit; SDK lain memerlukan bukti masing-masing. | Gunakan feature flag. Uji modern-ke-modern, modern-ke-warisan, kegagalan otorisasi, timeout, dan jalur rollback; catat revisi yang dinegosiasikan alih-alih menyimpulkannya dari versi paket. |
| Ekstensi Tasks. Ekstensi yang sudah dirilis; roadmap menyatakan para pemelihara ingin mematangkannya agar akhirnya masuk ke core. | Gunakan feature flag. Pin versi ekstensi, verifikasi kedua peer mendeklarasikan dan mengimplementasikannya, uji semantik polling dan pembatalan, lalu tolak penggunaan ketika negosiasi kapabilitas gagal. |
| Enterprise-Managed Authorization. Ekstensi stabil yang dikutip proyek, tetapi bukan lapisan identitas universal untuk setiap deployment MCP. | Gunakan feature flag. Verifikasi server otorisasi, client, server, grant, audience token, batas delegasi, dan perilaku pencabutan sebagai satu jalur yang diuji. |
| Event yang diinisiasi server melalui webhook atau channel. Deliverable roadmap yang ditujukan untuk mengurangi polling; komposisi finalnya dengan Tasks dan pekerjaan event lain masih dikembangkan. | Pantau. Tunggu kontrak berversi dan dukungan SDK target, lalu uji pengiriman, autentikasi, replay, pengurutan, pembatalan, retry, dan fallback. |
| Unifikasi transportasi HTTP over stdio. Arah roadmap untuk membawa semantik Streamable HTTP melalui I/O proses lokal. | Pantau. Minta spesifikasi atau ekstensi yang telah diterima, dukungan yang sudah dirilis pada kedua endpoint, tes framing dan shutdown, serta fallback ke transportasi yang saat ini didukung. |
| Adopsi DPoP, identitas workload, dan delegasi agent. Pekerjaan roadmap yang memanfaatkan standar identitas yang sudah ada; jalur khusus MCP belum menjadi satu fitur turnkey yang sudah dirilis. | Pantau. Minta kontrak MCP berversi ditambah tes issuer, audience, proof key, pertukaran token, delegasi, kedaluwarsa, pencabutan, dan lintas-tenant. |
| Hasil tool yang didesain ulang dan progressive discovery. Pekerjaan roadmap yang dimaksudkan untuk memperjelas fidelity hasil dan menghindari pemuatan katalog tool besar di awal. | Pantau. Tunggu skema stabil dan implementasi SDK; uji fidelity yang terlihat oleh model, perilaku cache, kelengkapan discovery, penyaringan otorisasi, dan fallback katalog penuh. |
| Artefak SDK yang dihasilkan dan otomatisasi konformansi yang lebih luas. Eksperimen roadmap untuk menguji lapisan SDK dan quickstart mana yang dapat dihasilkan dan divalidasi ulang. | Pantau. Perlakukan hasil konformansi yang dipublikasikan hanya sebagai bukti untuk suite, revisi, commit SDK, dan peran yang diuji secara persis; jangan men-deploy output yang dihasilkan hanya karena berasal dari eksperimen tersebut. |
Matriks ini sengaja asimetris. Ekstensi yang sudah dirilis dapat memperoleh status feature flag sebelum menjadi bagian dari core. Fitur roadmap tidak dapat memperoleh status “rilis” hanya karena vendor mengekspos sesuatu dengan nama yang mirip. Perilaku khusus produk mungkin berguna, tetapi harus dicatat sebagai ekstensi vendor tersebut, bukan sebagai dukungan MCP secara luas.
Perilaku yang sudah dirilis tetap dapat berbeda saat runtime
Satu koneksi konkret mencakup client, server, dua implementasi SDK, transportasi, jalur otorisasi, revisi protokol, dan ekstensi apa pun. “Kompatibel dengan MCP” memadatkan semua bagian yang bergerak itu menjadi satu label.
Revisi yang dinegosiasikan dapat berbeda dari revisi yang disarankan oleh versi dependensi. Peer yang lebih lama dapat memicu fallback atau penolakan yang disengaja, aturan gateway dapat mengubah perilaku wire, dan ekstensi yang diiklankan dapat tidak ada atau hanya diimplementasikan sebagian. Panduan migrasi dari Arcade yang independen mengharapkan periode dual-stack untuk layanan publik, tepat karena client tidak diperbarui secara bersamaan.
TypeScript membuat perbedaan antara paket dan runtime terlihat sangat jelas. Panduan v2-nya mendokumentasikan tiga kebijakan koneksi: warisan secara default, discovery otomatis dengan fallback, dan pin khusus modern. Tim platform dapat memilih negosiasi otomatis secara wajar untuk layanan publik dan pin khusus modern di dalam fleet yang terkontrol. Itu adalah keputusan risiko yang berbeda meskipun kedua deployment menggunakan rilis SDK yang sama.
Setiap lapisan yang bergerak dapat membatalkan kompatibilitas
Kompatibilitas berakhir ketika protokol, ekstensi, SDK client, SDK server, produk host, gateway, profil otorisasi, feature flag, atau suite konformansi berubah secara material. Kompatibilitas juga dapat berakhir ketika proposal roadmap menjadi ekstensi yang dirilis: itu alasan untuk membuka tinjauan baru, bukan untuk otomatis menaikkan item lama yang masih dipantau.
Beri tanggal pada setiap baris dan simpan URL sumber di sebelahnya. Changelog spesifikasi adalah baseline untuk perilaku core yang sudah dirilis; roadmap menjelaskan arah yang dituju; dokumentasi SDK menjelaskan bagaimana satu implementasi mengekspos kontrak. Masing-masing menjawab pertanyaan yang berbeda.
Jadi, pelajaran produksi paling berharga dari roadmap bukanlah fitur tertentu. Pelajaran itu adalah peringatan bahwa MCP bergerak pada beberapa lapisan sekaligus. Tim yang mencatat lapisan-lapisan tersebut secara terpisah dapat mengadopsi perbaikan yang sudah dirilis tanpa mengira momentum proyek sebagai interoperabilitas.