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, Uzantılar çerçevesi, Görevler, MCP Uygulamaları, yetkilendirme sağlamlaştırma ve resmi bir kullanımdan kaldırma politikası ekleme olarak tanımladı. Resmi MCP blogu ayrıca sürümün önemli değişiklikler içerdiği konusunda uyardı. En görünür MCP sunucu uygulamalarından birini işleten GitHub, son sürümden önce, MCP Sunucusunun yeni spesifikasyonu zaten desteklediğini söyledi ve 28 Temmuz'da protokolü "durumsuz hale gelecek" 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'de değişen şey
Başlık değişikliği, durum bilgisi olmayan bir protokol çekirdeğine geçiştir. GitHub'ın değişiklik günlüğü, yeni çekirdeğin uzak MCP dağıtımlarının ölçeklendirilmesini kolaylaştırmak amacıyla oturumları kaldırdığını ve 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ını 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ı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'nin daha modüler hale geldiğini ve daha uzun süreli çalışmalar konusunda daha net hale geldiğini gösteriyor. MCP Uygulamaları ve yetkilendirmenin güçlendirilmesi aynı yöne işaret ediyor: Protokol, erken 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ı. Bir 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?
Aracı araçlarının, 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 çevresinde geçici çözümler oluşturması gerekir.
MCP, oturumları çekirdekten kaldırarak 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 sıraları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. MCP, kodlama asistanlarında ve kurumsal aracılarda 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 yetkilendirmenin sertleştirilmesi tesadüfi değildir.Bu, araca erişimin artık yalnızca geliştiricilere kolaylık sağlamak değil, bir güvenlik sınırı olduğu gerçeğini yansıtıyor.
Kimler 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 çağırması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 arasında eksik araç özellikleri, değişen kimlik doğrulama davranışı veya bir araç sunucusunun artık beklendiği gibi davranmaması nedeniyle aracıların farklı yollar izlemesi sayılabilir.
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önetişiminin yakınında yer alıyor. Aracı sistemleri sıradan model çağrılarının yanına MCP aracı ç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.
Geçiş öncelikleri ve açık sorular
İlk geçiş önceliği uyumluluk testidir. Ekipler, MCP istemcilerinin ve sunucularının envanterini çıkarmalı, oturumlardaki bağımlılıkları belirlemeli veya davranışı başlatmalı ve mevcut olduğunda 2026-07-28 SDK'larına veya 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 analitiği, özellikle aracı iş akışları faturalandırıldığında, ücretle sınırlandırıldığında veya ekip tarafından denetlendiğinde, model çağrıları ile araç çağrıları arasında ayrım yapmalıdır.
Üçüncü öncelik yetkilendirme incelemesidir. 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 edilmesi gerekir. Bu makale için mevcut araştırma; sürüm adayını, spesifikasyon sayfasını, SDK geçiş materyallerini ve GitHub'un uygulama notunu içeriyordu. 2026-07-28 spesifikasyonunun nihai 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 birlikte çalışan 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.