MCP 2026-07-28 ile Ne Değişti? Stateless Mimari ve Yeni Nesil Agent Altyapısı

MCP 2026-07-28 ile Ne Değişti? Stateless Mimari ve Yeni Nesil Agent Altyapısı 

Bir önceki “MCP (Model Context Protocol) Nedir ve Nasıl Oluşturulur?” başlıklı yazımızda MCP’nin, yapay zeka uygulamalarını harici veri kaynaklarına ve araçlara bağlayan standart bir iletişim protokolü olduğundan bahsetmiştik. MCP sayesinde bir AI uygulaması Jira, Confluence, veritabanı, dosya sistemi veya şirket içindeki özel servislere her biri için ayrı bir entegrasyon yaklaşımı geliştirmeden erişebiliyor.

MCP’nin ilk dönemindeki temel amaç oldukça netti. Modelleri dış dünyaya bağlamak için ortak bir standart oluşturmak. Ancak bir protokol gerçek projelerde kullanılmaya başladıkça, yalnızca bağlantı kurmanın yeterli olmadığı ortaya çıkıyor. Bu bağlantının binlerce kullanıcı altında ölçeklenmesi, standart load balancer ve API gateway yapılarıyla çalışması, uzun süren işlemleri yönetmesi, kurumsal kimlik sistemlerine bağlanması ve bağlantı kesildiğinde kaldığı yerden devam edebilmesi gerekiyor.

28 Temmuz 2026 tarihinde yayınlanan MCP 2026-07-28 specification sürümü tam olarak bu sorunlara odaklanıyor. MCP’nin beşinci specification sürümü olan bu güncelleme, protokolün stateful ve çift yönlü iletişim ağırlıklı yapısını stateless bir request-response modeline dönüştürüyor. Bunun yanında uzun süren işlemler, kullanıcıdan ek bilgi alma, cache yönetimi, gateway tabanlı yönlendirme ve kurumsal yetkilendirme için önemli yenilikler getiriyor.

Bu nedenle yeni sürümü yalnızca birkaç yeni MCP özelliği olarak değerlendirmemek gerekiyor. MCP 2026-07-28, protokolün deneysel entegrasyon katmanından standart web altyapıları üzerinde çalışabilecek production seviyesinde bir agent altyapısına doğru geçişini temsil ediyor.

Önceki MCP Yapısında Sorun Neydi?

MCP’nin önceki sürümlerinde client ve server arasındaki iletişim bir başlangıç süreciyle kuruluyordu. Client önce initialize isteğini gönderiyor, server desteklediği özellikleri açıklıyor, ardından client initialized bildirimiyle bağlantının hazır olduğunu belirtiyordu.

Remote MCP Server senaryolarında bu bağlantı Mcp-Session-Id üzerinden takip edilebiliyordu. Böylece server, aynı client’tan gelen çağrıların hangi oturuma ait olduğunu biliyor ve gerektiğinde bu oturuma bağlı bilgiler tutabiliyordu.

Bu yaklaşım local çalışan MCP Server’lar için çok büyük bir problem oluşturmayabilir. Örneğin geliştiricinin bilgisayarında stdio transport üzerinden çalışan bir dosya sistemi server’ında bağlantının yaşam döngüsünü takip etmek oldukça kolaydır.

Ancak aynı server’ın binlerce kullanıcı tarafından kullanılan remote bir servise dönüştüğünü düşünelim. Artık istekleri birden fazla server instance’ına dağıtmak, session bilgisini ortak bir storage üzerinde tutmak veya kullanıcıyı sürekli olarak aynı instance’a yönlendirmek gerekir.

Bu noktada sticky session, distributed cache, sürekli açık bağlantılar ve bağlantı zaman aşımı gibi klasik dağıtık sistem problemleri MCP Server geliştiricisinin sorumluluğuna giriyordu.

MCP 2026-07-28 ile initialize ve initialized mesajlarıyla gerçekleştirilen handshake süreci kaldırıldı. Bununla birlikte protokol seviyesinde kullanılan Mcp-Session-Id header’ı da kullanımdan çıkarıldı. Artık her istek ihtiyaç duyduğu protokol sürümü, client bilgisi ve desteklenen yetenekleri kendi içerisinde taşıyor.

Stateless MCP Nasıl Çalışıyor?

