MCP 2026-07-28 Geçiş Kılavuzu: Durumsuz Sunucular

Ö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.

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.

Daha giriş niteliğinde bir uygulama yürütmesi için, geçişe başlamadan önce How to Create an MCP Server for Claude Code yazısını okuyun.

Kimler Geçiş Yapmalı?

Gereken çaba düzeyi, sisteminizde MCP’nin nasıl kullanıldığına bağlıdır.

İstekler arasında durum korumayan yerel bir sunucu, yalnızca bir SDK yükseltmesi ve uyumluluk testi gerektirebilir.

Oturumlar, OAuth, akış veya sunucu başlatımlı istekler kullanan uzak bir dağıtım, aşamalı bir geçiş gerektirir.

MCP 2026-07-28’te Neler Değişti?

1. Mevcut Uygulamayı Denetleyin

Yükseltmeden önce, istemci, sunucu, ağ geçidi ve dağıtım yapılandırmanızda eski protokol varsayımlarını arayın.

Mcp-Session-Id
initialize
notifications/initialized
sessionId
ctx.sessionId
extra.sessionId
sticky_session
sticky-session
elicitation/create
sampling/createMessage
roots/list
resources/subscribe
resources/unsubscribe
logging/setLevel
tasks/result
tasks/list
Last-Event-ID

Ardından şu soruları yanıtlayın:

1. Sunucu, başlatma tamamlanana kadar çağrıları reddediyor mu?
2. Bir oturum kimliği bir kullanıcıyı, kimlik bilgisini, çalışma alanını veya konuşmayı mı seçiyor?
3. Başka bir sunucu örneği, ilki tarafından başlatılan bir iş akışını sürdürebilir mi?
4. Yük dengeleyici oturum yapışkanlığı gerektiriyor mu?
5. Bir araç, onay istemeden önce yan etkiye neden oluyor mu?
6. Ağ geçidi yöntemi veya aracı belirlemek için gövdeyi ayrıştırıyor mu?
7. OAuth kimlik bilgileri, yayımlayan yetkilendirme sunucusu olmadan mı saklanıyor?
8. İstemci SSE yeniden bağlanmasına veya ileti yeniden teslimine bağımlı mı?
9. Araç veya kaynak listeleri bağlantıya göre değişiyor mu?
10. 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.

{
  "resultType": "complete",
  "content": [
    {
      "type": "text",
      "text": "Workspace created."
    }
  ],
  "structuredContent": {
    "workspaceHandle": "ws_7f93a2"
  }
}

Sonraki bir istek tanıtıcıyı normal bir argüman olarak geçirir:

{
  "name": "update_workspace",
  "arguments": {
    "workspaceHandle": "ws_7f93a2",
    "status": "approved"
  }
}

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:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
Authorization: Bearer <token>
{
  "jsonrpc": "2.0",
  "id": "req-101",
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "query": "stateless MCP migration"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "2.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

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:

const client = new Client(
  {
    name: "my-client",
    version: "1.0.0"
  },
  {
    versionNegotiation: {
      mode: "auto"
    }
  }
);

await client.connect(transport);

Otomatik modda, SDK server/discover ile yoklama yapar ve eski bir sunucuya ulaştığında daha eski başlatma akışına geri dönebilir.

Hâlâ @modelcontextprotocol/sdk v1 kullanan ekipler önce resmi TypeScript SDK v1-to-v2 geçiş kılavuzunu izlemelidir. Halihazırda v2 kullanan ekipler ayrı 2026-07-28 protokol destek kılavuzunu kullanmalıdır.

4. Sunucu Başlatımlı İstekleri MRTR ile Değiştirin

Önceki MCP uygulamaları, elicitation/create, sampling/createMessage veya roots/list gibi istekleri sunucudan istemciye gönderebiliyordu.

Yeni protokol bu modeli Multi Round-Trip Requests ile değiştirir.

Akış şöyle:

1. İstemci orijinal isteği gönderir.
2. Sunucu resultType: "input_required" döndürür.
3. İstemci istenen bilgiyi veya onayı toplar.
4. İstemci, yeni bir JSON-RPC kimliği kullanarak orijinal işlemi yeniden dener.
5. Yeniden deneme, inputResponses ve orijinal requestState içerir.
6. Sunucu isteği tamamlar veya başka bir tura başlar.

Örnek yanıt:

{
  "jsonrpc": "2.0",
  "id": "delete-1",
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "confirm_delete": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Delete project project_123?",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "confirmed": {
                "type": "boolean"
              }
            },
            "required": ["confirmed"]
          }
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

İstemci orijinal işlemi yeniden dener:

{
  "jsonrpc": "2.0",
  "id": "delete-2",
  "method": "tools/call",
  "params": {
    "name": "delete_project",
    "arguments": {
      "projectId": "project_123"
    },
    "inputResponses": {
      "confirm_delete": {
        "action": "accept",
        "content": {
          "confirmed": true
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

Ü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.

Yetkilendirme Farkında Önbellek Anahtarları Kullanın

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:

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.

Emeklilik tarihi belirlemeden önce resmi kullanım dışı özellikler kaydını inceleyin.

7. Geçişi Güvenle Yayınlayın

İ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ı

1. Protokol sürümleri, SDK’lar, oturumlar, SSE trafiği, DCR istemcileri ve kullanım dışı yöntemleri envanterleyin.
2. Üretim dışı SDK’ları yükseltin.
3. server/discover ve sürüm müzakeresi ekleyin.
4. Gizli oturum bağımlılıklarını değiştirin.
5. MRTR’ı uygulayın ve güvene alın.
6. Doğrulanmış yönlendirme başlıkları ve kapsamlı önbellekler ekleyin.
7. Yetkilendirme issuer sınırlarını test edin.
8. Modern protokolü eski yol ile birlikte kanarya olarak yayınlayın.
9. 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

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.

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:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.COMETAPI_KEY,
  baseURL: "https://api.cometapi.com/v1"
});

export async function summarizeResource(content: string) {
  const response = await client.chat.completions.create({
    model: "your-selected-model",
    messages: [
      {
        role: "system",
        content: "Summarize the supplied resource clearly and concisely."
      },
      {
        role: "user",
        content
      }
    ]
  });

  return response.choices[0]?.message?.content ?? "";
}

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:

1. MCP istemcileri ve sunucuları, model entegrasyon katmanını değiştirmeden yeni protokole geçebilir.
2. Model sağlayıcıları, MCP araçları veya taşıma davranışı yeniden tasarlanmadan değiştirilebilir.

Daha fazla uygulama ayrıntısı için CometAPI Quickstart, API dokümantasyonu ve çoklu model yapay zeka uygulama rehberine bakın.

MCP 2026-07-28 Geçiş Kontrol Listesi

İstemci

• Uyumluluklu bir SDK’ya yükseltin.
• Modern sürüm müzakeresini etkinleştirin.
• server/discover desteği ekleyin.
• Her istekte protokol metaverisi ekleyin.
• resultType işleyin.
• MRTR’ı destekleyin veya açıkça reddedin.
• 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.

1. Gerekli durumu açık tanıtıcılara veya paylaşılan depolamaya taşıyın.
2. MRTR’ı son kullanma, tekrar yürütme koruması ve idem-potentlikle uygulayın.
3. MCP başlıklarını JSON-RPC gövdesine karşı doğrulayın.
4. Önbellekleri kiracı ve yetkilendirme kapsamına göre bölümlendirin.
5. OAuth issuer doğrulamasını sertleştirin.
6. Kullanım dışı yöntemleri ve eski taşıma trafiğini ölçün.
7. 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.