MCP oturumları çöpe attı — ve bu, spesifikasyondaki en dürüst hamle

2026-07-28 sürümüyle MCP'den kurulum el sıkışması ve oturum başlığı kalktı. Kaybettiğiniz şey zarafet değil, yapıştırıcıydı. Değişenlerin listesi ve göç planı.

Bu yazının İngilizcesi: English version.

Model Context Protocol'ün 28 Temmuz 2026 sürümü çıktı ve bence son iki yılın en dikkat çeken protokol kararını içeriyor: oturumlar kaldırıldı.

Bunu "yeni özellik geldi" diye değil, "eski bir hata kabul edildi" diye okumak lazım. Aşağıda ne değiştiğini, neden değiştiğini ve kodunuzda neye dokunmanız gerektiğini yazdım.

Eskiden ne vardı

MCP'nin ilk tasarımı bir bağlantı protokolü gibiydi. İstemci bağlanıyor, initialize gönderiyor, sunucu yeteneklerini bildiriyor, istemci initialized ile onaylıyor, sonra konuşma başlıyordu. Aradaki durum Mcp-Session-Id başlığında taşınıyordu.

Bu, bir soket protokolü için gayet mantıklı. Sorun şu ki MCP sunucuları HTTP üzerinden çalışıyor ve HTTP durumsuz. Yani protokol, altındaki taşıma katmanının doğasına ters bir şey talep ediyordu ve o farkı kapatmak operasyon tarafına yıkılıyordu:

• Yük dengeleyicinizin yapışkan oturum yapması gerekiyordu, yoksa ikinci istek durumu olmayan bir sunucuya düşüyordu.
• Yatay ölçekleme, ya oturumları paylaşılan bir depoya taşımayı ya da her örneğin kendi oturumlarını tutmasını gerektiriyordu.
• Sunucusuz (serverless) bir fonksiyona MCP sunucusu koymak baştan zordu; her çağrı yeni bir örnek demek.
• Sunucuyu yeniden başlatmak, açık bütün oturumları düşürüyordu.

Bunların hiçbiri protokolün suçu diye anlatılmıyordu. "Altyapını doğru kur" deniyordu. Yeni sürüm bunun sürdürülebilir olmadığını kabul etmiş.

Şimdi ne var

Sürüm duyurusuna göre kırıcı değişikliklerin özeti:

Duyurunun kendi ifadesiyle özetlenirse: aynı isteğe, arkadaki herhangi bir sunucu örneği cevap verebiliyor.

Sonuç şu: MCP sunucunuz artık sıradan bir HTTP servisi. Önüne herhangi bir yük dengeleyici koyabilirsiniz, yapışkanlık ayarı gerekmez. Yeniden başlatmak bir şey düşürmez. Bir Lambda'ya koyabilirsiniz. İstemci yetenekleri önceden öğrenmek isterse isteğe bağlı bir server/discover çağrısı var, ama zorunlu değil.

Mcp-Method başlığı neden bu kadar önemli

Listedeki en sıkıcı görünen madde aslında en pratik olanı. Eskiden bir MCP isteğinin ne yaptığını anlamak için JSON gövdesini ayrıştırmak gerekiyordu. Yani araya giren her katman — API geçidi, yönlendirici, hız sınırlayıcı, günlükleyici — gövdeyi okumak zorundaydı.

Şimdi metot ve isim HTTP başlığında. Bu şu demek:

• Yük dengeleyici, tools/call isteklerini ağır makinelere, tools/list isteklerini ucuz olanlara yönlendirebilir.
• Hız sınırlamayı araç bazında yapabilirsiniz: pahalı bir aracı dakikada üçle sınırlayın, listeleme çağrılarını serbest bırakın.
• Erişim günlüğü, gövdeyi hiç açmadan hangi aracın çağrıldığını yazabilir. Hassas veri gövdede kalır.

Bunların hepsi eskiden de yapılabiliyordu ama her biri özel kod istiyordu. Artık standart bir HTTP başlığına bakmakla oluyor. Bu, protokolü "kendi ekosistemi" olmaktan çıkarıp mevcut ağ altyapısının içine yerleştiren değişiklik.

Önbelleğe alınabilir listeler

