CometAPI ile geliştirinBirden çok model için tek bir API mi gerekiyor?İş akışını Playground'da test edin, ardından model ve maliyet kullanım senaryonuza uyduğunda bir API anahtarı oluşturun.
Özet: MCP 2026-07-28, protokol düzeyindeki oturumları ve zorunlu başlatma el sıkışmasını kaldırır. Üretim ekipleri gizli oturum bağımlılıklarını bulmalı, istek başına protokol metaverisini benimsemeli, Multi Round-Trip Requests uygulamalı, ağ geçidi ilkelerini güncellemeli ve eski davranışı sonlandırmadan önce yeni protokolü kanarya yayına almalıdır.
Model Context Protocol spesifikasyonu 28 Temmuz 2026’da yayınlandı ve uzak taşıma desteğinin eklenmesinden bu yana MCP için en büyük mimari değişikliği getiriyor.
Protokol artık durumsuz bir istek-cevap çekirdeği kullanıyor. Zorunlu initialize ve notifications/initialized alışverişi kaldırıldı, Mcp-Session-Id çıkarıldı ve her istek, işlenmesi için gereken protokol bilgisini taşıyor.
Netlik, kaynak ataması ve güncel API terminolojisi açısından gözden geçirildi.
Sürüm ayrıca Multi Round-Trip Requests, HTTP yönlendirme başlıkları, önbelleğe alınabilir liste yanıtları, daha sıkı yetkilendirme davranışı, bir uzantı çerçevesi ve resmi bir kullanım dışı bırakma yaşam döngüsü sunuyor. Protokol düzeyindeki ayrıntılar için resmi MCP 2026-07-28 sürüm duyurusu ve tam spesifikasyon değişiklik günlüğüne bakın.
Bu değişiklikler, uzak MCP sunucularını standart HTTP altyapısının arkasında ölçeklendirmeyi kolaylaştırır. Mevcut bir uygulamayı kendiliğinden durumsuz hale getirmez.
Bir üretim sunucusu hâlâ bellekte tutulan çalışma alanlarına, yapışkan yönlendirmeye, oturuma bağlı kimlik bilgilere, uzun ömürlü akışlara veya sunucu başlatımlı etkileşimlere dayanıyor olabilir. Bu kılavuz bu bağımlılıkları bulmaya ve değiştirmeye odaklanır.
Sunucu, başlatma tamamlanana kadar çağrıları reddediyor mu?
Bir oturum kimliği bir kullanıcıyı, kimlik bilgisini, çalışma alanını veya konuşmayı mı seçiyor?
Başka bir sunucu örneği, ilki tarafından başlatılan bir iş akışını sürdürebilir mi?
Yük dengeleyici oturum yapışkanlığı gerektiriyor mu?
Bir araç, onay istemeden önce yan etkiye neden oluyor mu?
Ağ geçidi yöntemi veya aracı belirlemek için gövdeyi ayrıştırıyor mu?
OAuth kimlik bilgileri, yayımlayan yetkilendirme sunucusu olmadan mı saklanıyor?
İstemci SSE yeniden bağlanmasına veya ileti yeniden teslimine bağımlı mı?
Araç veya kaynak listeleri bağlantıya göre değişiyor mu?
Hangi kullanım dışı bırakılmış özellikler hâlâ üretim trafiği alıyor?
Mcp-Session-Id’i uygulamanın arkasında ne sakladığını anlamadan kaldırmayın.
Başlığı kaldırıp durumu yerel bellekte tutmaya devam eden bir sunucu, geliştirme sırasında çalışabilir ve istekler birden fazla örneğe dağıtıldığında aralıklı olarak başarısız olabilir.
2. Gizli Oturum Durumunu Değiştirin
MCP 2026-07-28 protokol düzeyinde oturumları kaldırır, uygulama durumunu değil.
Çağrılar arasında gereken durum üç kalıptan biriyle yönetilmelidir.
Açık Tanıtıcılar
Bir araçtan sunucu tarafından üretilmiş bir tanıtıcı döndürün ve sonraki çağrılarda bunu zorunlu kılın.
Bu, bağımlılığı araç sözleşmesinde görünür kılar ve uyumlu herhangi bir sunucu örneğinin isteği işlemesine olanak tanır.
Paylaşılan Depolama
Şunlar gerekli olduğunda bir veritabanı, dağıtık önbellek, nesne deposu veya dayanıklı görev sistemi kullanın:
birden fazla işçi aynı duruma ihtiyaç duyduğunda;
iş akışının bir yeniden başlatmadan sağ çıkması gerektiğinde;
durum bir tanıtıcı için fazla büyük olduğunda;
iş akışı tek bir isteği aşan sürelerde sürdüğünde;
işlemsel veya tek kullanımlık davranış gerektiğinde.
Korumalı requestState
MRTR, istemcinin orijinal isteği yeniden denerken yansıtacağı opak bir requestState değeri döndürebilir.
Değer istemciden geçtiği için, HMAC veya kimliği doğrulanmış şifreleme ile koruyun. Gerekirse tekrar yürütmeyi önlemek için kimliği doğrulanmış özneye, orijinal işleme, önemli parametrelere, sona erme zamanına ve bir nonce’a bağlayın.
İstemci değeri değiştirmeden geri verdi diye imzasız bir requestState değerine asla güvenmeyin.
3. Kendine Yeter İstekleri ve Keşfi Benimseyin
Modern MCP istekleri, _meta içinde protokol bağlamını içerir.
Streamable HTTP bir araç çağrısı şöyle görünebilir:
Yeni protokolü hedefleyen sunucular server/discover uygulamalıdır; bu uç nokta desteklenen sürümleri, yetenekleri ve sunucu kimliğini reklam eder. İstemciler bir başka işlemden önce bunu çağırabilir veya eskiye dönüş gerekip gerekmediğini belirlemek için kullanabilir.
Yanıt sözleşmesi için resmi server/discover documentation bölümünü okuyun.
TypeScript SDK Sürüm Müzakeresi
Yalnızca TypeScript SDK’yı yükseltmek, bir istemciyi otomatik olarak yeni protokole geçirmez.
v2 SDK kullanan bir istemci açıkça tercih belirtmelidir:
Üretim düzeyinde bir MRTR uygulaması şunları tanımlamalıdır:
azami tur sayısı;
istek durumu zaman aşımı;
iptal ve reddetme davranışı;
yanıt şeması doğrulaması;
her yeniden denemede yetkilendirme kontrolleri;
tekrar yürütmeye karşı koruma;
yan etkiler için idem-potentlik;
istemcinin istenen yeteneği desteklemediği durumda davranış.
Bir satın alma, silme, kredi düşümü veya harici yazma işlemini input_required döndürmeden önce tamamlamaktan kaçının.
Yeniden denemelerin işlemi çoğaltamaması için aşamalı bir işlem veya idem-potent anahtar kullanın. Tam etkileşim modeli için resmi MRTR spesifikasyonuna bakın.
5. Ağ Geçitlerini, Önbellekleme ve Yetkilendirmeyi Güncelleyin
Altyapı değişiklikleri yakından ilişkilidir ve birlikte test edilmelidir.
MCP Yönlendirme Başlıklarını Doğrulayın
Streamable HTTP POST istekleri artık şunları içerir:
MCP-Protocol-Version
Mcp-Method
Mcp-Name
Bu başlıklar, ağ geçitlerinin her JSON gövdesini ayrıştırmadan trafiği yönlendirmesine, ölçmesine, yetkilendirmesine ve hız sınırlaması uygulamasına olanak tanır.
Şu kontrolleri destekleyebilirler:
araca özgü hız sınırları;
listeleme ve yürütme yöntemleri için farklı politikalar;
pahalı araçlar için özel işçi havuzları;
yüksek riskli işlemlere sınırlı erişim;
araç bazında gecikme ve hata metrikleri;
altyapı maliyeti atfı.
Değerler yine de istemci tarafından sağlanır. Politikayı uygulamadan önce bunları JSON-RPC gövdesiyle karşılaştırın.
Bir istek, gövdede farklı bir aracı çağırırken Mcp-Name içinde düşük riskli bir aracı iddia edememelidir. Başlık ve gövde uyuşmazlıkları reddedilmeli ve günlüğe kaydedilmelidir.
Yeni protokol, şu sonuçlara ttlMs ve cacheScope ekler:
tools/list
prompts/list
resources/list
resources/templates/list
resources/read
Bir önbellek anahtarı normalde şunları içermelidir:
protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version
TTL süresi dolmadı diye özel bir önbellek girdisini kullanıcılar veya kiracılar arasında yeniden kullanmayın.
Deterministik araç sıralaması da önemlidir. Kararlı bir katalog, gereksiz önbellek kaçırmalarını önler ve araç tanımlarının istemlere yerleştirildiği durumlarda model istem önbelleği yeniden kullanımını iyileştirebilir.
OAuth Issuer İşlemesini Güçlendirin
Yetkilendirme geçişi sırasında:
dönen bir iss değerini akış için kaydedilen issuer’a göre doğrulayın;
saklanan istemci kimlik bilgilerini issuer’a göre anahtarlandırın;
kimlik bilgilerini başka bir yetkilendirme sunucusuyla asla yeniden kullanmayın;
DCR sırasında uygun bir application_type ayarlayın;
yeni entegrasyonları Client ID Metadata Documents için hazırlayın.
Dynamic Client Registration geriye dönük uyumluluk için kullanılabilir durumda kalsa da, tercih edilen kayıt yaklaşımı olarak kullanım dışıdır.
6. Bildirimleri, Görevleri ve Kullanım Dışı Özellikleri Taşıyın
Eski HTTP GET bildirim yolu ve resources/subscribe veya resources/unsubscribe akışı subscriptions/listen ile değiştirildi.
İstemciler uzun ömürlü bir POST-yanıt akışı açar ve ihtiyaç duydukları bildirim kategorilerine katılır. İstek özelindeki ilerleme ve günlük bildirimleri, anlattıkları isteğin yanıt akışına bağlı kalır.
Çoklu örnek dağıtımlarda, bir sunucu örneğinde üretilen bildirimlerin başka bir örneğe bağlı bir aboneliğe ulaşması gerekiyorsa paylaşılan bir olay veri yolu kullanın.
Tasks Uzantısı
Uzun süren işler, deneysel çekirdek protokolden çıkarılıp şuraya taşınmıştır:
io.modelcontextprotocol/tasks
Uzantı şunları kullanır:
tasks/get için yoklama;
tasks/update için istemciden sunucuya güncellemeler;
dayanıklı görev tanıtıcıları;
katılımlı güncellemeler için subscriptions/listen.
Eski tasks/result ve tasks/list kalıpları yeni bir uygulamaya taşınmamalıdır.
Kullanım Dışı Özellikler
Aşağıdaki özellikler kullanım dışıdır:
Özellik
Önerilen yön
MCP 2026-07-28
Geçiş eylemi
Roots
Dizinleri araç argümanları, kaynak URI’leri veya yapılandırma ile iletin
Zorunlu el sıkışması yok
Modern istek başlatma kapılarını kaldırın
Sampling
Model sağlayıcı API’larıyla doğrudan entegre olun
Protokol düzeyinde oturum yok
Gerekli durumu açık hale getirin
Logging
stdio için stderr veya üretimde OpenTelemetry kullanın
İsteğe bağlı server/discover çağrısı
Keşfi ve sürüm müzakeresini uygulayın
Dynamic Client Registration
Client ID Metadata Documents’a yönelin
İstek içinde _meta
İstek başına protokol metaverisi gönderin
Eski HTTP+SSE
Streamable HTTP’ye geçin
Mcp-Method ve Mcp-Name başlıkları
Yönlendirme, politika ve gözlemlenebilirliği güncelleyin
Kullanım dışı includeContext değerleri
Alanı atlayın veya "none" kullanın
Multi Round-Trip Requests
input_required ve yeniden denemeleri yönetin
Liste önbellekleme
Kataloglar tekrarlı alınır
ttlMs, cacheScope, deterministik sıralama
Yetkilendirme farkında önbellekleme ekleyin
Bildirimler
GET akışı ve kaynak abonelikleri
subscriptions/listen
Değişiklik bildirimlerini yeni akışa taşıyın
Yetkilendirme
Kullanım dışı işlevsellik, kullanım dışı bırakma penceresi boyunca mevcut kalır; ancak yeni uygulamalar tarafından benimsenmemelidir. MCP yaşam döngüsü politikası en az on iki aylık bir kullanım dışı bırakma süresi sağlar; bu, her özelliğin aynı onaylı kaldırma tarihine sahip olduğu anlamına gelmez.
İstemcileri, sunucuları, ağ geçitlerini, önbelleğe almayı ve yetkilendirmeyi tek bir gözetimsiz sürümde değiştirmeyin.
Önerilen Geçiş Sırası
Protokol sürümleri, SDK’lar, oturumlar, SSE trafiği, DCR istemcileri ve kullanım dışı yöntemleri envanterleyin.
Üretim dışı SDK’ları yükseltin.
server/discover ve sürüm müzakeresi ekleyin.
Gizli oturum bağımlılıklarını değiştirin.
MRTR’ı uygulayın ve güvene alın.
Doğrulanmış yönlendirme başlıkları ve kapsamlı önbellekler ekleyin.
Yetkilendirme issuer sınırlarını test edin.
Modern protokolü eski yol ile birlikte kanarya olarak yayınlayın.
Telemetriyi gözden geçirdikten sonra eski davranışı emekliye ayırın.
Kanarya Sırasında Uyumluluk
Modern client + modern server
→ Use MCP 2026-07-28
Modern client + legacy server
→ Probe and fall back when supported
Legacy client + dual-version server
→ Continue on the legacy path
Unsupported combination
→ Return a clear protocol-version error
Yeni bir MCP spesifikasyonunun yayınlanması, ekosistem genelinde bir anahtar değildir. İstemciler, sunucular, SDK’lar ve barındırılan platformlar farklı hızlarda geçiş yapacaktır.
Kaydedilecek Telemetri
Sinyal
Ne gösterir
İstek başına protokol sürümü
Benimseme ve uyumsuz kombinasyonlar
Keşif başarısı ve geri dönüş oranı
Sürüm müzakere davranışı
Eksik veya geçersiz MCP başlıkları
Eski istemciler veya ağ geçidi hataları
Başlık/gövde uyuşmazlıkları
İstemci hataları veya politika atlatma girişimleri
İstenen ve tamamlanan MRTR
Etkileşimli iş akışı güvenilirliği
Reddedilen veya zaman aşımına uğrayan MRTR
Kullanıcı ve istemci başarısızlık yolları
İstek durumu doğrulama hataları
Kurcalama, tekrar yürütme veya süre aşımı
Yinelenen işlem önleme
İdem-potentlik kontrollerinin etkinliği
Kapsama göre önbellek isabet oranı
Güvenli trafik azaltımı
Issuer doğrulama hataları
OAuth yapılandırma sorunları
HTTP+SSE trafiği
Kalan taşıma geçişi çalışmaları
Kullanım dışı yöntem trafiği
Emeklilik planlaması için kanıt
Araç gecikmesi ve kabul edilen görev oranı
Kullanıcıya görünür güvenilirlik
Başarılı tek atımlık tools/call istekleri geçişi ölçmek için yeterli değildir. Tekrarlı olarak zaman aşımına uğrayan, gereksiz giriş isteyen veya harici bir yazmayı çoğaltan bir iş akışı yine bir üretim başarısızlığıdır.
CometAPI, MCP Mimarisine Nasıl Uyar?
MCP bir model API’sinin yerini almaz. Bu iki katman farklı entegrasyon sorunlarını çözer.
Katman
Birincil sorumluluk
MCP
Ajanları araçlara, kaynaklara, istemlere, onaylara ve görevlere bağlamak
Birleşik model API’si
Uygulamaları modellere, kimlik bilgilerine, kullanıma ve faturalamaya bağlamak
Uygulama orkestrasyonu
Modellerin ve araçların ne zaman ve nasıl çağrılacağına karar vermek
Tipik bir üretim mimarisi şöyle görünür:
Application or agent
↓
MCP clients and servers
Tools, resources, approvals, tasks
↓
Unified model API
GPT, Claude, Gemini, DeepSeek, and other models
MCP, ajanların araçlar ve bağlamla nasıl etkileştiğini standartlaştırır. Model fiyatlandırması, sağlayıcı kimlik bilgileri, çıkarım uç noktaları veya sağlayıcı başarısızlık toleransı gibi unsurları standartlaştırmaz.
Bu ayrım, kullanım dışı bırakılan Sampling yeteneğinden taşınırken özellikle faydalıdır. Bir MCP sunucusu veya onu tüketen ajan hâlâ model çıkarımına ihtiyaç duyuyorsa, uygulama eski MCP Sampling akışına bağımlı olmak yerine doğrudan bir model API’sini çağırabilir.
Bir Birleşik Model Geçidi Ne Zaman Yardımcı Olur?
Bir birleşik model geçidi operasyonel işi azaltabilir:
birden fazla MCP sunucusunun farklı model sağlayıcılarına erişmesi gerektiğinde;
farklı araçların farklı modellere ihtiyaç duyduğu durumlarda;
ekipler sağlayıcıya özgü entegrasyonları yeniden yazmadan model değiştirmek istediğinde;
kimlik bilgileri, kullanım ve faturalama merkezi olarak yönetilmek istendiğinde;
model erişiminin MCP taşıma değişikliklerinden bağımsız kalması gerektiğinde.
CometAPI, MCP uygulamalarının arkasındaki model erişim katmanı olarak kullanılabilecek OpenAI uyumlu bir uç nokta sağlar. Bu, model sağlayıcı mantığını MCP araçlarından, kaynaklardan ve görev orkestrasyonundan ayrı tutar.
Örneğin, bir MCP aracı, uygulamanın başka yerlerinde kullanılan aynı OpenAI uyumlu istemci üzerinden bir modeli çağırabilir:
MCP sunucusu araç sözleşmesinden, yetkilendirmeden, durumdan ve sonuç işlemeden sorumlu olmaya devam eder. Model geçidi ise model seçimini, sağlayıcı erişimini ve çıkarım yanıtlarını yönetir.
Bu katmanları ayrı tutmak iki pratik fayda sağlar:
MCP istemcileri ve sunucuları, model entegrasyon katmanını değiştirmeden yeni protokole geçebilir.
Model sağlayıcıları, MCP araçları veya taşıma davranışı yeniden tasarlanmadan değiştirilebilir.
Yeniden denemeler için yeni bir JSON-RPC kimliği kullanın.
requestState değerini koruyup geri verin.
OAuth issuer doğrulayın.
Kimlik bilgilerini issuer’a göre saklayın.
Önbellek ipuçlarına uyun.
Gerektiğinde subscriptions/listen destekleyin.
Sunucu
Modern istek başlatma kapılarını kaldırın.
Mcp-Session-Id bağımlılıklarını kaldırın.
server/discover uygulayın.
Gizli durumu tanıtıcılar veya paylaşılan depolamayla değiştirin.
resultType döndürün.
Sunucu başlatımlı istekleri MRTR ile değiştirin.
requestState koruyun.
Tüm inputResponses değerlerini doğrulayın.
Yan etkiler için idem-potentlik ekleyin.
Deterministik listeler döndürün.
Tedbirli önbellek ipuçları yayınlayın.
Uzun süren işleri Tasks uzantısına taşıyın.
Ağ Geçidi ve Altyapı
MCP istek başlıklarını doğrulayın.
Başlıkları istek gövdesiyle karşılaştırın.
Gereksiz yapışkan yönlendirmeyi kaldırın.
İstekleri birden çok örnek arasında test edin.
Önbellekleri yetkilendirme sınırına göre bölümlendirin.
Gerektiğinde paylaşılan bir bildirim veri yolu ekleyin.
Eski ve kullanım dışı trafiği izleyin.
Kanarya sırasında geri alma yolunu koruyun.
SSS
MCP 2026-07-28 nedir?
MCP 2026-07-28, 28 Temmuz 2026’da yayınlanan Model Context Protocol spesifikasyonudur. Durumsuz bir protokol çekirdeği, Multi Round-Trip Requests, HTTP yönlendirme başlıkları, önbelleğe alınabilir sonuçlar, yetkilendirme değişiklikleri, uzantılar ve resmi bir kullanım dışı bırakma yaşam döngüsü sunar.
Mcp-Session-Id kaldırıldı mı?
Evet. Yeni Streamable HTTP protokolü artık Mcp-Session-Id kullanmıyor.
Uygulamalar hâlâ açık tanıtıcılar, paylaşılan depolama, dayanıklı görevler veya korumalı istek durumu değerleriyle durumu koruyabilir.
MCP başlatma el sıkışması kaldırıldı mı?
Evet. Modern istekler artık initialize ve notifications/initialized alışverişini gerektirmiyor.
Sunucular server/discover uygulamak zorundadır; ancak istemcilerin her işlemden önce bunu çağırması gerekmez.
Durumsuz MCP, araçların durum koruyamayacağı anlamına mı gelir?
Hayır. Durumsuzluk protokol katmanına işaret eder.
Bir araç hâlâ durum saklayabilir, ancak istek işlemesi gizli taşıma yakınlığına veya tek bir sunucu sürecine bağlı olmamalıdır.
MRTR nedir?
Multi Round-Trip Requests, sunucunun sürekli açık çift yönlü bir bağlantı üzerinden sunucu başlatımlı bir istek göndermeden ek istemci veya kullanıcı girdisi talep etmesine olanak tanır.
Sunucu input_required döndürür ve istemci istenen yanıtlarla orijinal işlemi yeniden dener.
HTTP+SSE hemen kaldırılıyor mu?
Hayır. Hemen kaldırılmak yerine kullanım dışı bırakılmıştır.
Yeni sunucular Streamable HTTP kullanmalı, mevcut sistemler kalan HTTP+SSE trafiğini ölçmeli ve taşınmalıdır.
TypeScript SDK v2 istemcileri MCP 2026-07-28’i otomatik olarak kullanır mı?
Hayır. TypeScript v2 SDK, modern protokolü kullanmak için açık bir sürüm müzakeresi yapılandırması gerektirir.
İstemcinin hem modern hem de eski sunucularla çalışması gerektiğinde otomatik müzakereyi kullanın.
Son Öneriler
MCP 2026-07-28, uzak MCP altyapısını ölçeklendirmeyi, yönlendirmeyi, önbelleğe almayı ve gözlemlenmeyi kolaylaştırır. Ana geçiş riski sadece bir başlığın veya el sıkışmasının kaldırılması değildir. Hâlâ onlara bağlı olabilecek gizli uygulama durumu ve etkileşim mantığıdır.
Yeni protokolü dağıtmadan önce:
Başlatma ve Mcp-Session-Id bağımlılıklarının tümünü bulun.
Gerekli durumu açık tanıtıcılara veya paylaşılan depolamaya taşıyın.
MRTR’ı son kullanma, tekrar yürütme koruması ve idem-potentlikle uygulayın.
MCP başlıklarını JSON-RPC gövdesine karşı doğrulayın.
Önbellekleri kiracı ve yetkilendirme kapsamına göre bölümlendirin.
OAuth issuer doğrulamasını sertleştirin.
Kullanım dışı yöntemleri ve eski taşıma trafiğini ölçün.
Modern ve eski protokol yollarını emeklilikten önce kanarya olarak yayınlayın.
Geçişi, rutin bir SDK yükseltmesi yerine bir altyapı değişikliği olarak ele alın.
MCP katmanı durumsuz ve gözlemlenebilir hale geldikten sonra, model erişimini ayrı bir arayüzün arkasında tutun. Bu, araç protokolünün ve model sağlayıcı katmanının birbirinden bağımsız evrilmesine olanak tanır.
OAuth istemcilerini ve kimlik bilgisi depolamayı denetleyin
Uzun süren işler
Çekirdekte deneysel Tasks
io.modelcontextprotocol/tasks uzantısı
Uzantı sözleşmesine geçin
Eski özellikler
Roots, Sampling, Logging, HTTP+SSE
Kullanım dışı
Yeni benimsemeyi durdurun ve mevcut kullanımı ölçün
DCR merkezli kayıt
Daha güçlü issuer kuralları ve CIMD yönelimi
OAuth istemcilerini ve kimlik bilgisi depolamayı denetleyin
Uzun süren işler
Çekirdekte deneysel Tasks
io.modelcontextprotocol/tasks uzantısı
Uzantı sözleşmesine geçin
Eski özellikler
Roots, Sampling, Logging, HTTP+SSE
Kullanım dışı
Yeni benimsemeyi durdurun ve mevcut kullanımı ölçün
