Rehberler

Yazan Matt Connor 2026-08-07 · Güncellendi 2026-08-28

Stateless MCP sunucusu nedir ve neler değişti?

Q: Yük dengeleyicimde hala sticky session (kalıcı oturum) kullanmam gerekiyor mu?

Normal istekler için gerekmez. 2026-07-28 revizyonu kapsamında her POST isteği kendi protokol sürümünü, yeteneklerini ve kimlik bilgilerini taşır; bu nedenle herhangi bir kopya (replica) herhangi bir isteği yanıtlayabilir ve round-robin yöntemi uygundur. Uzun ömürlü kalan tek şey, tek bir işleme açılan tek bir bağlantı olan subscriptions/listen yanıt akışıdır. Bu akış, ilgili işlem sona erdiğinde biter ve istemci yeniden kurmak için subscriptions/listen gönderir. Bu, oturum yakınlığından ziyade bağlantı ömrüdür ve hiçbir yönlendirme kuralı bunu engelleyemez.

Q: Mcp-Session-Id ve HTTP GET akışına ne oldu?

Her ikisi de SEP-2567 ve SEP-2575 kapsamında 2026-07-28 revizyonunda kaldırıldı. Yalnızca bu revizyonu uygulayan bir sunucu, MCP uç noktasında 405 Method Not Allowed ile GET ve DELETE isteklerine yanıt vermeli ve bir Mcp-Session-Id başlığını geri yansıtmak yerine görmezden gelmelidir. Sunucu tarafından başlatılan değişiklik bildirimleri artık bağımsız bir GET akışı yerine, bir subscriptions/listen isteğinin yanıt akışı üzerinden iletilir. Eski istemcilere hizmet vermeye devam etmesi gereken sunucular, önceki revizyonun davranışını bu revizyonla birlikte uygulamalıdır.

MCP 2026-07-28 revizyonu ile oturumlar ve initialize el sıkışması kaldırıldı. Reverse proxy, sağlık kontrolleri, zaman aşımları ve kimlik doğrulama süreçlerindeki etkileri inceleyin.

Stateless bir MCP sunucusu nedir

Stateless (durumsuz) bir MCP sunucusu, istekler arasında istemciye özel hiçbir durum bilgisi tutmaz. Her istek; protokol sürümünü, istemci yeteneklerini ve sunucunun yanıt vermesi için gereken kimlik bilgilerini taşır; bu sayede herhangi bir makinedeki herhangi bir süreç, herhangi bir isteği yanıtlayabilir. MCP (araçlara ulaşmak için aracıların kullandığı kablo formatı olan Model Context Protocol), 2026-07-28 revizyonunda bunu bir kural haline getirmiş ve altında yatan initialize el sıkışması ile HTTP oturumunu kaldırmıştır. Buradaki her şey, bu kablonun sunucu tarafı ile ilgilidir; bu nedenle aracı tarafı sizin için hala yeniyse, yapay zeka aracılarını öğrenmek için aşamalı bir yol, bu HTTP detayları önem kazanmadan önce bir aracı çağırmaya karar veren döngüyü kapsar.

Operasyonel açıdan tüm mesele budur. İstemci başına hiçbir şey tutmayan bir sunucu, oturum bağımlılığı (session affinity) gerektirmeyen sıradan bir yük dengeleyicinin arkasında durabilir, dağıtım sırasında istemcileri kesintiye uğratmadan yeniden başlatılabilir ve tek bir süreç yerine dört özdeş süreç olarak çalışabilir. Oturum odaklı bir sunucu, ek mekanizmalar olmadan bunların hiçbirini yapamaz.

Model Context Protocol, stateless bir protokoldür: bir isteği işlemek için gereken tüm bilgiler isteğin kendi içinde bulunur. Bir sunucu her isteği bağımsız olarak işler; aynı bağlantı veya akış üzerindekiler dahil olmak üzere önceki isteklerden hiçbir durum çıkarımı yapılmamalıdır.

