Roadmap Baru MCP: Apa Artinya bagi Mereka yang Membangun di Atasnya

Pada 22 Agustus, maintainer Model Context Protocol menerbitkan roadmap yang diperbarui untuk enam hingga dua belas bulan kerja protokol berikutnya. Roadmap itu menyebut lima area prioritas, Core Maintainers yang bertanggung jawab untuk masing-masing, serta satu aturan tenang tetapi penting mengenai proposal mana yang direview lebih dulu. Roadmap sebelumnya, dari Maret, menjanjikan empat hal dan sebagian besar dikirim dalam release spesifikasi Juli, jadi roadmap ini pantas dianggap serius. Bacaan saya: MCP sengaja sedang menjadi infrastruktur web biasa, dan pertanyaan berguna bagi builder adalah bagian stack mana yang berubah lebih dulu.

Poin utama - Roadmap menetapkan lima prioritas: agentic messaging, satu transport HTTP-native, agent identity dan enterprise security, primitive tool yang lebih bersih, dan SDK yang dihasilkan dari spesifikasi. - Spec Enhancement Proposal, SEP, di dalam area tersebut mendapat review dipercepat. Di luar area itu, harapkan antrean lebih panjang dan standar lebih tinggi. - Janji roadmap Maret sebagian besar mendarat di spec 2026-07-28: core stateless, hasil list yang cacheable, dan Multi Round-Trip Requests. - Dua perubahan yang paling mungkin menyentuh code Anda adalah agent identity, DPoP dan Workload Identity Federation, serta progressive tool discovery untuk katalog besar. - Anggap roadmap sebagai arah, bukan commitment. Maintainer sendiri mengatakannya. Jangan pause build untuk menunggu.

Apa yang sebenarnya diumumkan maintainer MCP?

Fakta lebih dulu. Roadmap MCP yang diperbarui, tertanggal 22 Agustus 2026, mengatur spec cycle berikutnya di sekitar lima area prioritas, masing-masing dengan Core Maintainers bernama dan satu atau lebih Working Group di belakangnya:

1. Agentic messaging primitives: event yang dimulai server, channels, subscriptions, dan webhooks, agar client berhenti polling, ditambah composition review agar Tasks, triggers, dan progress notifications berbagi satu lifecycle.

2. HTTP-native transport unification and hardening: Streamable HTTP sebagai satu binding, kelak dipakai juga lewat stdio untuk server lokal, dengan caching diperluas ke ETags.

3. Agent identity and enterprise-ready security: menyelesaikan DPoP, Demonstrating Proof of Possession, dan mendefinisikan jalur opinionated untuk agent identity dan delegation di atas standar IETF yang ada.

4. Improved primitives: redesign shape hasil tools/call, dan effort progressive discovery agar client mempelajari katalog server sesuai kebutuhan.

5. Improved SDK developer experience: extension contract dan eksperimen untuk menghasilkan Tier 1 SDK serta quickstart langsung dari spesifikasi.

Di samping lima area ada aturan yang akan membentuk semua hal lain: SEP di dalam area prioritas mendapat review dipercepat, dan proposal dengan Working Group di belakangnya bergerak paling cepat. Dalam kata maintainer sendiri, "maintainer review time is scarce. We spend it here first." Roadmap juga menyatakan jelas bahwa ia mencerminkan pemikiran saat ini, bukan commitment pasti, jadi item bisa bergeser atau hadir dalam bentuk berbeda.

Roadmap MCP yang diterbitkan 22 Agustus 2026 menetapkan lima area prioritas untuk enam hingga dua belas bulan berikutnya: agentic messaging, transport HTTP-native, agent identity, primitive tool yang lebih baik, dan SDK yang dihasilkan dari spec. Proposal dalam area ini mendapat review dipercepat; proposal di luar menghadapi antrean lebih panjang.

Mengapa roadmap ini penting?

Karena yang sebelumnya menghasilkan. Roadmap proyek open-source muda sering berupa dokumen aspiratif yang diam-diam menua. Yang ini punya track record. Roadmap Maret 2026 menetapkan empat prioritas dan sebagian besar dikirim lima bulan kemudian dalam release spesifikasi 2026-07-28:

Adoption memberi bobot. Pada Juli 2026, SDK Tier 1 protokol melihat hampir setengah miliar download per bulan, dengan SDK TypeScript dan Python masing-masing melewati satu miliar total download. Saat protokol pada skala itu mengatakan ke mana arahnya, layak membaca peta.

Sumber: roadmap MCP Maret dan Agustus 2026 serta pengumuman spesifikasi 2026-07-28.

