MCP Artık Stateless: Ne Değişti, Ne Yapmalısınız - Çağlar Özenç

Merhaba,

MCP (Model Context Protocol) tarafında bugün büyük bir gün. Protokolün 2026-07-28 sürümü yayınlandı ve protokolü geliştiren ekibin kendi ifadesiyle bu, lansmandan bu yana yapılmış en büyük revizyon. Aday sürüm 21 Mayıs’ta kilitlenmişti, arada SDK ekiplerine ve istemci geliştiricilerine on haftalık bir doğrulama penceresi verildi, bugün de nihai hali çıktı.

Bu yazıyı iki parça halinde kurdum. Önce neden: MCP’nin bir yılda nereden nereye geldiğini ve bu değişikliklerin arkasındaki mantığı anlatacağım. Sonra ne yapmalı: kendi MCP sunucunuzu işletiyorsanız hangi maddelere dokunmanız gerektiğini ve her biri için ne yapacağınızı, kontrol listesi halinde vereceğim.

Eğer SQL MCP Server kurulum yazımı okuyup kendi sunucunuzu ayağa kaldırdıysanız, ikinci bölüm doğrudan sizi ilgilendiriyor.

Kısaca ne oldu

Protokol stateless oldu. initialize el sıkışması ve Mcp-Session-Id başlığı tamamen kaldırıldı. Her istek herhangi bir sunucu örneğine gidebilir.
Yetkilendirme sertleşti. Altı ayrı öneri ile OAuth ve OpenID Connect dünyasına hizalandı; iss doğrulaması artık zorunlu.
İki yeni yetenek: MCP Apps (sandbox’lı iframe içinde arayüz) ve Tasks (uzun süren işler), ikisi de resmi uzantı olarak.
Resmi deprecation politikası geldi. Active → Deprecated → Removed, aralarda en az 12 ay. Roots, Sampling ve Logging deprecated işaretlendi.
Bazı değişiklikler geriye dönük uyumlu değil. Kendi sunucunuz varsa dokunmanız gereken yerler var, aşağıda tek tek listeledim.

İÇINDEKILER

Bir yıl önce yerel bir araçtı
Stateless tam olarak ne demek
Peki durum bilgisi nerede tutulacak
MRTR: sunucu size soru sorduğunda
Yetkilendirme kurumsallaşıyor
MCP Apps ve Tasks
Asıl olgunlaşma sinyali: deprecation politikası
Pratik kısım: sunucunuzda neye dokunmalısınız
SDK’lar ve göç sırası
Sık sorulan sorular

Bir yıl önce yerel bir araçtı

MCP’nin ilk günlerini hatırlayın. Tipik kurulum şuydu: geliştiricinin kendi makinesinde çalışan bir sunucu, tek bir istemciyle konuşuyor, stdio üzerinden mesajlaşıyor. Oturum kavramı vardı çünkü tek bir bağlantı vardı; el sıkışma vardı çünkü karşı tarafta tek bir muhatap vardı. Protokol o dünyaya göre tasarlanmıştı ve o dünyada gayet iyi çalışıyordu.

Sonra iki şey oldu.

Birincisi, MCP sunucuları uzaklaştı. Artık laptopunuzda değil, bir sunucuda, çoğu zaman bir konteynerde, çoğu zaman birden fazla kopya halinde çalışıyorlar. İkincisi, ajan sayısı patladı. Tek bir geliştiricinin tek bir sohbeti değil, aynı anda yüzlerce ajanın aynı sunucuya bağlandığı bir tablo var karşımızda.

Bu iki gelişme, oturum tabanlı tasarımı bir anda yük haline getirdi. Neden? Çünkü oturum, “bu istemciyi hep aynı sunucu örneği karşılamalı” demek. Yani yapışkan oturum (sticky session). Yani paylaşımlı bir oturum deposu. Yani yük dengeleyicinizde, hangi isteğin hangi oturuma ait olduğunu anlamak için paket içine bakan bir katman. Ölçeklenmesi gereken her yerde ekstra bir altyapı parçası.

28 Temmuz revizyonunun temel hamlesi bu yükü ortadan kaldırmak. Ve bir protokolün “yerel geliştirici aracı”ndan “dağıtık kurumsal protokol”e terfi etmesi tam olarak böyle görünüyor.

Stateless tam olarak ne demek

Somutlaştıralım, çünkü “stateless oldu” cümlesi tek başına havada kalıyor.

