MCP 2026-07-28: durumsuz çekirdek

MCP 2026-07-28 sürümü kesinleşti mi?

Evet. MCP (Model Context Protocol) projesi GitHub’da 29 Mayıs’ta “2026-07-28 RC” adıyla bir sürüm adayı, 28 Temmuz 2026’da da nihai sürümü yayımladı. Projenin blogu sürümü “genel kullanıma açılan” kararlı sürüm olarak duyuruyor. İki aşamalı takvim nedeniyle RC ile nihai sürüm karıştırılabiliyor; Kasım 2026 itibarıyla esas alınacak metin, spesifikasyon sitesindeki 2026-07-28 sürümüdür.

Blog yazısı değişikliği tek cümleyle özetliyor: MCP, çift yönlü ve durum tutan bir protokolden istek-cevap temelli, durumsuz bir protokole geçiyor. Projenin kendi ifadesiyle bu geçişin, özellikle oturum kimliğine dayanan geliştiriciler için bir taşıma maliyeti var.

MCP’nin bir ajana araç, kaynak ve istem sunma biçimi aynı kalıyor. MCP ile yapay zeka ajanı entegrasyonu yazımızda anlattığımız ilkeler, yani en az yetki, jeton aktarma yasağı, insan onayı ve adım adım kayıt, yeni sürümde de geçerli. Değişen, bu trafiğin ağ üzerinde nasıl taşındığı ve yönetildiği.

“Durumsuz” tam olarak ne anlama geliyor?

Önceki sürümlerde istemci önce initialize mesajıyla sunucuyla el sıkışıyor, sürüm ve yetenekleri bir kez konuşuyor, sunucu da HTTP üzerinde bir Mcp-Session-Id oturum kimliği verebiliyordu. Sonraki her istek bu oturuma bağlıydı. 2026-07-28 sürümünde:

• El sıkışma kalktı. Her istek, protokol sürümünü ve istemci yeteneklerini kendi _meta alanında taşıyor. HTTP’de ayrıca MCP-Protocol-Version başlığı zorunlu ve gövdedeki sürümle aynı olmalı.
• Oturumlar kalktı. Mcp-Session-Id başlığı artık yok. Çağrılar arasında durum tutması gereken sunucular, bir araçla kendi ürettikleri açık bir tanımlayıcıyı (handle) döndürüyor ve bu değer sonraki çağrılarda normal bir araç parametresi olarak geri geliyor.
• Keşif ayrı bir çağrı. Sunucular, desteklediği sürümleri ve yetenekleri bildiren server/discover çağrısını uygulamak zorunda. İstemci isterse önce bunu çağırır.
• Sunucudan istemciye istekler yeniden tasarlandı. Sunucu, kullanıcıdan bilgi veya bir model cevabı gerektiğinde artık kendi isteğini göndermiyor; “girdi gerekli” sonucu döndürüyor, istemci de cevabı ekleyerek aynı isteği tekrarlıyor. Spesifikasyon buna Multi Round-Trip Requests (MRTR) diyor.
• Kesilen akış yeniden başlamıyor. SSE akışlarının kaldığı yerden devam etmesi kaldırıldı. Bağlantı koparsa o istek kaybolur ve istemci aynı isteği yeni bir kimlikle yeniden göndermek zorundadır.

İş açısından en önemli sonuç ölçeklemedir. Oturum olmadığında bir isteği hangi sunucu kopyasının karşıladığı önemsizleşir; yük dengeleyicide “yapışkan oturum” ayarına ve oturum tablosuna gerek kalmaz. Sunucuları yatay çoğaltmak, sunucusuz ortamlarda çalıştırmak ve yeniden başlatmak kolaylaşır.

Mcp-Method ve Mcp-Name başlıkları ağ geçidi için neden önemli?

