MCP’nin Temmuz 2026 spesifikasyonu, protokol katmanından oturum durumunun (session state) her türlüsünü ayıklayarak, tüm durumu modelin bağlam penceresinde (context window) yaşamaya zorluyor. Bu değişiklik, herhangi bir MCP sunucusunun her türlü isteğe yanıt verebilmesine olanak tanıyarak; yük dengeleyiciler, sunucusuz (serverless) fonksiyonlar ve otomatik ölçeklenen Kubernetes podları arkasında tamamen durumsuz (stateless) dağıtımların önünü açıyor.

Değişiklik neden önemli

İlk sürümünden bu yana MCP (Model Communication Protocol), birden fazla HTTP çağrısı boyunca sohbet durumunu takip etmek için hafif bir oturum el sıkışması (handshake) ve bir Mcp-Session-Id başlığı kullanıyordu. Bu tasarım, sunucunun hangi araç tanımlayıcılarının (tool handles), örnekleme oranlarının veya günlükleme tercihlerinin belirli bir istemciye ait olduğunu hatırlamasını sağlıyordu. Ayrıca, kesilen bir bağlantının kaldığı yerden devam edebilmesi için yeniden başlatılabilir Server-Sent Events (SSE) akışları sunuyordu.

28 Temmuz 2026 spesifikasyonu, oturum el sıkışmasını tamamen ortadan kaldırıyor. Artık her istek, bir _meta alanında protokol sürümünü ve istemci yeteneklerini taşıyor ve Mcp-Session-Id başlığı ortadan kalkıyor. Roots, sampling ve logging alanları kullanımdan kaldırıldı (deprecated) olarak işaretleniyor. Kısacası, iletim protokolü (wire protocol) artık tamamen istek-yanıt (request-response) şeklindedir; sürdürülecek bir "oturum" bulunmamaktadır.

Geliştiriciler neler yapmalı

Durum artık sunucunun bir meselesi değil; modelin bağlam penceresinde yaşıyor. Bir modelin harici bir kaynağa atıfta bulunması gerektiğinde, bir araç sonucunun parçası olarak sunucudan açık bir tanımlayıcı (handle) alması gerekir. Bir sonraki istek, bu tanımlayıcıyı bir argüman olarak içerir ve model bunu diğer tüm token'lar gibi işler.

Bağlam penceresi sabit boyutlu bir token tamponu olduğundan, her tanımlayıcı (handle), kullanıcı istemleri (prompts) veya model çıktısı ile rekabet eden bir alan tüketir.

Güvenilirlik de değişiyor. SSE devam ettirilebilirliği veya mesajın yeniden iletilmesi özelliği olmadan, kesilen bir akış isteği tamamen kaybeder. İstemciler çağrıyı en baştan başlatmalıdır. Hızlı ve durumsuz sorgular için bu kabul edilebilir; ancak uzun süreli veri getirme veya çok adımlı ajan görevleri için geliştiricileri kendi yeniden deneme mantıklarını (retry logic) kurmaya veya işi daha küçük parçalara bölmeye zorlar.

Pilot Protocol boşluğu dolduruyor

MCP'nin durumsuzluğu (statelessness) kasıtlıdır, ancak ağ katmanını bağlantı düzeyinde kimlik veya güvenilirlik garantilerinden yoksun bırakır. MCP'nin altında yer alan Pilot Protocol bu boşluğu doldurur. Pilot, kimliği bir kez oluşturur ve paketleri gönderene bağlamak için şifreleme kullanır. MCP açısından bakıldığında, istemci her seferinde sadece yeni bir HTTP isteği gönderir; Pilot ise alttaki taşıma katmanını (transport) sabit tutar.

İki protokol birbirini tamamlar: MCP yalın, istek başına ucuz ve herhangi bir HTTP uç noktası arkasında kolayca ölçeklenebilir kalırken; Pilot, geleneksel oturum tabanlı protokollerin sağladığı ağır iş yükünü üstlenir.

Ölçeklenebilirlik avantajları

  • Yük dengeleyici dostu – Oturum bağlılığı (session affinity) gerektirmez; herhangi bir arka uç (backend) her türlü isteğe hizmet verebilir.
  • Serverless uyumlu – Fonksiyonlar talep üzerine ayağa kalkabilir, bir isteği işleyebilir ve kalıcı bir durum bırakmadan kapanabilir.
  • Kubernetes otomatik ölçeklendirme – Podlar özgürce eklenebilir veya kaldırılabilir; kontrol düzlemi (control plane) artık oturum haritalarını takip etmez.

Tavizler (Trade-offs)

  • Token yükü – Tanımlayıcılar (handles) ve diğer tüm durumlar artık modelin bağlam penceresini işgal ederek doğrudan istem (prompt) ve yanıt ile rekabet eder.
  • Model odaklı doğruluk – Model, tanımlayıcıları doğru bir şekilde geri yansıtmalıdır; bir halüsinasyon veya yazım hatası iş akışını bozabilir.
  • Yerleşik devam ettirilebilirlik yok – Uzun süren görevler kendi kontrol noktalarını (checkpointing) uygulamalı veya tam yeniden başlatma riskini kabul etmelidir.
  • Tanılama araçlarının kullanımdan kaldırılması – Roots, sampling ve logging alanları gittiği için, geliştiriciler uygulama katmanında eklemedikleri sürece hassas izleme için kullanışlı bir bağlantı noktası kaybederler.

Özetle

MCP 2026-07, oturum durumunu iletim hattından silerek protokolü herhangi bir yük dengeleyici, fonksiyon platformu veya uç düğüm (edge node) arkasında yer alabilecek saf bir HTTP uç noktasına dönüştürür. Avantajı net bir ölçeklenebilirliktir; dezavantajı ise durumun artık modelin sınırlı token penceresinde yaşaması ve güvenilirliğin istemciye ve alttaki Pilot katmanına dayanmasıdır. Yapay zeka ajanları saniyelerden saatlere uzandıkça, istek başına düşük fiyatlandırma ile token bütçesi baskısı arasındaki denge, durumsuz modelin kalıcı bir zafer olup olmayacağını belirleyecektir.