Stateless, sunucunuzun hiçbir veri saklamadığı anlamına gelmez. Veritabanınız, kuyruğunuz ve cache'iniz yine yerindedir. Buradaki anlam, protokolün bağlantı üzerinde durum bilgisi taşımamasıdır. Bu nedenle sunucu, bir bağlantıyı, süreci veya açık bir socket'i "bu istemci, görüşmenin ortasında" durumunun karşılığı olarak görmemelidir. Bu ayrım, verilerinin sahibi olan bir uygulamada daha kolay görülür: openGym'in salt okunur MCP sunucusu, uygulamanın kendi veritabanında bulunan antrenman geçmişiyle ilgili soruları yanıtlar. Bu verilerin saklanması, belirli bir isteğin hangi bağlantı üzerinden geldiğine bağlı değildir.

2026-07-28 revizyonunda nelerin kaldırıldığı

2026-07-28, Ağustos 2026 itibarıyla spesifikasyonun güncel revizyonudur. 2025-11-25 ile karşılaştırıldığında, oturumları desteklemek için var olan beş özellik kaldırılmıştır.

initialize isteği ve notifications/initialized bildirimi. Artık herhangi bir el sıkışma (handshake) süreci bulunmamaktadır (SEP-2575).
Mcp-Session-Id başlığı ve HTTP DELETE ile oturum sonlandırma (SEP-2567).
Sunucuların bildirimleri gönderdiği bağımsız HTTP GET akışı. Bu yapı, yanıtı uzun ömürlü bir akış olan standart bir POST isteği olan subscriptions/listen ile değiştirilmiştir.
SSE (server-sent events) akış devam ettirilebilirliği. Last-Event-ID başlığı ve olay bazlı kimlikler kaldırılmıştır; bu nedenle kesilen bir akış, o an işlenmekte olan isteği kaybeder ve istemci bunu yeni bir istek kimliğiyle yeni bir istek olarak tekrar göndermelidir.
ping, logging/setLevel ve notifications/roots/list_changed. Günlük seviyesi artık _meta içindeki io.modelcontextprotocol/logLevel alanında, istek bazlı olarak tanımlanmaktadır.

Bir yöntem eklenmiştir ve her sunucunun bunu uygulaması zorunludur. server/discover, sunucunun desteklediği protokol sürümlerini, yeteneklerini ve kimliğini tek bir çağrıda döndürür. Bu, geriye kalan el sıkışma işlemine en yakın yapıdır ve istemciler için çağrılması isteğe bağlıdır.

Oturum taşıma mekanizmasının üretim ortamında çalıştırılmasının zorlukları

2025-11-25 ve önceki sürümlerde, bir sunucu başlatılma sırasında bir oturum kimliği oluşturabilir ve bunu InitializeResult üzerindeki Mcp-Session-Id başlığında döndürebilirdi. İstemcinin daha sonraki her istekte bu başlığı göndermesi gerekiyordu. Müzakere edilen protokol sürümü ve istemcinin yetenekleri, sunucunun belleğinde bu kimlik ile anahtarlanmış şekilde tutulurdu. Bu seçimlerin her birinin operasyonel bir maliyeti vardı.

Yeniden başlatma işlemi oturum tablosunu silerdi. Spesifikasyon, sunucunun geçersiz bir oturum kimliği taşıyan her isteğe 404 Not Found ile yanıt vermesini ve istemcinin yeni bir InitializeRequest ile baştan başlamasını zorunlu kılıyordu. Her dağıtım, bağlı olan tüm istemciler için bir yeniden bağlanma olayına dönüşüyordu.
İkinci bir kopya, ilk kopyanın oturumlarını bilmiyordu. Ölçeklendirme yapmak, yük dengeleyicide yapışkan yönlendirme (sticky routing) veya her kopyanın her istekte okuduğu paylaşımlı bir oturum deposu gerektiriyordu.
Oturum tablosu, boşta bekleyen istemcilerle birlikte büyüyen bir bellek alanıydı. DELETE kullanımı isteğe bağlıydı ve bunu göndermeden bağlantıyı kapatan istemciler, sunucuda kalıntı kayıtlar bırakıyordu.
Liste sonuçları bağlantıya göre değişebildiği için, sunucunun önünde önbellekleme yapmak güvenli değildi.