Yeni yapıda her MCP isteği bağımsız ve self-contained, yani kendi kendini açıklayan bir mesaj olarak gönderiliyor. Bir isteğin işlenebilmesi için server’ın daha önce aynı client ile bağlantı kurmuş veya session oluşturmuş olması gerekmiyor.

Client, kullandığı protokol sürümünü ve kendi bilgilerini isteğin _meta alanında iletiyor. Server’ın yeteneklerini önceden öğrenmek isteyen client’lar için ayrıca server/discover metodu bulunuyor. Ancak bu çağrı zorunlu değil. Client desteklediği özellikleri doğrudan yaptığı istek içerisinde belirtebiliyor.

Basitleştirilmiş bir HTTP isteği şu şekilde düşünülebilir:

POST /mcp HTTP/1.1

Content-Type: application/json

MCP-Protocol-Version: 2026-07-28

Mcp-Method: tools/call

Mcp-Name: musteri_durumu_getir

{

  "jsonrpc": "2.0",

  "id": 1,

  "method": "tools/call",

  "params": {

    "name": "musteri_durumu_getir",

    "arguments": {

      "musteriNo": "123456"

    },

    "_meta": {

      "io.modelcontextprotocol/protocolVersion": "2026-07-28",

      "io.modelcontextprotocol/clientInfo": {

        "name": "kurumsal-asistan",

        "version": "1.0.0"

      }

    }

  }

}

Buradaki önemli nokta, server’ın bu isteği işlemek için önceki mesajları veya herhangi bir transport session bilgisini bilmek zorunda olmamasıdır.

Böylece aynı MCP Server’dan birden fazla instance çalıştırdığınızda, gelen her istek sıradan bir round-robin load balancer tarafından herhangi bir instance’a yönlendirilebilir. Session bilgisini ortak bir Redis üzerinde tutmak veya kullanıcıyı aynı instance’a sabitlemek zorunda kalmazsınız.

Bu değişiklik özellikle Kubernetes, serverless platformlar ve edge altyapıları üzerinde MCP Server çalıştırmayı önemli ölçüde kolaylaştırıyor. Instance’lar ihtiyaç halinde oluşturulabilir, yük azaldığında kapatılabilir ve isteklerin hangi instance’a gittiği uygulama açısından önemini kaybeder.

Stateless Olmak Hiç State Tutulmayacağı Anlamına mı Geliyor?

Burada stateless kavramını yanlış yorumlamamak gerekiyor. Yeni MCP sürümü, uygulamaların hiçbir şekilde state tutamayacağını söylemiyor. Kaldırılan şey, state bilgisinin transport katmanındaki gizli bir session içerisinde tutulması.

Örneğin bir tool birkaç aşamadan oluşan bir süreç başlatıyorsa server bir işlem kimliği üretebilir:

{

  "islemId": "operation-8f26d1",

  "durum": "baslatildi"

}

Sonraki tool çağrılarında model veya client bu islemId değerini tekrar parametre olarak gönderir:

{

  "islemId": "operation-8f26d1"

}

Bu yaklaşımda state hâlâ server tarafında tutulabilir. Ancak hangi state üzerinde işlem yapıldığı artık gizli bir transport session’ından değil, açıkça gönderilen bir işlem kimliğinden anlaşılır.

MCP geliştiricileri de çağrılar arasında state taşınması gerektiğinde server’ın açık bir handle üretmesini ve modelin bunu sonraki tool çağrılarına parametre olarak eklemesini öneriyor. Böylece süreç hem model hem client hem de server açısından gözlemlenebilir hale geliyor.

Bu, klasik backend sistemlerinde kullandığımız job ID, workflow ID, correlation ID veya process token yapılarına oldukça benziyor.

Multi Round-Trip Requests Nedir?

Stateless mimariye geçerken çözülmesi gereken önemli sorunlardan biri, server’ın işlem sırasında client’tan veya kullanıcıdan ek bilgi istemesiydi.

Bir tool çağrısının her zaman tek adımda tamamlanması mümkün değildir. Örneğin bir sunucu oluşturma işlemi sırasında kullanıcıdan bölge seçmesi istenebilir. Bir satın alma işlemi tamamlanmadan önce kullanıcı onayı alınması gerekebilir. Modelden eksik bir parametrenin tamamlanması veya belirli bir içeriğin üretilmesi istenebilir.

Önceki yapıda server’ın client’a elicitation/create veya sampling/createMessage gibi istekler gönderebilmesi için çift yönlü iletişim kanalının açık tutulması gerekiyordu.