Kaldırılan birinci şey: el sıkışma. Eskiden bir istemci sunucuya bağlandığında önce initialize gönderir, sunucu yeteneklerini bildirir, istemci initialized ile onaylardı. Bu tur tamamen kaldırıldı. Protokol sürümü ve istemci bilgisi artık her istekte _meta alanı içinde taşınıyor.

Kaldırılan ikinci şey: oturum kimliği. Mcp-Session-Id başlığı ve protokol seviyesindeki oturum kavramı yok. İstemci, isteklerinin aynı sunucuya gideceğine güvenemez, güvenmesi de gerekmez.

Bunun pratik karşılığı çok net: daha önce yapışkan oturum, paylaşımlı oturum deposu ve gateway’de derin paket incelemesi isteyen bir uzak MCP sunucusu, artık sıradan bir round-robin yük dengeleyicinin arkasında çalışabiliyor. Kubernetes’te üç replika kaldırıp beşe çıkarmak, önüne standart bir ingress koymak yeterli. Altyapı tarafında bu ciddi bir sadeleşme.

Şöyle düşünün: HTTP’nin kendisi neden bu kadar iyi ölçekleniyor? Çünkü stateless. Her istek kendi kendine yeter. MCP de şimdi aynı prensibi benimsedi.

Peki durum bilgisi nerede tutulacak

Akla gelen ilk itiraz şu: “Bazı işler doğası gereği durum ister. Alışveriş sepeti gibi, çok adımlı bir işlem gibi. Bunlar ne olacak?”

Yeni yaklaşım şu: durum açık tutamaklarla (explicit handles) taşınıyor. Sunucu bir tanımlayıcı üretiyor, mesela bir sepet_id, bunu araç sonucu olarak modele döndürüyor. Model de sonraki çağrılarda bu tanımlayıcıyı araç parametresi olarak geri gönderiyor.

İlk bakışta “aynı şeyi elle yapıyoruz” gibi duruyor ama aradaki fark önemli: durum artık taşıma katmanının içinde gizli değil, modelin gördüğü bir şey. Bu hem hata ayıklamayı kolaylaştırıyor, hem de o durumun ne olduğunu denetleyebilir hale getiriyor. Ajan neyi taşıdığını biliyor, siz de log’a bakınca görüyorsunuz.

MRTR: sunucu size soru sorduğunda

Stateless olmanın çözmesi gereken bir problem daha vardı: sunucu, bir işlemin ortasında istemciden ek bilgi isteyebiliyordu. Eskiden bu, açık duran bir SSE akışı üzerinden yapılıyordu. Ama kalıcı bağlantı, tam da kurtulmak istediğimiz şey.

Yerine MRTR (Multi Round-Trip Requests) geldi. İşleyişi şöyle:

Sunucu, işlemi tamamlamak için girdiye ihtiyaç duyduğunda bir InputRequiredResult döndürüyor. Bunun içinde sorulacak sorunun şeması ve mesajı var, bir de requestState adında base64 kodlanmış bir sunucu durumu.
İstemci cevapları topluyor.
İstemci aynı çağrıyı tekrar yapıyor, bu sefer inputResponses ve az önce aldığı requestState‘i aynen geri göndererek.

Kilit nokta şu: ihtiyaç duyulan her şey isteğin içinde olduğu için, bu ikinci çağrıyı herhangi bir sunucu örneği karşılayabiliyor. İlk çağrıyı hangi kopyanın aldığının önemi yok. Kalıcı bağlantı da gerekmiyor.

Yetkilendirme kurumsallaşıyor

Bu revizyonda altı ayrı öneri (SEP) yetkilendirmeye dokunuyor. Hepsi aynı yöne bakıyor: MCP’yi standart OAuth ve OpenID Connect dağıtımlarına yaklaştırmak.

SEP-2468, RFC 9207 uyarınca iss parametresi doğrulamasını getiriyor. Yani istemci, yetkilendirme cevabının gerçekten beklediği sunucudan geldiğini doğrulamak zorunda. Şimdilik geçiş dönemi var ama ileriki sürümler iss içermeyen cevapları tamamen reddedecek.
SEP-837, Dinamik İstemci Kaydı’nda (DCR) OpenID Connect’in application_type bildirimini ekliyor.
SEP-2352, kimlik bilgisinin onu veren yetkilendirme sunucusunun issuer değerine bağlanmasını istiyor.
SEP-2207, OpenID Connect için refresh token isteklerini belgeliyor.
SEP-2350, adım adım yetki yükseltmede (step-up) kapsam birikimini netleştiriyor.
SEP-2351, .well-known keşif son ekini belgeliyor.