Oturumların kaldırılması, bu dört sorunu aynı anda ortadan kaldırır. Herhangi bir yapılandırmaya dokunmadan önce anlaşılması gereken değişiklik budur.

Her isteğin taşıdığı veriler

MCP uç noktasına yapılan her POST isteği bağımsızdır. Protokol sürümü ve istemci yetenekleri, istek gövdesinde _meta altında taşınır; seçili alanlar ise HTTP başlıklarına yansıtılır. Bu sayede bir aracı, JSON ayrıştırması yapmadan yönlendirme gerçekleştirebilir.

POST /mcp HTTP/1.1
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather
Authorization: Bearer <access token>

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {"location": "Seattle, WA"},
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {"name": "ExampleClient", "version": "1.0.0"},
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

io.modelcontextprotocol/protocolVersion ve io.modelcontextprotocol/clientCapabilities her istekte zorunludur. clientInfo zorunlu değildir ancak istemcilerin bunu göndermesi önerilir. Zorunlu bir alanı eksik olan istek hatalı yapılandırılmış sayılır; bu durumda sunucu, isteği JSON-RPC hatası -32602 ve HTTP 400 Bad Request kodu ile reddetmelidir.

Mcp-Method başlığı her istekte zorunludur. Mcp-Name; tools/call, resources/read ve prompts/get üzerinde zorunludur. Başlık değeri gövde ile eşleşmelidir. Gövdeyi işleyen bir sunucu, uyumsuzluk durumunda isteği 400 Bad Request ve -32020 hata kodu HeaderMismatch ile reddetmelidir. Bu kuralın varlık nedeni, başlığa göre yönlendirme yapan bir yük dengeleyici ile gövdeyi işleyen sunucunun iki farklı doğruluk kaynağı olmasıdır. Bu başlıklar üzerinden yönlendirme veya hız sınırlaması (rate-limiting) yapıyorsanız, önce MCP-Protocol-Version değerini kontrol edin: önceki revizyonlar başlık ile gövdeyi doğrulamıyordu, bu nedenle o sürümlerde başlık değeri güvenilir değildir.

Sürüm uyuşmazlığı artık başarısız bir el sıkışma değil, isteğe bağlı olağan bir hatadır. İstenen sürümü uygulamayan bir sunucu, 400 Bad Request ve -32022 hata kodu UnsupportedProtocolVersion ile yanıt verir ve desteklediği sürümleri data.supported içinde listeler. İstemci, bu listeden birini seçerek isteği tekrar eder.

Durum bilgisi nereye gitti: belirteçler, imleçler, abonelikler

Durum bilgisi kaybolmadı. Görebileceğiniz ve günlükleyebileceğiniz yerlere taşındı.

Kimlik bilgileri her isteğin içine taşınır. Kimliği ilişkilendirecek bir oturum bulunmadığından, erişim belirteci (access token) her HTTP çağrısında iletilir ve her seferinde doğrulanır. Ayrıntılar aşağıdaki kimlik doğrulama bölümündedir.

İmleçler kendi konumlarını taşımak zorundadır. tools/list, resources/list, prompts/list ve resources/templates/list üzerindeki sayfalama işlemi, opak bir imleç dizisi kullanır; istemciler bu diziyi ayrıştırmamalı veya değiştirmemelidir. Tek süreçli bir sunucuda, ofset değerini oturum bazlı olarak bellekte tutmak yaygındı. Oturum olmadığında, imlecin herhangi bir replikanın listelemeye devam edebilmesi için yeterli olması gerekir; bu nedenle konumu imlecin içine kodlayıp imzalayın ya da tüm replikaların paylaştığı bir depolama alanında tutun. Geçersiz bir imleç -32602 hatası döndürmelidir. İmleci imzalayın, çünkü opak bir imleç yine de istemci tarafından sağlanan ve kodunuzun çözüp güvendiği bir girdidir.