Yeni sürümde bunun yerine Multi Round-Trip Requests, kısaca MRTR yaklaşımı kullanılıyor. Server işlemi tamamlamak için ek bilgiye ihtiyaç duyduğunda normal sonucu döndürmek yerine input_required sonucu gönderiyor. Client gerekli bilgiyi kullanıcıdan veya modelden aldıktan sonra orijinal çağrıyı cevaplarla birlikte yeniden gerçekleştiriyor.

Örneğin bir deployment tool’u şu sonucu döndürebilir:

{

  "resultType": "input_required",

  "inputRequests": {

    "deploymentApproval": {

      "type": "confirmation",

      "message": "Production ortamına deployment başlatılsın mı?"

    }

  }

}

Client bu isteği kullanıcıya gösterir. Kullanıcı onay verdiğinde aynı tool çağrısı inputResponses alanıyla tekrar gönderilir:

{

  "name": "deployment_baslat",

  "arguments": {

    "environment": "production"

  },

  "inputResponses": {

    "deploymentApproval": {

      "approved": true

    }

  }

}

Böylece server’ın sürekli açık bir bağlantı üzerinden client’a mesaj göndermesi gerekmez. Her adım bağımsız bir request-response işlemi olarak tamamlanır.

Bu yaklaşım yalnızca altyapıyı sadeleştirmiyor. Kullanıcının hangi noktada onay verdiğini, hangi bilginin talep edildiğini ve iş akışının neden durduğunu daha görünür hale getiriyor.

Uzun Süren İşlemler İçin MCP Tasks

Birçok MCP örneğinde tool çağrısı birkaç saniye içerisinde tamamlanır. Veritabanından kayıt getirmek, bir dokümanı okumak veya basit bir API çağrısı yapmak buna örnek gösterilebilir.

Ancak gerçek agentic sistemlerde tüm işlemler bu kadar kısa sürmez. Bir CI/CD pipeline’ının tamamlanması, binlerce kaydın işlenmesi, büyük bir rapor oluşturulması, bir model eğitiminin başlatılması veya insan onayı bekleyen kurumsal bir sürecin sonuçlanması dakikalar hatta saatler sürebilir.

Bu gibi işlemlerde HTTP bağlantısını sürekli açık tutmak sağlıklı bir yöntem değildir. Client, proxy veya gateway timeout’a düşebilir. Kullanıcı uygulamayı kapatabilir ya da bağlantı geçici olarak kesilebilir.

MCP Tasks extension’ı, server’ın işlem sonucunu bekletmek yerine kalıcı bir task kimliği döndürmesini sağlıyor. Client bu kimlik üzerinden işlemin durumunu takip edebiliyor, gerekli olduğunda ek bilgi gönderebiliyor ve bağlantı kesilse bile daha sonra aynı task üzerinden devam edebiliyor.

Örneğin uzun sürecek bir log analizi çağrısının ilk cevabı şu şekilde olabilir:

{

  "resultType": "task",

  "task": {

    "taskId": "task-log-analysis-1298",

    "status": "working",

    "ttlMs": 3600000,

    "pollIntervalMs": 5000

  }

}

Client daha sonra tasks/get metodunu kullanarak işlemin durumunu kontrol eder:

{

  "jsonrpc": "2.0",

  "id": 2,

  "method": "tasks/get",

  "params": {

    "taskId": "task-log-analysis-1298"

  }

}

Task beş temel durumda bulunabilir:

working: İşlem devam ediyor.
input_required: Devam etmek için kullanıcıdan veya client’tan bilgi gerekiyor.
completed: İşlem başarıyla tamamlandı.
failed: İşlem hata ile sonuçlandı.
cancelled: İşlem iptal edildi.

Task tamamlandığında tasks/get cevabındaki result alanı, normalde tool çağrısının senkron şekilde döndüreceği nihai sonucu içeriyor. Task sırasında ek bilgi gerekiyorsa client bu bilgiyi tasks/update üzerinden gönderebiliyor. Client ayrıca tasks/cancel çağrısıyla işlemin iptal edilmesini talep edebiliyor.

Burada iptal işleminin cooperative olduğunu belirtmekte fayda var. Yani client iptal talebi gönderir ancak server’ın işlemi anında durdurabileceği garanti edilmez. Server mümkünse işlemi durdurur ve task durumunu günceller.