Daha az konuşulan ama faturaya doğrudan yansıyan bir değişiklik daha var: tools/list, prompts/list, resources/list ve resources/read cevapları artık ttlMs ve cacheScope alanlarını taşıyabiliyor.

Bunun anlamını ajan araçlarının token faturası yazısında hesaplamıştım: araç tanımları her turda yeniden gönderiliyor ve bir ajan döngüsünde bu kalem sandığınızdan büyük. Sunucunun "bu listeyi 10 dakika saklayabilirsin" diyebilmesi, istemci tarafında bu tekrarı azaltmanın standart bir yolu demek. Kırıcı olmayan bir değişiklik ama parasal etkisi olan az sayıdaki maddeden biri.

Kullanımdan kaldırılanlar

Bu sürüm epey şeyi emekliye ayırdı. Hepsinin en az on iki aylık bir geçiş süresi var, yani yarın bir şey bozulmuyor:

Yetkilendirme tarafında iki tane de sıkılaştırma var: yetkilendirme sunucuları RFC 9207 uyarınca iss parametresi dönmek zorunda, ve dinamik kayıtta application_type artık zorunlu. Kimlik bilgileri de onları veren yetkilendirme sunucusuna bağlanıyor — yani bir sunucudan alınan jetonu başka bir yerde kullanmak kapanmış oluyor.

Tasks'ın çekirdekten uzantıya taşınması bana mantıklı geldi. Uzun süren işleri protokolün çekirdeğine koymak, çekirdeği o işlerin bütün karmaşasıyla (yeniden deneme, sonuçların ne kadar saklanacağı) yüklemek demekti. 2026 yol haritasında bu konuların uzantı tarafında ele alınacağı yazıyor.

Ne yapmalı

Bir MCP sunucusu işletiyorsanız sıralamam şöyle olurdu:

1. Önce oturum bağımlılığınızı bulun. Kodunuzda Mcp-Session-Id geçen her yeri arayın. Oturuma bağlı tuttuğunuz durum varsa, onun ya isteğin içine ya da paylaşılan bir depoya taşınması gerekiyor. Bu, göçün en uzun kısmı.
2. Yönlendirme başlıklarını ekleyin. Mcp-Method ve Mcp-Name zorunlu. Bunu ekledikten sonra geçidinizin gövde ayrıştırmasını kaldırabilirsiniz.
3. Liste cevaplarına ttlMs koyun. Kırıcı olmayan, tek satırlık, doğrudan token tasarrufu.
4. DCR kullanıyorsanız CIMD'ye takvim koyun. Bugün çalışmaya devam ediyor, ama geriye dönük uyumluluk kalıcı değil.
5. Eski SSE taşımasını bırakın. Bir yıllık geçiş süresi kulağa uzun geliyor; bu tür işlerde on birinci ayda hatırlanır.

Göç sırasında gözden kaçan bir kazanç da var: _meta artık istemci kimliğini ve yeteneklerini taşıdığı için, sunucu tarafında "bu istemci neyi destekliyor" sorusunun cevabı her istekte elinizin altında. Eskiden bunu el sıkışmadan hatırlamak zorundaydınız. Yani sürüm uyumluluğunu istek bazında ele almak artık daha kolay, daha zor değil.

Kişisel görüşüm

Protokol tasarımında "durum tutmak" hep daha zarif görünür. Bir kere el sıkışırsınız, sonra her istek küçülür, tekrar yoktur. Kâğıt üstünde temiz.

Ama dağıtık bir sistemde durumun bir bedeli var ve o bedeli protokolü yazan değil, protokolü işleten ödüyor. MCP'nin ilk hâli bu bedeli sessizce operasyon tarafına yıkıyordu. Yeni sürüm, her istekte biraz daha fazla veri taşımayı — yani teoride biraz daha israfı — kabul edip karşılığında bütün o yapışkanlık işini ortadan kaldırıyor.

Bu takas bana doğru geliyor. Ağ üzerinden birkaç yüz byte fazla göndermek 2026'da problem değil; yapışkan oturumları doğru kuramamak ise gerçek bir problem. Bir spesifikasyonun kendi ilk tasarımını böyle geri alması da sık görülen bir şey değil, hakkını vermek lazım.

← Tüm yazılar