Streamable HTTP üzerinden gelen her istekte Mcp-Method başlığı (örneğin tools/call) ve araç çağrısı, kaynak okuma ve istem alma isteklerinde Mcp-Name başlığı (aracın adı veya kaynağın adresi) zorunlu. Spesifikasyon bunun amacını açıkça yazıyor: yük dengeleyiciler, ağ geçitleri ve gözlem araçları, JSON gövdesini çözümlemeden isteği yönlendirebilsin ve inceleyebilsin.

Pratikte bu şu kapıları açıyor:

• Araç bazında yetki. Ağ geçidi, Mcp-Name: siparis_iptal gören bir isteği yalnız belirli rollere açabilir.
• Araç bazında hız sınırı ve maliyet ölçümü. Hangi aracın ne kadar çağrıldığı, gövdeyi açmadan sayılabilir.
• Yönlendirme. Farklı araçlar farklı arka uç servislere gönderilebilir.

Sunucu araçları, belirli parametreleri de Mcp-Param-* başlıklarına yansıtılacak şekilde işaretleyebiliyor; örneğin bölge veya kiracı bilgisi. Güvenlik açısından kritik kural şu: gövdeyi işleyen sunucu, başlıklar ile gövde uyuşmazsa isteği 400 hatası ve HeaderMismatch koduyla reddetmek zorunda. Amaç, ağ geçidinin başlığa, sunucunun gövdeye bakarak farklı kararlar vermesini önlemek. Spesifikasyon ayrıca başlıklara göre politika uygulayan ara katmanların, sürüm başlığı eski veya eksik olan istekleri reddetmesini öneriyor; çünkü eski sürümlerde bu doğrulama yok.

Hangi özellikler kullanımdan kalkıyor?

Özellik	Durum	Önerilen yol
Roots	Kullanımdan kaldırıldı (deprecated)	Dizin veya dosyayı araç parametresi, kaynak adresi veya sunucu ayarıyla verin
Sampling	Kullanımdan kaldırıldı	Model sağlayıcısının API’sine doğrudan bağlanın
Logging	Kullanımdan kaldırıldı	stdio’da stderr’e yazın veya OpenTelemetry kullanın
Eski HTTP+SSE aktarımı	Kullanımdan kaldırıldı	Streamable HTTP’ye geçin
Dynamic Client Registration	Kullanımdan kaldırıldı	Client ID Metadata Documents (CIMD)
Görevler (tasks)	Çekirdekten çıkarıldı	İsteğe bağlı io.modelcontextprotocol/tasks uzantısı

Kullanımdan kaldırılan özellikler çalışmaya devam ediyor. Bu sürümle gelen yaşam döngüsü politikası, kaldırma öncesinde en az on iki aylık bir geçiş süresi tanımlıyor. Uzun süren işler için kullanılan görevler, artık resmi bir uzantı olarak yoklama (polling) temelli çalışıyor.

Yetkilendirme tarafında da sıkılaştırmalar var: istemci, yetkilendirme sunucusunun döndürdüğü iss değerini kodu kullanmadan önce doğrulamalı ve kayıtlı istemci bilgilerini onları veren yetkilendirme sunucusuna bağlı tutmalı. Liste cevapları (tools/list gibi) artık önbellek süresi bilgisi taşıyor ve araçların sabit sırayla dönmesi öneriliyor. OpenTelemetry iz bağlamının nasıl taşınacağı da tanımlandı; bu, ajan çağrılarını mevcut gözlem altyapınıza bağlamayı kolaylaştırıyor.

Bulut platformları yeni sürümü destekliyor mu?

Projenin blogu, TypeScript, Python, Go ve C# SDK’larının 2026-07-28 sürümünü desteklediğini, Rust SDK’sının ise beta desteği olduğunu söylüyor. AWS, yayın günü yazdığı blogda AgentCore Gateway’in yeni sürümü desteklediğini doğruladı. Destek isteğe bağlı: ağ geçidinin desteklediği sürümler listesi UpdateGateway ile güncelleniyor. AWS iki noktanın altını çiziyor: çağrı, gönderdiğiniz listeyi mevcut listenin yerine koyuyor, ekleme yapmıyor; bu yüzden eski sürümü de listeye yazmanız gerekiyor. Yeni davranışı yalnız 2026-07-28 isteyen istemciler alıyor, mevcut istemciler eskisi gibi çalışmaya devam ediyor.