Tasks yapısı özellikle mevcutta asynchronous job sistemi kullanan servisler için oldukça doğal bir entegrasyon sunuyor. Arka tarafta RabbitMQ, Kafka, Hangfire, Kubernetes Job veya bir bulut sağlayıcısının job servisini kullanıyorsanız, mevcut job kimliğinizi MCP task kimliğiyle ilişkilendirebilirsiniz.

MCP Artık HTTP Altyapılarıyla Daha Doğal Çalışıyor

Stateless mimarinin bir diğer önemli sonucu, MCP trafiğinin standart web ve API altyapıları tarafından daha kolay yönetilebilmesi.

Yeni Streamable HTTP isteklerinde Mcp-Method ve Mcp-Name header’larının bulunması gerekiyor. Mcp-Method, çağrılan MCP metodunu; Mcp-Name ise ilgili tool, resource veya prompt adını belirtiyor.

Örneğin:

Mcp-Method: tools/call
Mcp-Name: production_deployment

Bu header’lar sayesinde API gateway veya Web Application Firewall, JSON request body’sini parse etmek zorunda kalmadan hangi işlemin çağrıldığını anlayabilir.

Bunun sonucunda tool bazında rate limiting uygulanabilir:

production_deployment → Kullanıcı başına dakikada 2 çağrı
log_search            → Kullanıcı başına dakikada 30 çağrı
customer_query        → Kullanıcı başına dakikada 100 çağrı

Benzer şekilde gateway seviyesinde tool bazlı authorization politikaları tanımlanabilir. Örneğin yalnızca belirli bir role sahip kullanıcıların production_deployment tool’unu çağırmasına izin verilirken diğer kullanıcılar sadece read-only tool’lara erişebilir.

Loglama ve observability tarafında da hangi MCP metodunun ve hangi tool’un ne kadar çağrıldığı doğrudan header üzerinden ölçülebilir. Bu durum MCP trafiğinin mevcut API yönetim altyapılarına daha rahat dahil edilmesini sağlıyor.

Tool ve Resource Listeleri Artık Cache Edilebiliyor

MCP client’ların server üzerindeki yetenekleri keşfetmek için kullandığı tools/list, prompts/list, resources/list ve resources/read cevapları yeni sürümde cache bilgileri taşıyabiliyor.

Server, cevap içerisinde ttlMs ile verinin ne kadar süre cache’lenebileceğini, cacheScope ile cache’in hangi kapsamda geçerli olduğunu belirtebiliyor. Ayrıca listelerin deterministik bir sıralamayla dönmesi bekleniyor.

Örnek bir cevap şu şekilde düşünülebilir:

{

  "tools": [

    {

      "name": "musteri_durumu_getir",

      "description": "Müşteri durumunu getirir."

    },

    {

      "name": "fatura_detayi_getir",

      "description": "Fatura detaylarını getirir."

    }

  ],

  "ttlMs": 3600000,

  "cacheScope": "private"

}

Bu küçük gibi görünen değişikliğin birkaç önemli sonucu var.

Öncelikle client’ın her bağlantıda veya her konuşmada aynı tool listesini tekrar tekrar çekmesi engelleniyor. Bu durum network trafiğini ve server yükünü azaltıyor.

İkinci olarak tool’ların her seferinde farklı sırayla dönmesi, modelin aldığı context’in değişmesine neden olabilir. Deterministik sıralama sayesinde tool tanımları daha stabil hale geliyor ve LLM sağlayıcılarının prompt cache mekanizmalarından daha verimli yararlanılabiliyor.

Özellikle yüzlerce tool sunan kurumsal MCP gateway sistemlerinde bu değişiklik hem gecikme hem de token maliyeti açısından önemli olabilir.

MCP Extensions Yapısı

MCP’nin yeni sürümündeki önemli mimari kararlardan biri de core protokol ile ek yeteneklerin birbirinden ayrılması.

Her özelliği MCP core içerisine eklemek, protokolün zamanla büyümesine ve karmaşık hale gelmesine neden olabilir. Bunun yerine MCP Extensions adı verilen versioned ve opt-in bir yapı oluşturuldu.

Extensions, core protokolün üzerine eklenen isteğe bağlı yeteneklerdir. Client ve server bir extension’ı kullanabilmek için ilgili özelliği desteklediklerini capability bilgileri içerisinde açıkça belirtir. Taraflardan biri extension’ı desteklemiyorsa sistem mümkün olduğunda core protokol davranışına geri döner.

