MCP artık 'durumsuz': Yapay zekâ araç protokolünün en büyük güncellemesi

MCP neydi?

MCP (Model Context Protocol), yapay zekâ uygulamalarının dış araçlarla konuşmasını sağlayan açık bir standart. Claude, ChatGPT ya da bir kod editörü, MCP sayesinde bir veritabanını sorgulayabiliyor, bir takvime erişebiliyor ya da bir API’yi çağırabiliyor. Aracı sunan tarafa MCP sunucusu, onu kullanan tarafa istemci deniyor.

Eski düzen: Önce tanışma, sonra oturum

Önceki sürümde (2025-11-25) bir araç çağırmadan önce istemci ile sunucu tanışmak zorundaydı. İstemci bir initialize isteği gönderiyor, sunucu da ona bir oturum kimliği (Mcp-Session-Id) veriyordu. Sonraki her istek bu kimliği taşımak zorundaydı.

Kulağa masum geliyor ama bir sorun var. Büyük bir servis tek bir sunucuda çalışmaz. Önünde, gelen istekleri birkaç kopyaya dağıtan bir yük dengeleyici (load balancer) durur. Oturum tek bir kopyada tutuluyorsa, o istemcinin bütün istekleri hep aynı kopyaya gitmek zorunda kalır. Buna “yapışkan oturum” (sticky session) deniyor. Ya da bütün kopyaların okuyabileceği ortak bir oturum deposu kurman gerekir. Videoda bunun için genelde Redis gibi ek bir servis kullanıldığı anlatılıyor.

Yeni düzen: Her istek kendi başına

2026-07-28 sürümünde MCP, protokol seviyesinde durumsuz (stateless) hale geldi:

• El sıkışma kaldırıldı. Protokol sürümü ve istemci bilgisi artık her isteğin içinde geliyor. Sunucunun yeteneklerini önceden öğrenmek isteyen istemci için server/discover adında yeni bir çağrı var.
• Oturum kimliği kaldırıldı. Herhangi bir istek, sunucunun herhangi bir kopyasına düşebilir.
• Yeni başlıklar. Mcp-Method ve Mcp-Name HTTP başlıkları sayesinde yük dengeleyiciler ve ağ geçitleri, isteğin gövdesini açmadan ne yapıldığını görüp ona göre yönlendirebiliyor.
• Önbellek ipuçları. Araç listesi gibi yanıtlar artık ttlMs (ne kadar süre taze sayılır) ve cacheScope (başka kullanıcılarla paylaşılabilir mi) bilgisi taşıyor. Tıpkı web’deki Cache-Control gibi.

Sonuç: MCP sunucusu artık sıradan bir web API’si gibi, kopyaları arasında sırayla dağıtılarak (round-robin) çalışabiliyor. Kullanılmadığında sıfıra inen sunucusuz ortamlara da daha rahat uyuyor.

Peki durum gerekiyorsa?

“Durumsuz protokol” demek, uygulamanın hiçbir şey hatırlamayacağı anlamına gelmiyor. MCP ekibinin önerisi, web API’lerinin hep yaptığı şey: Bir araç, örneğin bir sepet_id üretip döndürüyor. Model de sonraki çağrılarda bu kimliği normal bir parametre olarak geri gönderiyor. Böylece durum gizli bir başlıkta değil, modelin görebildiği bir yerde duruyor.

Başka neler değişti?

• Kullanıcıya soru sormak. Sunucu işin ortasında onay isteyebiliyor (“3 dosya silinsin mi?”). Eskiden bunun için bağlantının açık kalması gerekiyordu. Şimdi sunucu “bilgi lazım” diye yanıt veriyor, istemci cevabı toplayıp isteği yeniden gönderiyor.
• Uzun süren işler. Deneysel olan Tasks özelliği, ayrı bir resmi eklentiye dönüştü.
• MCP Apps. Sunucular, uygulamanın içinde güvenli bir çerçevede gösterilen etkileşimli arayüzler sunabiliyor.
• Emekliye ayrılanlar. Roots, Sampling ve Logging özellikleri “kullanımdan kalkacak” diye işaretlendi. Hemen silinmiyorlar. Yeni kurala göre kaldırılmadan önce en az 12 ay bekleniyor.

Bu sürüm geriye dönük uyumsuz değişiklikler içeriyor. Kendi MCP sunucunu yazdıysan, kullandığın SDK’nın yeni sürümüne geçmen gerekecek.

Düşün

• Bir web sitesine giriş yaptığında, site seni sonraki sayfada nasıl hatırlıyor? Bu “durumlu” mu, “durumsuz” mu bir tasarım?
• Durumu modelin görebileceği bir kimlikle taşımanın avantajı ne olabilir? Riski ne olabilir?