Roadmap MCP Maret 2026 menjanjikan transport evolution, agent communication, governance maturation, dan enterprise readiness. Lima bulan kemudian, spesifikasi 2026-07-28 mengirim core protokol stateless, extension Tasks, Multi Round-Trip Requests, dan deprecation policy formal dengan minimum dua belas bulan.

Apa artinya jika Anda membangun di atas MCP?

Bagi builder, dampak langsung tidak merata. Dua dari lima area kemungkinan mengubah code Anda dalam satu tahun. Tiga lainnya lebih mengubah cara protokol digovern dan dimaintain di sekitar Anda. Berikut terjemahan setiap area.

Agentic messaging: akhir dari polling

Kerja agent nyata tidak cocok dengan request dan response. Job berjalan beberapa menit, server selesai saat client tidak melihat, dan saat ini jawaban client biasanya polling, mahal dan jelek. Roadmap memprioritaskan event yang dimulai server: channels, subscriptions, webhooks, sehingga server dapat memberi tahu client ketika kerja selesai. Composition review sama pentingnya. Tasks, subscriptions/listen, dan progress notifications berisiko menjadi tiga jawaban berbeda untuk "server belum selesai", dan maintainer ingin lifecycle, cancellation model, serta error surface yang sama. Jika Anda membangun tool long-running, ini area yang perlu diikuti di Discord.

Satu transport, dipakai di mana saja

Release 2026-07-28 membuat server MCP remote menjadi workload HTTP biasa. Roadmap kini ingin menghapus pemisahan remote/local: Streamable HTTP sebagai satu binding, digunakan melalui stdin dan stdout untuk server lokal, dengan HTTP/2 memberi multiplexing sementara subprocess mempertahankan guarantee security dan lifecycle. Saat ini setiap feature HTTP-native butuh design kedua khusus stdio atau tidak bekerja lokal, dan SDK memelihara dua transport pipeline. Satu model transport berarti lebih sedikit pekerjaan ganda. Caching juga diperluas: ETags di atas hint ttlMs dan cacheScope yang datang Juli, sehingga hasil tool call bisa diberi versi, bukan diambil ulang.

Agent identity: yang paling cepat terasa

Authorization MCP mengasumsikan manusia dengan browser saat consent. Semakin sering caller adalah agent: cloud workload dengan identity sendiri, bertindak untuk user yang tidak hadir, atau melahirkan sub-agent yang seharusnya punya authority lebih sempit daripada parent. Honeycomb, dikutip dalam pengumuman release Juli, sudah mengaitkan hampir 20% query interaktif bulanan dengan agents. Sementara itu banyak server MCP production masih mengandalkan API key yang ditempel dan refresh token long-lived, persis praktik yang ingin dihentikan effort ini. Rencananya DPoP diselesaikan dan diadopsi, plus jalur delegation standar melalui Workload Identity Federation, SEP-1933, grant ID-JAG di balik Enterprise-Managed Authorization, dan RFC 8693 token exchange, berkoordinasi dengan Working Group OAuth dan WIMSE IETF.

Model authorization MCP dibuat untuk manusia yang menyetujui access di browser, tetapi agents menjadi caller. Roadmap memprioritaskan DPoP dan jalur delegation standar berbasis Workload Identity Federation dan RFC 8693 token exchange, agar server mengenali agent identity tanpa API key ditempel atau token long-lived.

Hasil tool dan progressive discovery

Dua kebingungan diperbaiki. Pertama, tools/call mengembalikan content dan structuredContent sekaligus, menghasilkan implementasi berbeda karena server author tidak tahu bentuk mana yang akan ditampilkan client ke model. Contract itu akan didesain ulang. Kedua, scale: connect ke server dengan seratus tool dan model membayar seluruh surface sebelum user bertanya, dan tool selection memburuk saat list tumbuh. Token bill bukan teori. Dalam test Cloudflare Februari 2026, mengekspos API 2.500 endpoint sebagai definisi MCP tool mengonsumsi sekitar 1,17 juta token, dibanding sekitar 1.000 dengan code-calling. Progressive discovery adalah jawaban yang diusulkan: entry point kecil yang mengungkap katalog lebih banyak saat conversation menyempit, terkait dengan caching di atas. Saya sudah menulis tentang kapan overhead itu membuat API biasa lebih baik; progressive discovery adalah usaha MCP mengecilkan gap.

SDK dihasilkan dari spec

Item paling sunyi mungkin paling telling. Sekarang SDK, reference server, dan quickstart dimaintain manual. Roadmap menjalankan eksperimen: menghasilkan candidate Tier 1 SDK dan quickstart langsung dari spesifikasi, memvalidasi keduanya dengan conformance test suite, lalu menerbitkan temuan termasuk layer mana harus deterministic codegen dan mana model-assisted. Jika berhasil, bug kejelasan spec muncul sebagai generation failure dan SDK berhenti drift dari document yang seharusnya diimplementasikan.