Abonelikler bir bağlantıya değil, bir isteğe aittir. Değişiklik bildirimleri isteyen bir istemci, istediği türleri belirten bir filtre ile subscriptions/listen gönderir: toolsListChanged, promptsListChanged, resourcesListChanged ve resourceSubscriptions. Sunucu notifications/subscriptions/acknowledged ile yanıt verir ve bu yanıt akışını açık tutar. Akış kesilirse sunucu hiçbir şeyi saklamaz ve istemci geri almak için subscriptions/listen isteğini yeniden gönderir.

Çağrılar arası uygulama durumu, açık bir tanıtıcıya (handle) dönüşür. Bir sunucunun çağrılar arasında gerçekten bir şeyi hatırlaması gerektiğinde, şartnamenin çözümü, sunucu tarafından oluşturulan ve sıradan bir araç argümanı olarak geri iletilen bir tanımlayıcıdır. Bu tanımlayıcı araç şemasında görünür, günlük kaydına alınabilir ve hiçbir zaman bağlantı tarafından örtük olarak varsayılmaz. kendi kendine barındırılan bir MCP e-posta sunucusu gibi arkasında gerçek kullanıcı verisi bulunan bir sunucu, oturum yerine bu modeli kullanır: posta kutusu veya taslak tanımlayıcısı bir araç argümanıdır, bu sayede herhangi bir replika bir sonraki çağrıyı devralabilir. Birçok araç hiçbir tanıtıcıya ihtiyaç duymaz: kendi SearXNG örneğiniz tarafından desteklenen bir arama aracı, bir sorgu alır ve sonuçları geri verir; bir sonraki çağrının devam ettireceği bir durum yoktur ve hangi replikanın yanıt verdiğinin bir önemi yoktur.

Dağıtım: reverse proxy, zaman aşımları, sağlık kontrolleri

MCP uç noktası, POST isteklerini kabul eden tek bir yoldur. Trafiğin çoğu kısa bir istek ve JSON yanıtından oluşur; bu da herhangi bir proxy tarafından kolayca yönetilir. İstisna durum ise streaming yanıtlarıdır; burada proxy varsayılanları sizin aleyhinize çalışır. Dizüstü bilgisayardaki bir demodan bir VPS üzerinde çalışan MCP sunucusuna geçtiğinizde değişen kısım budur.

location /mcp {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_buffering off;
    proxy_read_timeout 1h;
    proxy_send_timeout 1h;
}

proxy_buffering off önemlidir çünkü nginx, proxied yanıtları varsayılan olarak arabelleğe alır; bu da SSE olaylarını bir arabellek dolana veya yanıt bitene kadar tutar. Spesifikasyon ayrıca sunucuların SSE yanıtlarında X-Accel-Buffering: no göndermesini ister ve nginx bu başlığa riayet eder; dolayısıyla doğru yapılandırılmış bir sunucu, proxy'nize ne yapması gerektiğini kendisi bildirir. Yine de bu direktifi ayarlayın, çünkü kontrol edebileceğiniz kısım budur.

proxy_read_timeout varsayılan olarak 60 saniyedir. Bu süreden daha uzun süre sessiz kalan bir subscriptions/listen akışı, sunucunuz tarafından değil, nginx tarafından kapatılır. Bu durumda loglarınızda sağlıklı bir süreç görürken, istemci tarafında kopmuş bir akışla karşılaşırsınız. Bu ayarı tüm sunucu için değil, yalnızca MCP konumu için artırın. Sunucuların ayrıca sessiz dönemlerde keep-alive olarak bir SSE yorum satırı (iki nokta üst üste ile başlayan bir satır) göndermesi önerilir; bu, aracıların akışı zaman aşımına uğratmasını engeller.

Caddy daha az yapılandırma gerektirir. Ağ verimliliği için varsayılan olarak kısmi arabelleğe alma yapar ve yanıt Content-Type: text/event-stream içerdiğinde hemen boşaltır; bu nedenle streaming ek direktifler olmadan çalışır.