Resmi extension’lar io.modelcontextprotocol prefix’iyle tanımlanıyor. Üçüncü taraflar ise isim çakışmalarını engellemek için kendi domain adlarının ters çevrilmiş halini kullanabiliyor:

io.modelcontextprotocol/tasks
com.example/custom-approval
tr.com.company/internal-audit

MCP Apps, Tasks ve kurumsal authorization mekanizmaları bu extension yaklaşımının önemli örnekleri arasında bulunuyor. MCP Apps, server’ların sohbet içerisinde form, grafik, tablo veya video oynatıcı gibi interaktif arayüzler gösterebilmesini sağlarken Tasks uzun süren işlemleri yönetiyor. Authorization extension’ları ise standart OAuth akışlarının yanında machine-to-machine ve merkezi kurumsal yetkilendirme senaryolarını destekliyor.

Extensions yapısının en önemli avantajı, MCP core protokolünün sade kalmasıdır. Her client bütün extension’ları desteklemek zorunda değildir. Örneğin yalnızca tool çağıran basit bir client, MCP Apps veya Tasks desteği sunmadan da protokole uyumlu olabilir.

Yetkilendirme Tarafında Neler Değişti?

Kurumsal MCP projelerinde en fazla geliştirme maliyeti oluşturan konuların başında authentication ve authorization geliyor.

Bir MCP Server yalnızca modelin hangi tool’u çağırabileceğini değil, ilgili kullanıcının arka taraftaki sistemde hangi verilere erişebileceğini de kontrol etmek zorunda. Kullanıcı müşteri verisi okuyabiliyor mu, production ortamında işlem yapabiliyor mu veya yalnızca kendi departmanına ait belgeleri görebiliyor mu gibi soruların cevapları model tarafından değil, güvenilir authorization katmanı tarafından verilmelidir.

MCP 2026-07-28, OAuth 2.0 ve OIDC tabanlı kurumsal kimlik sistemleriyle uyumluluğu güçlendiren değişiklikler getiriyor. Authorization server tarafından döndürülen issuer bilgisinin doğrulanması zorunlu hale getiriliyor. Client credential’larının yalnızca oluşturuldukları issuer ile kullanılmasına izin veriliyor. Böylece bir authorization server için üretilmiş credential’ın yanlışlıkla veya kötü niyetli şekilde başka bir authorization server üzerinde kullanılmasının önüne geçiliyor.

Dynamic Client Registration, yani DCR yaklaşımı da kademeli olarak Client ID Metadata Documents, kısaca CIMD lehine kullanımdan kaldırılıyor. DCR geriye dönük uyumluluk için çalışmaya devam edecek ancak gelecekteki bir MCP specification sürümünde tamamen kaldırılması planlanıyor.

Claude tarafında ise Enterprise-Managed Authorization özelliğiyle yöneticiler MCP connector yetkilendirmelerini kurumun mevcut identity provider sistemi üzerinden merkezi olarak yönetebiliyor. Kullanıcılar erişimlerini Okta veya Entra gibi sistemlerdeki mevcut grup ve rollerinden devralabiliyor. Böylece her kullanıcının connector’ları ayrı ayrı kurup yetkilendirmesi gerekmiyor.

Ancak protokolün authorization desteğinin gelişmesi, tool seviyesindeki güvenlik kontrollerinin ortadan kalktığı anlamına gelmiyor. MCP Server hâlâ her çağrıda kullanıcının yetkisini doğrulamalı, gerekli durumlarda kullanıcı onayı almalı ve model tarafından gönderilen bütün parametreleri güvenilmez input olarak kabul etmelidir.

Bazı Eski Özellikler Kullanımdan Kaldırılıyor

Büyük bir specification güncellemesi doğal olarak bazı breaking change ve deprecation kararlarını da beraberinde getiriyor.

Roots, Sampling ve Logging özellikleri deprecated olarak işaretlendi. Legacy HTTP+SSE transport da resmi olarak kullanımdan kaldırılma sürecine girdi. Bu özellikler hemen kapatılmayacak ve en az 12 ay boyunca çalışmaya devam edecek. Ancak yeni MCP implementasyonlarının deprecated özellikleri kullanmaması öneriliyor.