Bu maddeleri tek tek okuduğunuzda teknik ayrıntı gibi görünüyorlar. Birlikte okuduğunuzda anlattıkları şey şu: MCP artık kurumsal kimlik altyapısıyla düzgün konuşmak istiyor. Şirketinizin Entra ID’si, Okta’sı, Keycloak’ı ne ise, MCP sunucunuz onun arkasına standart biçimde girebilsin diye.

MCP Apps ve Tasks

İki yeni yetenek, ikisi de resmi uzantı statüsünde.

MCP Apps (SEP-1865)

Sunucular artık etkileşimli HTML arayüzler sunabiliyor; istemci bunları sandbox’lı bir iframe içinde gösteriyor. Araçlar kullanacakları arayüz şablonlarını önceden bildiriyor, böylece hem önden yüklenebiliyor hem de güvenlik incelemesinden geçirilebiliyor.

Güzel tarafı şu: arayüzdeki bütün eylemler, doğrudan araç çağrılarıyla aynı JSON-RPC protokolünu kullanıyor. Yani kullanıcı bir düğmeye bastığında da denetim kaydı (audit trail) bozulmuyor, her şey aynı yerden akıyor. Yönetişim açısından önemli bir tercih.

Tasks (SEP-2663)

Uzun süren işler için tasarlanan Tasks, deneysel bir çekirdek özellikten uzantıya taşındı ve yaşam döngüsü stateless olmaya göre yeniden kurgulandı:

Sunucu, bir tools/call isteğine bir görev tutamağı ile cevap veriyor.
İstemci süreci tasks/get, tasks/update ve tasks/cancel ile yönetiyor.
Görev oluşturma artık sunucu yönlendirmeli: istemci yeteneğini duyuruyor, bir çağrının göreve dönüşüp dönüşmeyeceğine sunucu karar veriyor.
tasks/list kaldırıldı.

Dikkat: 2025-11-25 sürümüne göre Tasks uygulaması yazdıysanız, bu yeni yaşam döngüsüne göç etmeniz gerekiyor. İki API birbiriyle uyumlu değil.

Asıl olgunlaşma sinyali: deprecation politikası

Bu revizyonun en az konuşulan ama bence en önemli parçası burası.

MCP artık resmi bir yaşam döngüsü politikasına sahip (SEP-2577): Active → Deprecated → Removed, ve bir özelliğin deprecated işaretlenmesiyle kaldırılabileceği en erken an arasında en az on iki ay olmak zorunda.

Bunun anlamı şu: protokol artık “mevcut kurulumları kırmadan evrilme” sözü veriyor. Bir özelliğin bir gün sessizce yok olmayacağını, en az bir yıl önceden haber alacağınızı biliyorsunuz. Kurumsal bir bağımlılık kabul edeceğiniz teknolojide aradığınız şey tam olarak budur.

Bu politikayla birlikte üç özellik deprecated işaretlendi. Hepsi çalışmaya devam ediyor, sadece not düşülmüş durumda:

Deprecated özellik	Yerine ne kullanılacak
Roots	Araç parametreleri, resource URI’ları ya da sunucu yapılandırması
Sampling	Doğrudan LLM sağlayıcısının API’siyle entegrasyon
Logging	stdio için `stderr`; yapılandırılmış gözlemlenebilirlik için OpenTelemetry

Bu üçü de “yalnızca işaretleme” düzeyinde deprecation. Yani bugün acele etmeniz gereken bir şey yok, ama önümüzdeki yılın yol haritasına yazmanız gereken üç madde var.

Pratik kısım: sunucunuzda neye dokunmalısınız

Buraya kadar olan kısım “neden” idi. Şimdi asıl mesele: kendi MCP sunucunuzu işletiyorsanız neye dokunmanız gerekiyor?

Dokunmanız gereken maddeleri tek tabloda topladım. ŞİMDİ etiketli olanları göç ederken halletmeniz gerekiyor, SÜRE VAR etiketli olanlar en az bir yıl çalışmaya devam ediyor.