mcp.example.com {
	reverse_proxy 127.0.0.1:8080 {
		health_uri /healthz
		health_interval 10s
	}
}

Sağlık kontrolünün nereye işaret ettiğine dikkat edin. Aktif bir kontrolü GET ile MCP uç noktasına yönlendirmeyin; çünkü yalnızca bu revizyonu uygulayan bir sunucu, GET ve DELETE isteklerine 405 Method Not Allowed yanıtı verir ve Caddy'nin varsayılan sağlık kontrolü yöntemi GET'dir. Bu durumda proxy, tamamen sağlıklı bir backend'i devre dışı olarak işaretler. Proxy için /healthz gibi düz bir yol sunun ve protokolü ayrı bir POST isteği ile kontrol edin.

curl -sS https://mcp.example.com/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: server/discover' \
  -d '{"jsonrpc":"2.0","id":"health-1","method":"server/discover","params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientCapabilities":{}}}}'

supportedVersions listesi içeren bir 200, sürecin ayakta olduğunu ve protokolü konuştuğunu gösterir. JSON-RPC hatası -32601 içeren bir 404, sürecin ayakta olduğunu ancak her 2026-07-28 sunucusunun uygulaması gereken server/discover özelliğini sunmadığını belirtir. -32022 içeren bir 400, kontrolcünüzün bu derlemenin desteklemediği bir sürümü istediği anlamına gelir; bu, bağımlılık yükseltmesinden sonra yakalamak istediğiniz durumun ta kendisidir. Açık kaynak nginx aktif sağlık kontrollerine sahip değildir; bu nedenle upstream üzerinde pasif max_fails ve fail_timeout kullanın ve protokol kontrolünü izleme sisteminiz üzerinden gerçekleştirin.

Kademeli yeniden başlatma (rolling restart) artık size yalnızca o an devam eden isteklerin kaybına mal olur. Süreci boşaltın, açık POST isteklerinin bitmesini bekleyin, yeni süreci başlatın; istemciler başarısız olan istekleri tekrar gönderecektir. Kaybettiğiniz tek şey açık subscriptions/listen akışlarıdır, çünkü bu akış belirli bir sürece bağlı canlı bir bağlantıdır. Durumsuzluk (statelessness) oturum yakınlığını ortadan kaldırmıştır ancak o an açık olan bir akış için bağlantı yakınlığını kaldırmamıştır ve hiçbir yönlendirme kuralı bunu düzeltemez. Bir istemci aradaki farkı anlayabilir: boş subscriptions/listen sonucuyla biten bir akış düzgün bir şekilde kapanmıştır, bu sonuç olmadan biten bir akış ise kopmuştur; istemci bunu yeniden bağlanmak için bir neden olarak değerlendirebilir.

Önbellekleme ilk kez mümkün hale gelir. Liste yöntemlerinden gelen sonuçlar artık ttlMs ve cacheScope taşır; cacheScope: "public" ise paylaşılan aracılara yanıtı önbelleğe alabileceklerini bildirir. Bu durum yalnızca liste sonuçlarının bağlantı başına değişmemesi nedeniyle güvenlidir; bu da oturumların kaldırılmasının doğrudan bir sonucudur.

Oturum olmadığında kimlik doğrulamanın neden değiştiği

Oturum varken, initialize üzerinde bir kez kimlik doğrulaması yapıp oturum kimliğini (session ID) sonraki her şey için bir kanıt olarak kullanmak cazipti. Bu şekilde kullanılan bir oturum kimliği; hedef kitlesi, son kullanma tarihi ve iptal yolu olmayan, kendi sunucunuz tarafından oluşturulmuş bir taşıyıcı (bearer) kimlik bilgisidir. Oturumların kaldırılması bu kestirme yolu ortadan kaldırır ve yerine daha katı bir yöntem getirir.

