MCP'nin stateless revizyonu protokolü ikiye bölüyor ve üretici destek iddialarını belirsiz hale getiriyor

"MCP destekler" ifadesi sessizce tek bir anlama gelmeyi bıraktı. dev.to'da yayımlanan bir yazıya göre, 2026-07-28 tarihli bir spesifikasyon revizyonu Model Context Protocol'ün oturum modelini kaldırdı ve bunun sonucunda birbirleriyle uyumsuz iki protokol nesli şu anda aynı anda üretim ortamında çalışıyor — bir ürünün gerçekte hangisini konuştuğuna dair üreticilerin pazarlama metinlerinde hiçbir işaret yok.

Revizyon neyi değiştirdi

Yazar, bu revizyonu protokolün yaklaşık bir yıl önceki çıkışından bu yana yaşadığı en büyük değişiklik olarak nitelendiriyor. Eski tasarımda bir client, initialize çağrısını yaparak bağlantı açıyor, bir session ID alıyor ve tek bir server instance'ına sabitleniyordu. Bu modelin ölçeklendirilmesi sticky routing veya Redis gibi paylaşımlı bir session store gerektiriyordu; bu da her isteği o store'a bağımlı hale getiriyor, oturumları instance ömrüne bağlıyor ve load balancing'i süregiden bir sorun haline getiriyordu.

Revizyondan sonra her istek ihtiyacı olan her şeyi kendi içinde taşıyor. Artık el sıkışma yok, oturum yok ve benzerlik (affinity) gereksinimi yok: stateless sunucuların önüne basit bir round-robin load balancer koymak yeterli oluyor ve bir sunucuyu yeniden başlatmak artık bir olay olmaktan çıkıyor. Revizyon ayrıca yetkilendirmeyi OAuth ve OIDC geleneklerine doğru sıkılaştırdı, bir kullanımdan kaldırma (deprecation) politikası ekledi ve uzun süren işler ile sunucu tarafında render edilen UI'lar için extensions kavramını getirdi — ancak yazıya göre asıl altyapı varsayımlarını yeniden yazan değişiklik stateless olması.

Onay kutusu neden belirsizleşti

Bahisin protokol hijyeninden daha büyük olmasının nedeni protokolün erişimi. Yazı, en üst kademe SDK'ların ayda yarım milyar civarı indirme kaydettiğini, TypeScript ve Python SDK'larının ise yaşam boyu indirme sayılarının her birinin bir milyarı geçtiğini iddia ediyor. Bu ölçekteki bir spesifikasyon için belirsiz bir uyumluluk iddiası, çok büyük bir ekosisteme yayılan belirsiz bir iddiadır.

Pratik sorun şu: değişiklik kırıcı bir nitelik taşıyor ve ekosistem tam da bu kırılmanın üstünde duruyor. Bazı client'lar hâlâ eski SDK'lar çalıştırıyor; bazı sunucular hâlâ eski el sıkışmayı bekliyor. "MCP destekler" ifadesi iki revizyondan herhangi birini kastedebilir ve ifadenin kendisi hangisi olduğunu hiçbir şekilde ele vermiyor — yazar bunu, konektöründe hiçbir işaret bulunmayan bir USB cihazı almaya benzetiyor.

Konuştuğunuz MCP'nin hangisi olduğunu anlama

Yazı, teşhis öncelikli bir kontrol listesi sunuyor:

• Her şeyden önce initialize ile probe yapın. Eski revizyon sunucusu yanıt verir; yeni revizyon sunucusu bu çağrıyı beklemez. Yazar, tek başına bu probe'un tüm üretici listesini ayırdığını söylüyor.
• Sticky routing'i yalnızca yeni revizyon sunucuları için bırakın. Round-robin dengeleme yeniden tasarımın amacıdır, ancak eski revizyon sunucularının hâlâ oturumlara ihtiyacı var.
• Kimlik doğrulama akışlarını her iki nesilde yeniden doğrulayın. Yeni revizyon sunucularıyla çalışan bir client, eskilerine karşı sessizce başarısız olabilir; çünkü atladığı el sıkışma, eski auth yolu için yük taşıyıcı konumundaydı. Hata sizin bug'ınız gibi görünür ama aslında bir sürüm uyuşmazlığıdır — yazarın deyişiyle, öğleden sonraların gittiği yer burasıdır.
• SDK sürümlerini sabitleyin ve her sunucunun hangi revizyonu konuştuğunu kayıt altına alın. Belirsizlik kendi kendine çözülmez; yönetilir — ideal olarak sunucuların ve revizyonların yer aldığı basit iki sütunlu bir listede.

Olumlu taraf

Yazar, değişikliğin yönüne ilişkin genel olarak olumlu: stateless MCP daha basit ve yaşanan acı mimari değil geçiş dönemine ait — yazarın kırıcı geçişler için nadir olduğunu belirttiği bir ayrım. Yazı, Simon Willison'ın MCP konuşan araçların shell erişimi olan bir agent'a kıyasla denetlenebilir olduğu ve stateless bir çekirdeğin protokolün çoğu ops ekibinin zaten çalıştırdığı sıradan altyapıda ölçeklenmesini sağladığı yönündeki argümanına atıf yapıyor. Yeniden tasarım ayrıca MCP'yi komut satırı araçlarının her zaman çalıştığı modele yaklaştırıyor: bir komut çalıştır, çıktıyı al, yola devam et.

Neden önemli

Eski nesil çabucak kaybolmayacak. Yazar bazı hostların uzun süre eski SDK'larda kalmasını bekliyor ve bu da ekosistemin kırılmanın üstünde durmasını geçici bir dönem değil normal durum haline getiriyor. Agent entegrasyonları yapan ya da satın alan herkes için eyleme dönüştürülebilir değişim şu: üreticilere MCP destekleyip desteklemediklerini sormayı bırakıp hangi revizyonu uyguladıklarını sormaya başlamak — ve bir etikete değil bir probe ile doğrulamak, çünkü destek matrisleri çürür ve yeni spesifikasyon revizyonları yolda. Yazıya göre bir üretici revizyonunu adlandırsa bile birilerinin yine de kontrol etmesi gerekiyor.