Diğer platformlar ve hazır ajan ürünleri yeni sürüme kendi takvimleriyle geçiyor. Copilot Studio gibi hazır bir platform kullanıyorsanız hangi MCP sürümünü desteklediğini o ürünün belgelerinden kontrol edin. Hazır platform ile özel ajan arasındaki genel karar için Copilot Studio mu, özel ajan mı yazımıza bakabilirsiniz.

MCP ile ajan bağlamış bir şirket neyi yeniden test etmeli?

Geçiş kontrol listesi:

1. Envanter çıkarın. Hangi MCP sunucularınız var, hangi sürümü konuşuyorlar, hangi istemciler ve yapay zeka ajanları onlara bağlanıyor?
2. Oturuma dayanan yerleri bulun. Oturum kimliğinde sepet, taslak belge veya kullanıcı bağlamı tutan sunucuları açık tanımlayıcı modeline taşıyın.
3. Yazma araçlarını tekrar edilebilir yapın. Kesilen akış yeniden gönderilen bir istek demek. Ödeme, sipariş veya kayıt oluşturan araçlarda aynı isteğin iki kez işlenmemesi için tekrar anahtarı (idempotency key) veya mükerrer kontrolü ekleyin.
4. Ağ geçidini güncelleyin. Mcp-Method ve Mcp-Name başlıklarına göre araç bazında yetki, hız sınırı ve kayıt kuralları yazın; eski sürüm trafiğine başlıklara güvenerek karar vermeyin.
5. Yetkiyi yine sunucuda doğrulayın. Ağ geçidi ilk duvardır, tek duvar değildir. Sunucu, her çağrıda jetonun kendisi için verildiğini ve kullanıcının o araca yetkisi olduğunu kontrol etmeye devam etmeli.
6. Kullanımdan kalkan özellikleri taşıyın. Logging yerine OpenTelemetry, Sampling yerine doğrudan model API’si.
7. Kayıtları kontrol edin. Her araç çağrısında kim adına, hangi araç, hangi parametre, sonuç ve onaylayan kişi kaydediliyor mu? Oturum kalktığı için bu bilgileri istek bazında taşıyan bir iz kimliği şart.
8. İki sürümü birlikte test edin. Geçiş döneminde eski ve yeni istemcilerin aynı sunucu veya ağ geçidiyle doğru çalıştığını doğrulayın.

Nereden başlamalısınız?

1. MCP sunucularınızın ve istemcilerinizin listesini, konuştukları sürümle birlikte çıkarın.
2. Oturum kimliğine ve kullanımdan kalkan özelliklere bağımlılığı olan sunucuları işaretleyin.
3. Önce yalnız okuma araçları olan bir sunucuyu yeni sürüme taşıyın ve ağ geçidi kurallarını onunla deneyin.
4. Yazma araçlarına tekrar anahtarı ve kayıt kurallarını ekledikten sonra onları taşıyın.

Bu sıra özellikle iç araçları hızlı çoğalan teknoloji ve yazılım şirketlerinde işe yarar; birden fazla ekibin aynı MCP sunucularını kullandığı yerde ağ geçidi kuralları ortak bir dil sağlar.

Corrplus’ta MCP geçişine sunucu ve araç envanteriyle başlıyor, her aracın risk sınıfını ve yetki kuralını yazılı hale getiriyor, ardından sunucuları kısa döngülerle taşıyıp test ediyoruz. Ajanın kendisi için yapay zeka ajanı geliştirme, model ve API katmanı için LLM entegrasyonu sayfalarımıza bakabilirsiniz. Mevcut ajan mimarinizi birlikte gözden geçirmek isterseniz yapay zeka keşif programı iyi bir başlangıç noktasıdır.