Korunan bir MCP sunucusu, bir OAuth 2.1 kaynak sunucusu gibi davranır. İstemciden gelen her HTTP isteği Authorization: Bearer <access token> taşımalıdır ve sunucu, her istekte bu belirteci (token) doğrular. Doğrulama işlemi hedef kitleyi de kapsar: Sunucu, RFC 8707 (OAuth 2.0 için Kaynak Göstergeleri) uyarınca belirtecin özellikle kendisi için verildiğini doğrulamalı; başka bir amaçla oluşturulmuş belirteçleri kabul etmemeli veya iletmemelidir. İstemciler, sunucunun kanonik URI'si ile resource parametresini göndererek doğru hedef kitleyi talep ederler.

Keşif süreci bir sınama (challenge) üzerinden yürütülür. Kullanılabilir bir belirteç içermeyen bir istek geldiğinde, sunucu 401 Unauthorized ile yanıt verir.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

İstemci resource_metadata değerini okur, ilgili belgeyi (MCP sunucularının uygulaması gereken RFC 9728, OAuth 2.0 Korumalı Kaynak Meta Verileri) getirir, yetkilendirme sunucusunu bulur ve akışı başlatır. Yetersiz izinlere sahip geçerli bir belirteç, error="insufficient_scope" ve o işlem için gerekli kapsamlarla (scopes) birlikte 403 Forbidden yanıtını alır.

Bunu nasıl çalıştırdığınızla ilgili iki sonuç ortaya çıkar. Belirteç doğrulaması artık oturum başına bir kez değil, her istekte gerçekleşir; bu nedenle her çağrı için bir iç gözlem (introspection) uç noktasına yapılan ağ gidiş-dönüşü gecikme sürenize yansıyacaktır. Bir imza, hedef kitle ve son kullanma tarihine göre yerel olarak doğrulayabileceğiniz belirteçleri tercih edin veya doğrulama sonucunu belirteç anahtarıyla kısa bir süre için önbelleğe alın. Kimliği tutan bir oturum olmadığından, yetkilendirme her çağrıda belirteç üzerinden hesaplanmalıdır. Bu, oturum modelinden daha şeffaf bir yöntemdir ve kimlik bilgilerini aracı (agent) sürecinin dışında tutma uygulamasıyla uyumludur; bu konu yapay zeka aracında sırları saklama bölümünde ele alınmıştır. Kapsamlar, yalnızca istek size ulaştığında bir belirtecin neler yapabileceğini kısıtlar; aracın çalıştığı makinede ise araç izin kuralları ve bütçe sınırları ekleyen eklentilerden yararlanma yöntemi, hangi çağrıların yapılması gerektiğine karar verir.

Bu revizyon hakkında neyin doğru, neyin yanlış olduğu

Yukarıdaki her şey 2026-07-28 revizyonunu tanımlar. Bu, MCP'nin tamamını veya geçen yıl dağıttığınız sunucuyu tanımlamaz.

2025-11-25 ve önceki sürümlerdeki istemciler ve sunucular hala el sıkışma (handshake) modelini kullanır. Teknik şartname bu revizyonları eski (legacy), istek bazlı meta veri revizyonlarını ise modern olarak adlandırır. Yalnızca bu revizyonu destekleyen bir sunucu, eski bir istemciyle karşılaştığında MCP uç noktasında 405 Method Not Allowed ile GET veya DELETE yanıtını vermeli, Mcp-Session-Id başlığını oluşturmadan veya yansıtmadan görmezden gelmeli ve akışlar devam ettirilemediği için Last-Event-ID değerini dikkate almamalıdır. Çift dönemli bir sunucu, her ikisine de tek bir uç noktadan hizmet verebilir: modern _meta taşıyan bir istek durumsuz (stateless) olarak işlenir ve bir initialize isteği, eski oturum semantiğini seçer.

Bu nedenle, buradaki bilgilere güvenmeden önce revizyon dizisini kontrol edin. SDK'nız hala initialize gönderiyorsa, oturumlar dağıtımınız için hala geçerlidir ve yukarıda belirtilen oturum kaynaklı sorunlar sizin sorumluluğunuzdadır. Aynı durum istemci tarafı için de geçerlidir: bir VPS üzerinde kodlama ajanı çalıştırma kurulumunda olduğu gibi, kendi makinenizdeki bir aracı süreci, yalnızca kullandığı kütüphane modern bir revizyonla konuşuyorsa bu anlamda durumsuzdur. Çalışma zamanınızın (runtime) müzakere ettiği sürümü okuyun, ardından şartnamenin ilgili revizyonunu inceleyin ve bu sayfayı protokolün genelini değil, yalnızca isimlendirilmiş bir revizyonu tanımlayan bir kaynak olarak kabul edin.