Ne değişti	Durum	Ne yapmalısınız
El sıkışma kaldırıldı `initialize` / `initialized`	ŞİMDİ	El sıkışmayı bekleyen ya da yeteneklerini orada bildiren kodu kaldırın. Protokol sürümü ve istemci bilgisini her istekteki `_meta` alanından okuyun.
Oturum kimliği kaldırıldı `Mcp-Session-Id`	ŞİMDİ	Oturum deposu, yapışkan oturum ayarı ve oturuma bağlı bellek içi durum ne varsa çıkarın. Durum gerekiyorsa açık tutamak yaklaşımına geçin.
Hata kodu değişti SEP-2164	ŞİMDİ	Bulunamayan kaynak hatası, MCP’ye özel `-32002`‘den standart JSON-RPC `-32602`‘ye (Invalid Params) geçti. Kodun içinde `-32002` değerini birebir arayan yer varsa güncelleyin.
Yeni zorunlu başlıklar SEP-2243	ŞİMDİ	Streamable HTTP artık yönlendirme için `Mcp-Method` ve `Mcp-Name` başlıklarını istiyor. Üstelik sunucular, başlıklarla gövde birbirini tutmuyorsa isteği reddediyor. İstemci tarafında bu başlıkları göndermeyi ekleyin.
Tasks yaşam döngüsü SEP-2663	ŞİMDİ	Yalnızca Tasks kullanıyorsanız. `2025-11-25` uygulamanız yeni uzantıyla uyumlu değil; görev tutamağı modeline göçün, `tasks/list` çağrılarını kaldırın.
`iss` doğrulaması SEP-2468	ŞİMDİ	İstemci tarafında `iss` doğrulaması ekleyin. Bugün geçiş dönemi ama ileriki sürümler `iss` içermeyen cevapları reddedecek, şimdi halledin.
Roots / Sampling / Logging SEP-2577	SÜRE VAR	Çalışmaya devam ediyorlar, en az 12 ay. Yukarıdaki tablodaki karşılıklarına geçişi yol haritanıza alın, acele etmeyin.

Kontrol listesi

Sunucunuzun başına oturduğunuzda sırayla bakacağınız yerler:

Kod tabanında initialize, initialized ve session kelimelerini arayın. Çıkanların her biri gözden geçirilecek.
-32002 değerini arayın. Bulursanız -32602 ile değiştirin.
Yük dengeleyici ve ingress yapılandırmanızdaki yapışkan oturum ayarını kapatın. Artık gerekmiyor, üstelik gereksiz yere bir kopyayı yoruyor.
Oturuma bağlı bellek içi durumunuz varsa (kullanıcı başına önbellek gibi), bunu açık tutamağa ya da harici bir depoya taşıyın.
Yetkilendirme akışınızda iss doğrulaması var mı, bakın. Yoksa ekleyin.
Tasks kullanıyorsanız yeni yaşam döngüsüne göçün.
Roots, Sampling, Logging kullanıyorsanız bir not düşün; bu yılın işi değil ama gelecek yılın işi.

SDK’lar ve göç sırası

İyi haber: kendi elinizle protokol seviyesinde uğraşmanıza çoğu zaman gerek yok. Dört Tier 1 SDK’nın beta sürümleri hazır: Python, TypeScript, Go ve C#.

Kurulumda dikkat edilecek bir incelik var. Python, Go ve C# tarafında SDK’yı normal şekilde kurarsanız hala kararlı sürüm gelir; beta istiyorsanız bunu açıkça belirtmeniz gerekiyor. TypeScript tarafında ise durum farklı, çünkü paket bölündü:

TYPESCRIPT// Eskiden tek paketti:
//   @modelcontextprotocol/sdk

// Artık ikiye ayrıldı:
npm install @modelcontextprotocol/server@beta
npm install @modelcontextprotocol/client@beta

Yeni TypeScript paketlerinin henüz kararlı sürümü olmadığı için, onları kurmanın kendisi zaten beta’ya geçiş anlamına geliyor. Ayrıca Express, Hono, Fastify ve Node’un kendi http modülü için ince adaptörler geliyor.

Python tarafında v2, PyPI’da 2.0.0b1 olarak duruyor ve kararlı sürümü spesifikasyonla birlikte planlanmıştı.

Göç sırası önerim: önce bir test ortamında beta SDK’yı gerçek iş yükünüzle çalıştırın. Değişikliklerin çoğunu SDK sizin için hallediyor; sizin elle dokunmanız gereken kısım genelde oturum mantığı, hata kodu eşlemesi ve yetkilendirme akışı oluyor. Bu üçünü test ortamında gördükten sonra production’a alın.