Sampling ve Elicitation gibi server’dan client’a doğru başlatılan işlemlerin yerini büyük ölçüde Multi Round-Trip Requests yaklaşımı alıyor. Logging konusunda ise MCP protokolüne özel bir sistem yerine OpenTelemetry ve mevcut observability altyapılarının kullanılması daha sürdürülebilir bir yaklaşım olabilir.

Yeni sürümle birlikte resmi bir deprecation politikasının tanımlanması da önemli. MCP geliştiricileri, deprecated edilen özellikler için en az 12 aylık bir geçiş süresi sunmayı taahhüt ediyor. Böylece ekipler specification değişikliklerine anlık olarak tepki vermek yerine migration süreçlerini planlayabiliyor.

Claude Tarafında MCP Nasıl Gelişiyor?

MCP açık bir protokol olsa da Anthropic, Claude ürünlerinde bu yapıyı doğrudan ürünleştirmeye devam ediyor.

MCP Apps sayesinde connector’lar yalnızca metin veya JSON sonucu döndürmekle sınırlı kalmıyor. Bir MCP Server, Claude sohbeti içerisinde interaktif formlar, grafikler, tablolar ve farklı arayüzler gösterebiliyor. Böylece kullanıcı tool’un yaptığı işlemi daha görünür şekilde takip edebiliyor ve sohbet ekranından ayrılmadan etkileşim kurabiliyor.

Connector observability özellikleri, yayınlanan connector’ların kullanımını, hata oranlarını ve gecikmelerini takip etmeyi sağlıyor. Geliştiriciler connector’ın Claude, Claude Code veya diğer Claude ürünlerindeki kullanım dağılımını inceleyebiliyor.

MCP Tunnels ise private network içerisinde çalışan MCP Server’ların public internet üzerinde bir endpoint açmadan Claude’a bağlanabilmesini amaçlıyor. Bağlantı şirket ağı içerisinden dışarı doğru kuruluyor. Böylece inbound firewall kuralı, public endpoint veya origin üzerinde IP allowlist tanımlanması gerekmiyor. Özellik şu anda research preview durumunda bulunuyor.

MCP 2026-07-28 desteği Claude ürünlerine kademeli olarak sunuluyor. Dolayısıyla yeni specification yayınlanmış olsa da kullandığınız Claude ürünü veya connector altyapısının tüm yeni özellikleri aynı anda desteklediğini varsaymamak gerekiyor. Özellikle Tasks ve diğer extension’lar hem client hem de server tarafından açıkça desteklenmelidir.

Mevcut MCP Server’lar Nasıl Güncellenmeli?

Mevcut bir MCP Server geliştiriyorsanız ilk olarak kullandığınız SDK’nın 2026-07-28 specification sürümünü destekleyip desteklemediğini kontrol etmelisiniz.

TypeScript, Python, Go ve C# Tier 1 SDK’ları yeni specification sürümünü destekleyecek şekilde güncellendi. Rust SDK desteği ise beta seviyesinde sunuluyor. Özellikle Mcp-Session-Id kullanan veya session içerisindeki state’e bağımlı çalışan projelerde migration maliyeti oluşabilir.

Migration sırasında öncelikle session içerisinde tuttuğunuz bilgileri belirlemelisiniz. Kullanıcı kimliği gibi güvenlik bilgileri authorization token veya request context üzerinden çözülmeli. İş akışı state’i ise açık bir işlem veya task kimliği üzerinden taşınmalı.

Daha sonra initialize ve initialized akışına olan bağımlılıklar kaldırılmalı. Client capability bilgileri her isteğin _meta alanından okunmalı ve gerektiğinde server/discover metodu desteklenmeli.

Streamable HTTP kullanıyorsanız Mcp-Method ve Mcp-Name header’larının doğru gönderildiğinden emin olmalısınız. API gateway, WAF ve rate limit politikalarınızı bu header’lardan yararlanacak şekilde güncelleyebilirsiniz.

Uzun süren tool çağrılarınız bulunuyorsa bunları senkron şekilde bekletmek yerine Tasks extension’a taşımayı değerlendirmelisiniz. Kullanıcıdan onay veya ek bilgi isteyen akışlarda ise server-to-client çağrılar yerine Multi Round-Trip Requests yaklaşımına geçebilirsiniz.

Son olarak deprecated edilen Roots, Sampling, Logging ve legacy HTTP+SSE kullanımlarınızı tespit edip en az 12 aylık geçiş süresi içerisinde alternatif mimariye taşımalısınız.