Apa yang harus Anda lakukan sekarang?

Empat hal, berdasarkan urgensi:

1. Minggu ini: berhenti membangun work baru di surface deprecated. Roots, Sampling, Logging, dan transport legacy HTTP+SSE di-deprecated dalam spec 2026-07-28 dengan jendela minimum dua belas bulan. Masih bekerja. Implementasi baru jangan mengadopsi.

2. Bulan ini: buat server cache-friendly. List result sudah punya ttlMs dan cacheScope, ETags segera datang. Server yang menghasilkan cache hint masuk akal hari ini satu migration di depan.

3. Kuartal ini: audit cara agent melakukan autentikasi. Jika server MCP Anda percaya API key yang ditempel atau refresh token long-lived untuk caller unattended, itu tepat pola yang Agent Identity Working Group ingin ganti. Ikuti group daripada membuat delegation scheme sendiri. Sudut governance terkait dengan tulisan saya tentang governing AI agents.

4. Jika ingin membentuk protokol: tulis SEP di area prioritas. Bawa ke Working Group relevan lebih dulu dan dapatkan dukungan. Proposal selaras roadmap mendapat review dipercepat; proposal lain antre.

Dua hal jangan dilakukan. Jangan pause build menunggu spec berikutnya: spec sekarang adalah base stabil, dan deprecation policy menjamin peringatan dua belas bulan untuk apa pun yang akan hilang. Dan jangan anggap roadmap sebagai promise. Bagian pertama sendiri mengatakan prioritas dapat berubah dan kerja yang tidak dicantumkan masih bisa ship. Jika Anda lebih awal dalam perjalanan, walkthrough hands-on untuk server MCP pertama dan shortlist server yang layak dihubungkan adalah titik awal praktis.

Spesifikasi MCP 2026-07-28 men-deprecate Roots, Sampling, Logging, dan transport legacy HTTP+SSE dengan jendela minimum dua belas bulan. Pengumuman release menegaskan semuanya tetap bekerja selama periode tersebut, tetapi implementasi baru tidak seharusnya mengadopsi.

Gambaran besar

Mundur selangkah dan polanya adalah protokol yang tumbuh dewasa di depan publik. MCP didonasikan kepada Agentic AI Foundation yang vendor-neutral di bawah Linux Foundation pada Desember 2025, dengan OpenAI dan Block sebagai co-founder. Sejak itu ia mendapat contributor ladder, feature lifecycle, deprecation policy, dan kini pernyataan publik tentang ke mana perhatian maintainer diarahkan. Extensions framework juga melakukan kerja tenang tetapi nyata: SEP-2133 memungkinkan Working Group bereksperimen di repository experimental-ext- sebelum proposal formal, sehingga ide dapat diuji tanpa mendestabilisasi core.

Yang akan saya lihat dalam dua kuartal berikutnya adalah apakah HTTP over stdio benar-benar hadir. Jika server lokal dan remote benar-benar converge pada satu transport, "MCP server" berhenti menjadi jenis software khusus dan menjadi web service dengan wajah standar. Itulah titik ketika protokol menghilang ke plumbing, yang seharusnya dilakukan infrastruktur baik.

Pertanyaan yang sering ditanyakan

Apakah MCP sudah cukup stabil untuk dibangun sekarang?

Ya, dengan disiplin migrasi. Spec 2026-07-28 memperkenalkan deprecation policy formal dengan jendela minimum dua belas bulan, dan SDK ship dengan migration note untuk breaking changes. Protokol akan terus bergerak, tetapi sekarang memberi tahu setahun sebelumnya ketika sesuatu yang Anda andalkan akan hilang.

Apa yang terjadi dengan MCP sessions?

Mereka retired dalam spesifikasi 2026-07-28. Handshake initialize dan header Mcp-Session-Id hilang, SEP-2575 dan SEP-2567. Setiap request sekarang self-describing, membawa protocol version dan client capabilities di _meta, dan call opsional server/discover menggantikan handshake untuk client yang ingin capabilities upfront. Request apa pun bisa masuk ke instance mana pun di belakang round-robin load balancer.

Haruskah saya menunggu spec berikutnya sebelum membangun?

Tidak. Roadmap menjelaskan arah enam sampai dua belas bulan berikutnya, bukan feature committed, dan maintainer menyatakannya eksplisit. Spec saat ini stabil, cacheable, dan stateless. Bangun di atasnya, hindari surface deprecated, dan ikuti dua Working Group yang output-nya paling akan menyentuh Anda.