Not: Zaman baskısı altında değilsiniz. Eski sürümler bir anda kapanmıyor; deprecation politikasının varlığı zaten bunun güvencesi. Ama iss doğrulaması gibi ileride sertleşecek maddeleri erken halletmek, sonra acil yama yapmaktan ucuz.

Sık sorulan sorular

Mevcut MCP sunucum yarın çalışmayı durdurur mu?

Hayır. Eski protokol sürümleri bir gecede kapanmıyor, istemciler bir süre daha eski sürümlerle konuşmaya devam edecek. Ama yeni istemcilerle uyumlu kalmak istiyorsanız göç etmeniz gerekecek.

Stateless olması güvenliği zayıflatır mı?

Tam tersi yönde bir tablo var. Yetkilendirme bu sürümde sertleşti, durum artık taşıma katmanında gizli değil görünür halde, ve MCP Apps’teki arayüz eylemleri bile aynı denetim kaydından geçiyor. Oturumun kaldırılması bir ölçekleme kararı, güvenlik gevşetmesi değil.

Bir MCP sunucusu kullanıyorum ama geliştirmiyorum, beni etkiler mi?

Doğrudan değil. Kullandığınız sunucuyu geliştiren taraf göçü yapacak. Sizin tarafınızda olabilecek tek şey, istemci uygulamanızın güncellenmesi gerekmesi.

Roots, Sampling ve Logging’i hemen bırakmalı mıyım?

Hayır. En az on iki ay çalışmaya devam edecekler. Yeni yazacağınız kodda kullanmamak mantıklı, ama mevcut kodu bugün acilen değiştirmeniz gerekmiyor.

Hangi SDK ile başlamalıyım?

Zaten kullandığınızla. Dördü de (Python, TypeScript, Go, C#) bu sürümü destekliyor. Yeni başlıyorsanız ekibinizin en rahat olduğu dil doğru cevap; protokol tarafında bir fark yok.

Kapanış

Bir yıl önce MCP, geliştiricinin makinesinde tek bir ajanla konuşan yerel bir protokoldu. 28 Temmuz revizyonu onu, arkasında yüzlerce eşzamanlı ajanın olduğu, standart yük dengeleyiciyle ölçeklenen, kurumsal kimlik sistemine bağlanabilen dağıtık bir protokole çeviriyor.

Bunun bir bedeli var: bir kereye mahsus bir göç işi sizi bekliyor. Ama karşılığında aldığınız şey, üzerine kurumsal bağımlılık inşa edebileceğiniz bir olgunluk. Resmi deprecation politikası da tam olarak bu sözü veriyor: bundan sonra hiçbir şey habersiz kaybolmayacak.

Kendi sunucunuz varsa yukarıdaki kontrol listesiyle bir öğleden sonra ayırmanızı öneririm. İşin çoğunu SDK hallediyor, geriye kalan üç beş yer var.

MCP tarafında neler yaptığınızı, hangi maddede takıldığınızı yorumlarda paylaşırsanız sevinirim. Kolay gelsin 🙂

Devamı için 👇

🛠️ Kendi MCP sunucunuzu henüz kurmadıysanız: SQL MCP Server: 3 Adımda Güvenli ve Kolay Kurulum
🔒 Ajanlara veri erişimi verirken yönetişim tarafı: AI Agent Çağında Veritabanının Yeni Sınavı — 12 Madde
💬 Göçte hangi maddede takıldınız? Yorumlarda yazın, birlikte bakalım.

Kaynaklar

Aday sürüm duyurusu ve teknik ayrıntılar: blog.modelcontextprotocol.io — The 2026-07-28 MCP Specification Release Candidate
Beta SDK duyurusu: blog.modelcontextprotocol.io — Beta SDKs for the 2026-07-28 MCP Spec Release Candidate Are Here
Protokol ana sayfası ve spesifikasyon: modelcontextprotocol.io
TypeScript SDK: github.com/modelcontextprotocol/typescript-sdk
Python SDK: github.com/modelcontextprotocol/python-sdk

Bağlantılar 28 Temmuz 2026 itibarıyla kontrol edilmiştir. SEP numaraları aday sürüm duyurusundaki adlandırmayı takip eder.