Geçen sene bu zamanlar MCP sunucusu yazmak eğlenceli bir hafta sonu projesiydi. Bir stdio süreci açıyordunuz, birkaç tool tanımlıyordunuz, Claude Desktop'ın config dosyasına ekliyordunuz, olmuştu. Sonra işler ciddileşti. Sunucuyu uzağa taşıdınız, HTTP'ye geçtiniz, iki instance açtınız ve o noktada protokolün size verdiği oturum modeli birdenbire bir yük haline geldi.
28 Temmuz 2026'da yayımlanması planlanan spesifikasyonun sürüm adayı tam olarak bu yükü kaldırıyor. Resmî tanımıyla protokolün lansmandan bu yana geçirdiği en kapsamlı revizyon. Lead maintainer David Soria Parra'nın ifadesiyle "MCP'yi MCP yapan pek çok şey gitti."
Bu yazı, elinde çalışan bir MCP sunucusu olan ve "şimdi ne yapacağım" diye soran geliştirici için. Spesifikasyonun tamamını değil, sizi gerçekten kesecek kısımları anlatıyorum.
Kısa cevap: oturum yok
Eski modelde bir tool çağırmak iki adımdı. Önce initialize gönderiyordunuz, sunucu size bir Mcp-Session-Id dönüyordu, sonraki her istekte o başlığı taşıyordunuz.
POST /mcp HTTP/1.1
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"initialize",
"params":{"protocolVersion":"2025-11-25","capabilities":{},
"clientInfo":{"name":"my-app","version":"1.0"}}}
Ardından:
POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json
{"jsonrpc":"2.0","id":2,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"}}}
Bu Mcp-Session-Id masum görünüyor ama size şunu dayatıyordu: o oturumu üreten instance'a yapışmak zorundasınız. Yani sticky session, yani paylaşımlı bir session store, yani load balancer'da gövdeyi açıp bakan bir kural. Üç instance'lık bir dağıtım için hatırı sayılır bir altyapı.
Yeni sürümde aynı çağrı tek ve kendi kendine yeten bir istek:
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"},
"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}
Handshake yok. Oturum başlığı yok. Protokol sürümü, istemci bilgisi ve yetenekleri artık her istekte _meta içinde geliyor. Sunucu yeteneklerini önceden öğrenmek isteyen istemci için server/discover diye yeni bir metot var.
Pratik sonucu şu: istek herhangi bir instance'a düşebilir. Düz round robin yeter. Session store'u silebilirsiniz.
Peki durumu nerede tutacağım
Bu soruyu ilk duyduğumda ben de sordum. Sepet oluşturup içine ürün ekleyen bir tool setiniz varsa, sepet nerede yaşayacak?
Cevap sıkıcı derecede klasik: HTTP API'lerin yirmi yıldır yaptığı şey. Tool'unuz açık bir tanıtıcı üretsin, modele döndürsün, model sonraki çağrıda parametre olarak geri versin.
create_basket() -> { "basket_id": "bskt_9f2a" }
add_item(basket_id: "bskt_9f2a", sku: "TR-1188")
Protokol artık bu durumu sizin için yönetmiyor ama yönetmenizi de engellemiyor. Spesifikasyon ekibinin gözlemi ilginç: bu desen oturum durumunun yerine geçen bir taviz değil, çoğu zaman ondan daha güçlü. Çünkü tanıtıcı modele görünür oluyor. Model onu tool'lar arasında taşıyabiliyor, üzerine akıl yürütebiliyor, adımlar arasında devredebiliyor. Transport metadata'sında saklanan gizli oturum durumunun asla izin vermediği şeyler.
Türkiye'deki ekiplerin çoğu zaten Redis'te session tutuyordu. O Redis'i tamamen kaldırın demiyorum, ama artık protokol yüzünden orada olmasına gerek yok. İş mantığınız gerektiriyorsa kalsın.
Sunucu size soru sormak isterse
Durumsuz bir protokolde sunucunun çağrı ortasında kullanıcıya soru sorması sorunlu hale geliyor. Eskiden bir SSE akışı açık tutuluyordu. Artık öyle değil.
Sunucu InputRequiredResult dönüyor:
{
"resultType": "inputRequired",
"inputRequests": {
"confirm": {
"type": "elicitation",
"message": "3 dosya silinsin mi?",
"schema": { "type": "boolean" }
}
},
"requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}
İstemci cevabı topluyor ve orijinal çağrıyı inputResponses ile birlikte, requestState değerini aynen geri yollayarak tekrar yapıyor. requestState içinde sunucunun devam etmek için ihtiyaç duyduğu her şey var, dolayısıyla tekrar isteği bambaşka bir instance'a düşebilir ve sorun olmaz.
Bir kural daha sertleşti: sunucu artık yalnızca aktif olarak bir istemci isteğini işlerken soru sorabiliyor. Eski sürümde bu tavsiyeydi, şimdi zorunlu. Kullanıcı hiçbir zaman durup dururken bir onay kutusuyla karşılaşmıyor.
Operasyonu kolaylaştıran üç küçük değişiklik
Yönlendirilebilirlik. Streamable HTTP artık Mcp-Method ve Mcp-Name başlıklarını zorunlu kılıyor. Load balancer, gateway ve rate limiter gövdeyi açmadan operasyona göre karar verebiliyor. Sunucu, başlıkla gövdenin uyuşmadığı istekleri reddediyor, dolayısıyla bunu "isteğe bağlı bir kolaylık" sanmayın.
Önbelleklenebilirlik. Liste ve kaynak okuma sonuçları artık ttlMs ve cacheScope taşıyor. HTTP Cache-Control mantığının aynısı. İstemci bir tools/list yanıtının ne kadar taze olduğunu ve kullanıcılar arasında paylaşılmasının güvenli olup olmadığını biliyor. Listenin değiştiğini öğrenmek için sürekli açık bir SSE akışı tutmak zorunda değilsiniz artık.
İzlenebilirlik. W3C Trace Context yayılımı _meta içinde belgelendi. traceparent, tracestate ve baggage anahtar isimleri sabitlendi. Host uygulamada başlayan bir iz, istemci SDK'sından MCP sunucusuna, oradan sunucunun çağırdığı alt servislere kadar takip edilip OpenTelemetry uyumlu bir backend'de tek bir span ağacı olarak görünüyor. Bu, üretimde MCP koşturan herkesin özlediği şeydi.
Deprecate edilenler
Üç temel özellik artık deprecated:
| Özellik | Yerine ne kullanılacak |
|---|---|
| Roots | Tool parametreleri, kaynak URI'leri veya sunucu yapılandırması |
| Sampling | Doğrudan LLM sağlayıcı API entegrasyonu |
| Logging | stdio için stderr, yapılandırılmış gözlemlenebilirlik için OpenTelemetry |
Bunlar yalnızca işaretleme düzeyinde. Metotlar, tipler ve capability bayrakları bu sürümde ve bundan sonraki bir yıl içinde yayınlanacak her sürümde çalışmaya devam ediyor. Kaldırılmaları ayrı bir SEP gerektiriyor.
Sampling'in gidişi bazı kütüphaneleri üzecek. Ama dürüst olmak gerekirse sampling üretimde neredeyse hiç düzgün çalışmadı. Sunucunun istemcinin modelini kullanması kulağa zarif geliyordu, faturayı kimin ödeyeceği ve hangi modelin kullanılacağı sorularının cevabı hiçbir zaman net olmadı.
Bir de sessiz ama can yakan bir değişiklik var: eksik kaynak hatası MCP'ye özgü -32002 kodundan JSON-RPC standardı olan -32602 Invalid Params'a taşındı. İstemcinizde literal -32002 üzerinde eşleşme yapan bir kod varsa, güncelleyin.
Tools şemaları artık gerçek JSON Schema
inputSchema ve outputSchema tam JSON Schema 2020-12'ye yükseltildi. Input şemaları kök seviyede type: "object" kısıtını koruyor ama artık oneOf, anyOf, allOf kompozisyonuna, koşullara, $ref ve $defs referanslarına izin veriyor. Output şemalarında kısıt yok ve structuredContent artık nesne olmak zorunda değil, herhangi bir JSON değeri olabilir.
Bir uyarı: dış $ref URI'lerini otomatik çözmeyin. Şema derinliğini ve doğrulama süresini sınırlayın. Burası saldırı yüzeyi.
Peki ne yapmalıyım
Sıraya koyalım.
- SDK'nızı güncelleyin. Python, TypeScript, Go ve C# için beta SDK'lar zaten yeni sürümü hedefliyor. SDK'yı düzenli güncelleyen ekipler için geçiş büyük ölçüde otomatik.
- Sticky routing kurallarınızı sökün. Load balancer'da
Mcp-Session-Idüzerine kurulu ne varsa gidiyor. YerineMcp-Methodüzerinden yönlendirme koyabilirsiniz. - Oturum durumunu açık tanıtıcılara çevirin. Hangi tool'lar çağrılar arası durum taşıyor, listeleyin. Her biri için bir handle üretin.
- Tasks kullanıyorsanız yeniden yazın. Tasks artık çekirdekten çıkıp uzantı oldu, yaşam döngüsü değişti,
tasks/listtamamen kaldırıldı çünkü oturum olmadan güvenli şekilde kapsamlandırılamıyor. - Yetkilendirme tarafını gözden geçirin. Altı SEP OAuth 2.0 ve OpenID Connect hizalamasını sıkılaştırdı. İstemciler artık RFC 9207 uyarınca yetkilendirme yanıtlarındaki
issparametresini doğrulamak zorunda. Yetkilendirme sunucunuzissgöndermiyorsa şimdiden göndermeye başlayın, gelecekte eksikliği reddedilecek.
Ve bir uyumluluk uyarısı
Deprecate edilen özellikler en az on iki ay çalışacak. Bu, ekosistemin tamamı için bir uyumluluk garantisi değil. 2026-07-28 kullanan sunucular eski istemcilerle çalışmayabilir, tersi de geçerli. Kurumsal bir ortamda hem eski hem yeni istemcilere hizmet veriyorsanız, bir süre iki uçlu yaşamayı planlayın.
Kırıcı değişikliklerin normal olmadığını da söyleyeyim. Bu sürümle birlikte gelen üç yönetişim SEP'i tam olarak bunu engellemek için var. Her özelliğin Active, Deprecated ve Removed aşamalarından oluşan bir yaşam döngüsü var ve deprecation ile olası kaldırma arasında en az on iki ay bulunuyor. Yeni yetenekler artık opt-in uzantı olarak çıkıp orada olgunlaşabiliyor. Bir Standards Track SEP'i, uyumluluk test paketine eşleşen bir senaryo eklenmeden Final statüsüne geçemiyor.
Yani bu geçişin acısını bir kere çekiyorsunuz. Sonrası için kurulan altyapı, transport ve yaşam döngüsü kodunu bir daha yeniden yazmak zorunda kalmamanız üzerine tasarlanmış.
Sorularınız varsa yorumlara yazın. Üretimde MCP koşturan ekiplerin geçiş deneyimlerini duymak isterim.