MCP Klasik Bir REST API’ye mi Dönüştü?

Yeni specification sonrasında akla gelebilecek sorulardan biri, MCP’nin stateless request-response yapısına geçerek klasik bir REST API’ye dönüşüp dönüşmediğidir. Burada cevap yine hayır.

MCP transport ve iletişim modeli açısından standart HTTP altyapılarına daha fazla yaklaşıyor. Ancak MCP’nin amacı hâlâ bir iş servisini insan geliştiricilerin kullanacağı endpoint’ler halinde sunmak değil, AI uygulamalarının keşfedebileceği ve kullanabileceği standart tool, resource ve prompt tanımları sağlamaktır.

REST API’de hangi endpoint’in nasıl çağrılacağını genellikle geliştirici bilir. MCP’de ise client tools/list üzerinden server yeteneklerini keşfedebilir, tool input schema’sını modele sunabilir ve model kullanıcının talebine göre hangi tool’un çağrılması gerektiğine karar verebilir.

Dolayısıyla MCP, API’lerin alternatifi olmaya çalışmıyor. Mevcut API, veritabanı ve iş servislerini AI uygulamalarına standart ve yönetilebilir bir biçimde sunan iletişim katmanı olma görevini sürdürüyor.

Stateless mimari yalnızca bu iletişim katmanının modern web altyapıları üzerinde daha güvenilir çalışmasını sağlıyor.

Kapanış

MCP’nin ilk sürümleri önemli bir problemi çözdü. Farklı yapay zeka uygulamaları ile dış sistemler arasında ortak bir iletişim standardı oluşturdu. Ancak bir protokolün yaygınlaşmasıyla birlikte yeni sorular ortaya çıktı. Binlerce kullanıcının bağlandığı bir MCP Server nasıl ölçeklenecek? Kullanıcı onayı gerektiren işlemler nasıl yönetilecek? Saatler süren bir görev bağlantı koptuğunda nasıl devam edecek? Tool katalogları her seferinde yeniden mi taşınacak? Kurumsal kimlik ve erişim politikaları sisteme nasıl dahil edilecek?

MCP 2026-07-28 bu sorulara protokol seviyesinde cevap vermeye başlıyor. Stateless core sayesinde MCP Server’lar standart load balancer, serverless ve edge altyapıları üzerinde daha kolay çalıştırılabiliyor. Multi Round-Trip Requests, sürekli açık çift yönlü bağlantılar olmadan kullanıcıdan ek bilgi veya onay alınmasını sağlıyor. Tasks, uzun süren ve bağlantı kesintilerine dayanıklı agent iş akışları oluşturuyor. Cache, header-based routing ve güçlendirilmiş authorization özellikleri ise MCP’yi kurumsal sistemlere daha doğal şekilde yaklaştırıyor.

Bence bu güncellemenin en önemli tarafı, MCP’nin yalnızca modelleri araçlara bağlayan bir protokol olmaktan çıkmaya başlamasıdır. Yeni yapı, bu bağlantıların production ortamında nasıl ölçekleneceğini, nasıl yönetileceğini ve uzun süreli agent süreçlerine nasıl dönüşeceğini de standartlaştırıyor.

Yine de MCP’nin sihirli bir değnek olmadığını unutmamak gerekiyor. Stateless bir protokol kullanmak sistemi otomatik olarak ölçeklenebilir yapmaz. OAuth desteği bulunması bütün authorization kararlarının doğru verileceği anlamına gelmez. Tasks kullanmak, arka taraftaki job altyapısının güvenilirliğini garanti etmez.

State yönetimini doğru kurgulamak, kullanıcının yetkilerini her işlemde doğrulamak, kritik aksiyonları onaya bağlamak, idempotency sağlamak ve observability altyapısını oluşturmak hâlâ biz geliştiricilerin sorumluluğunda. Fakat MCP 2026-07-28 ile artık bunları kurmak için çok daha sağlam ve web dünyasının yıllardır kullandığı prensiplere daha yakın bir temelimiz var.

Bir sonraki yazıda görüşmek üzere, sevgiler.

Kaynaklar:

• https://claude.com/blog/bringing-mcp-2026-07-28-to-claude
• https://blo​g.modelcontextprotocol.io/posts/2026-07-28/
• https://modelcontextprotocol.io/specification/2026-07-28