Model Bağlam Protokolü önemli bir altyapı dönüm noktasına ulaştı: 2026-07-28 revizyonu, protokolü durum bilgisi olmayan bir çekirdeğe taşıyor. Aracı sistemleri, araç sunucuları, IDE entegrasyonları veya çok modelli düzenleme katmanları oluşturan ekipler için bu, kozmetik bir özellik güncellemesi değildir. Oturumlar, başlatma, ölçeklendirme, uyumluluk ve yönetimle ilgili varsayımları değiştirir.
MCP sürüm adayı, 28 Temmuz spesifikasyonunu durum bilgisi olmayan bir protokol çekirdeği, bir Uzantı çerçevesi, Görevler, MCP Uygulamalar, yetkilendirmenin güçlendirilmesi ve resmi bir kullanımdan kaldırma politikasının eklenmesi olarak tanımladı. Resmi MCP blogu da sürümün önemli değişiklikler içerdiği konusunda uyardı. En görünür MCP sunucu uygulamalarından birini çalıştıran GitHub, son sürümden önce MCP Sunucusunun yeni spesifikasyonu zaten desteklediğini söyledi ve protokolü 28 Temmuz'da "durumsuz hale gelme" olarak tanımladı.
Pratik anlamı basit: MCP oturum ağırlıklı bir yerel entegrasyon katmanından ziyade, uzaktan araç erişimi için internet ölçeğinde bir protokole benziyor. Bu önemli çünkü aracı sistemler artık masaüstü geliştirici araçlarıyla sınırlı değil. Bulut hizmetleri, CI sistemleri, müşteri destek iş akışları, sorun izleyicileri ve kurumsal otomasyon platformlarında giderek daha fazla çalıştırılıyorlar.
MCP
ile değişenler: Başlık değişikliği, durum bilgisi olmayan bir protokol çekirdeğine geçiştir. GitHub'nin değişiklik günlüğü, yeni çekirdeğin oturumları kaldırdığını ve uzak MCP dağıtımlarının ölçeklendirilmesini kolaylaştırmak amacıyla başlatıldığını söylüyor. Bu önemli bir mimari değişimdir. Durum bilgisi olan protokoller, yerel araçlar ve kontrollü ortamlar için iyi çalışabilir ancak yatay ölçeklendirmeyi, sunucusuz yürütmeyi, yük devretmeyi, uç dağıtımı ve yük dengelemeyi karmaşık hale getirir.
Durum bilgisi olmayan bir çekirdek, uygulayıcılara MCP sunucuları sıradan web altyapısının arkasında çalıştırma konusunda daha fazla özgürlük sağlar. İstekler, belirli bir arka uçta uzun ömürlü bir oturum korunmadan örnekler arasında dağıtılabilir. Büyük kuruluşlar için bu, operasyonel karmaşıklığı azaltabilir. Daha küçük ekipler için, barındırılan MCP sunucuların özel uzun süreli altyapı yerine yönetilen bilgi işlem kullanılarak dağıtılması daha kolay hale gelebilir.
Daha geniş olan 2026-07-28 sürümü, sürüm adayı materyallerine göre bir Uzantı çerçevesi ve Görevler de sunuyor. Bu eklemeler, MCP'in daha modüler hale geldiğini ve daha uzun süreli çalışmalar konusunda daha açıklayıcı hale geldiğini gösteriyor. MCP Uygulamalar ve yetkilendirmenin güçlendirilmesi aynı yöne işaret ediyor: Protokol, ilk ekosistem birleşiminden aracılar arası etkileşim için daha resmi bir katmana doğru olgunlaşıyor.
Bu olgunlaşmanın maliyeti uyumluluk çalışmasıdır. MCP blogu, sürümü son derece önemli değişiklikler içeren bir sürüm olarak nitelendirdi ve revizyon etrafında yayınlanan TypeScript ve C# SDK materyalleri, geçiş desteği ve durum bilgisi olmayan kavramlara odaklandı. MCP sunucusu çalıştıran, MCP'yi bir IDE uzantısına yerleştiren veya aracı çağrılarını dahili altyapı üzerinden yönlendiren herhangi bir ekip, revizyonu arka plan standartları güncellemesi yerine bir mühendislik olayı olarak ele almalıdır.
Geliştiriciler ve operatörler için durum bilgisi olmayan MCP neden önemlidir
Ajan araçlarında sıradan API ölçeklendirmesinden farklı görünen bir ölçeklendirme sorunu vardır. Tek bir kullanıcı isteği birçok araç çağrısını, model dönüşünü, yeniden denemeyi, dosya okumasını, arama sorgusunu ve onay adımını tetikleyebilir. Araç protokolü dayanıklı oturumlar varsaydığında, üretim operatörlerinin bu etkileşimler genelinde durumu koruması veya protokol etrafında geçici çözümler oluşturması gerekir.
Oturumları çekirdekten kaldırarak, MCP aracı iş yüklerinin yoğun, dağıtılmış ve eşzamansız olduğu ortamlara daha iyi uyum sağlar. Sunucusuz işlevler, uç çalışanlar, Kubernetes dağıtımları ve çok bölgeli sistemlerin tümü, isteklerin bağımsız olarak ele alınabilmesinden yararlanır.Bu, aracı uygulamalarından durumu ortadan kaldırmaz; durumu protokol çekirdeğine yerleştirmek yerine uygulama veritabanlarına, görev kuyruklarına, kimlik sistemlerine veya açık iş akışı katmanlarına taşır.
Geliştiriciler için bu değişiklik, sonuçta uzak araç sunucularının kullanımını kolaylaştıracaktır. Platform ekipleri için gözlemlenebilirliği ve kapasite planlamasını basitleştirebilir. Operatörler, opak oturum benzeşim davranışında hata ayıklamak yerine istek düzeyindeki izlemelere, araç çağrısı gecikmesine, yetkilendirme kararlarına ve hata modellerine odaklanabilir.
Ayrıca bir yönetişim açısı da vardır. Kodlama asistanlarında ve kurumsal aracılarda MCP daha yaygın hale geldikçe şirketlerin, aracıların hangi araçları arayabileceği, hangi verilere erişebileceği ve hangi kullanıcıların veya hizmetlerin bunları çağırmasına izin verileceği konusunda politikalara ihtiyacı olacak. Bu nedenle yeni revizyondaki Authorization sertleşmesi tesadüfi değildir. Bu, araca erişimin artık geliştiricilere kolaylık sağlamaktan ziyade bir güvenlik sınırı olduğu gerçeğini yansıtıyor.
Kim etkilenir
En doğrudan etkilenen gruplar MCP sunucu bakımcıları, SDK kullanıcılar, aracı platform ekipleri ve dahili araçları yapay zeka aracılarına sunan kuruluşlardır. Bir sunucu oturum davranışına veya eski başlatma akışlarına bağlıysa, yeni spesifikasyona göre test edilmesi gerekecektir. Bir uygulama birden fazla MCP sürümünü destekliyorsa sürüm anlaşmasına, uyumluluk katmanlarına veya aşamalı bir geçiş planına ihtiyaç duyabilir.
IDE ve geliştirici aracı satıcıları da kapsam dahilindedir. MCP, kodlama aracıları, özel aracılar ve model yönetimi özelliklerinin yanında giderek daha fazla karşımıza çıkıyor. Durum bilgisi olmayan bir protokol çekirdeği, bu ürünlerin uzak araçları güvenilir bir şekilde aramasını kolaylaştırır, ancak bu yalnızca entegrasyonlarının spesifikasyona ayak uydurması durumunda mümkündür.
Ajan otomasyonunu kullanan işletmeler, MCP spesifikasyonunu hiç okumamış olsalar bile dikkatli olmalıdır. Değişiklik, depolara, biletleme sistemlerine, veritabanlarına, dahili bilgi tabanlarına veya dağıtım araçlarına bağlanan aracıların güvenilirliğini etkileyebilir. Geçiş pencereleri sırasında olası hata modları yalnızca bariz kesintiler değildir. Bunlar, eksik araç yeteneklerini, değişen kimlik doğrulama davranışını veya bir araç sunucusunun artık beklendiği gibi davranmaması nedeniyle aracıların farklı yollar izlemesini içerebilir.
Model Gate gibi bir AI API ağ geçidi için bağlantı pratiktir. Birleşik bir AI API giderek daha fazla model yönlendirme, API anahtar yönetimi, kullanım analitiği ve ekip API yönetiminin yanında yer alıyor. Aracı sistemleri sıradan model çağrılarının yanına MCP araç çağrılarını ekledikçe, ağ geçidi ve gözlemlenebilirlik katmanlarının iş akışının her iki tarafını da hesaba katması gerekecektir: hangi modelin kullanıldığı, hangi araçların çağrıldığı, bunların maliyeti, bunlara kimin yetki verdiği ve hataların nerede oluştuğu.
Taşıma öncelikleri ve açık sorular
İlk taşıma önceliği uyumluluk testidir. Ekipler MCP istemci ve sunucuların envanterini çıkarmalı, oturumlardaki bağımlılıkları belirlemeli veya davranışı başlatmalı ve 2026-07-28 SDK'larına veya mümkün olan yerlerde uyumluluk materyallerine göre test etmelidir. Üretim sistemleri, özellikle aracıların çekme istekleri oluşturma, sorunları değiştirme, müşteri verilerini sorgulama veya dağıtım iş akışlarını yürütme gibi yan etkileri olan eylemler gerçekleştirmesi durumunda yükseltme işlemini gerçekleştirmelidir.
İkinci öncelik gözlemlenebilirliktir. Durum bilgisi olmayan altyapının ölçeklendirilmesi daha kolay olabilir ancak dağıtılmış aracı sistemleri hâlâ korelasyon kimliklerine, iz yakalamaya, istek günlüklerine ve politika olaylarına ihtiyaç duyar. Bunlar olmadan ekipler oturum karmaşıklığını hata ayıklama karmaşıklığıyla değiştirebilir. Kullanım analizleri, özellikle aracı iş akışları faturalandırıldığında, ücret sınırlamasına tabi olduğunda veya ekip tarafından denetlendiğinde, model çağrıları ile araç çağrıları arasında ayrım yapmalıdır.
Üçüncü öncelik, yetkilendirmenin incelenmesidir. Yeni spesifikasyon, yetkilendirme semantiğini sertleştiriyorsa, uygulayıcıların eski erişim varsayımlarını yeni sürüme aktarmaması gerekir. Belirteç kapsamlarını, kullanıcı yetkilendirmesini, hizmet hesaplarını, denetim günlüklerini ve reddetme davranışını yeniden kontrol etmeleri gerekir.Araç erişimi, özellikle uzak MCP dağıtımları için varsayılan olarak en az ayrıcalıklı olmalıdır.
Kuruluşlar geri dönüşü olmayan tasarım kararları vermeden önce bazı ayrıntıların kontrol edilmeye değer olduğunu düşünüyoruz. Bu makale için mevcut araştırma; sürüm adayını, spesifikasyon sayfasını, SDK geçiş materyallerini ve GitHub'nin uygulama notunu içeriyordu. 2026-07-28 spesifikasyonunun son normatif metni, dahili standartlarda veya müşteri belgelerinde kesin protokol gereksinimlerinden alıntı yapılmadan önce doğrudan gözden geçirilmelidir.
Bu uyarıya rağmen, yön açıktır. MCP aracı altyapısı için daha üretim odaklı bir protokol haline geliyor. Durum bilgisi olmayan çekirdek, uzak dağıtımların ölçeklendirilmesini kolaylaştırmalı, ancak aynı zamanda ekosistemi daha önceki uygulamalardan gelen varsayımları temizlemeye de zorluyor. Temsilcilerle oluşturulan ekipler için bu, yalnızca bir yer işaretini değil, bir sprint biletini de hak eden türden bir protokol değişikliğidir.