FAQ

Stateless bir MCP sunucusu hiçbir şeyi depolayamayacağım anlamına mı gelir?

Hayır. Stateless (durumsuz) ifadesi uygulamanızı değil, protokolü tanımlar. Veritabanları, kuyruklar ve önbellekler tam olarak eskisi gibi çalışır. Değişen şey, birden fazla çağrıya yayılan durumun, istemcinin her istekte ilettiği açık bir tanımlayıcı (örneğin bir araç argümanında sunucu tarafından oluşturulan bir tanıtıcı) ile referans gösterilmesi gerekliliğidir. Bağlantı üzerinden bağlam çıkarımı yapamazsınız: şartname, bir sunucunun yetenekleri, protokol sürümünü veya istemci kimliğini belirlemek için aynı bağlantı üzerinden önceki isteklere güvenmemesi gerektiğini belirtir; çünkü her istek bunları _meta içinde sağlar.

Yük dengeleyicimde hala sticky session (kalıcı oturum) kullanmam gerekiyor mu?

Normal istekler için gerekmez. 2026-07-28 revizyonu kapsamında her POST isteği kendi protokol sürümünü, yeteneklerini ve kimlik bilgilerini taşır; bu nedenle herhangi bir kopya (replica) herhangi bir isteği yanıtlayabilir ve round-robin yöntemi uygundur. Uzun ömürlü kalan tek şey, tek bir işleme açılan tek bir bağlantı olan subscriptions/listen yanıt akışıdır. Bu akış, ilgili işlem sona erdiğinde biter ve istemci yeniden kurmak için subscriptions/listen gönderir. Bu, oturum yakınlığından ziyade bağlantı ömrüdür ve hiçbir yönlendirme kuralı bunu engelleyemez.

Mcp-Session-Id ve HTTP GET akışına ne oldu?

Her ikisi de SEP-2567 ve SEP-2575 kapsamında 2026-07-28 revizyonunda kaldırıldı. Yalnızca bu revizyonu uygulayan bir sunucu, MCP uç noktasında 405 Method Not Allowed ile GET ve DELETE isteklerine yanıt vermeli ve bir Mcp-Session-Id başlığını geri yansıtmak yerine görmezden gelmelidir. Sunucu tarafından başlatılan değişiklik bildirimleri artık bağımsız bir GET akışı yerine, bir subscriptions/listen isteğinin yanıt akışı üzerinden iletilir. Eski istemcilere hizmet vermeye devam etmesi gereken sunucular, önceki revizyonun davranışını bu revizyonla birlikte uygulamalıdır.

El sıkışması (handshake) olmayan bir MCP sunucusunun sağlık kontrolünü nasıl yaparım?

İki seviyeli bir yöntem kullanın. Proxy'nin aktif kontrolünü uygulamanızın sunduğu düz bir HTTP yoluna yönlendirin; çünkü MCP uç noktasına yapılan bir GET isteği doğru bir şekilde 405 döndürür ve sağlıklı bir arka ucu (backend) devre dışı olarak işaretleyebilir. Ardından, her 2026-07-28 sunucusunun uygulaması gereken server/discover isteğini POST ederek protokolün kendisini kontrol edin ve yanıtın HTTP 200 olduğunu ve istemcilerinizin kullandığı bir protokol sürümünü listelediğini doğrulayın. JSON-RPC hatası -32601 içeren bir 404, sürecin çalıştığını ancak bu yöntemi sunmadığını; -32022 içeren bir 400 ise talep ettiğiniz sürümün o derleme tarafından desteklenmediğini gösterir.

#mcp #ai-agents #self-hosting#protocol#http