Skip to content

Protokol Dönemleri

nexus-mcp, iki MCP protokol dönemini aynı anda ve aynı bağlantı üzerinde destekler: el sıkışma gerektirmeyen güncel 2026-07-28 biçimi ve klasik 2025-06-18 initialize el sıkışması. supportedVersions değeri ["2026-07-28", "2025-06-18"]'dir — bu ikilinin dışında hiçbir şey kabul edilmez. Bu sayfa birini seçip doğru kullanmakla ilgilidir; tüm alan adlarını içeren eksiksiz anlaşma sözleşmesi MCP Protokolü sayfasındadır.

Doğru anlaşılması gereken tek şey: dönem istek başınadır

Bu sunucuda "bu bağlantı hangi dönemi konuşuyor" diye hatırlanan bir şey yoktur. Her istek, yalnızca kendi _meta bloğuna bakılarak tek başına sınıflandırılır:

  • _meta alanında geçerli bir dize io.modelcontextprotocol/protocolVersion taşıyan istek 2026-07-28 olarak değerlendirilir.
  • Böyle bir anahtarı hiç taşımayan istek, eski dönem 2025-06-18 olarak değerlendirilir.

Bir istemcinin bir dönem seçip bağlantı boyunca orada kalması beklenir, ancak sunucu tarafında bunu zorlayan bir mekanizma yoktur — istemci kodunuz karışık gönderirse, her istek yine de aynı bağlantıda kendisinden önce gelenden bir mod devralmak yerine tek tek değerlendirilir. Sunucu bu sapmayı kendisi tespit etmese de, istemcinizi bu kesin bir kuralmış gibi yazın.

Yeni bir istemci yazıyorsanız: 2026-07-28 kullanın

Bu dönemde initialize el sıkışması yoktur. İstemcinin gönderdiği ilk şey server/discover çağrısıdır; 2026-07-28 dönemindeki her istemcinin bu çağrıya erişebilmesi gerekir — istemci, başka hiçbir şey çağırmadan önce sunucunun ne sunduğunu bu şekilde öğrenir.

json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "server/discover",
  "params": {},
  "_meta": {
    "io.modelcontextprotocol/protocolVersion": "2026-07-28",
    "io.modelcontextprotocol/clientInfo": { "name": "example-cli", "version": "1.4.0" },
    "io.modelcontextprotocol/clientCapabilities": {}
  }
}
json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "server/discover",
    "supportedVersions": ["2026-07-28", "2025-06-18"],
    "capabilities": { "tools": {} },
    "ttlMs": 60000,
    "cacheScope": "session",
    "_meta": { "io.modelcontextprotocol/serverInfo": { "name": "nexus-mcp" } }
  }
}

Bu dönemdeki sonraki her istek aynı _meta bloğunu taşır (istemci kimliği ve yetenekleri genellikle bulunur, ancak sürüm gibi yeniden doğrulanmaz) ve başarılı her sonuç resultType taşır; liste döndüren sonuçlar (server/discover ve tools/list gibi) ayrıca, o sonucun ne kadar süre güncel sayılabileceğini anlatan ttlMs ve cacheScope taşır — buradaki sayıları örnek kabul edin ve koda sabitlemek yerine kendi yanıtınızdan okuyun.

Daha eski bir MCP istemcisi entegre ediyorsanız: 2025-06-18 değişmeden çalışır

İkinci ve daha yeni bir dönemin desteklenmesi, klasik el sıkışmanın davranışında hiçbir şeyi değiştirmedi. Eski dönem istemcisi initialize çağırır, resultType sarmalayıcısı olmayan düz bir MCP sonucu alır, initialized gönderir ve başka herhangi bir 2025-06-18 sunucusunda olduğu gibi devam eder:

json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {},
    "clientInfo": { "name": "example-cli", "version": "1.0.0" }
  }
}
json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": { "tools": {} },
    "serverInfo": { "name": "nexus-mcp" }
  }
}

Sürüm eşleşmediğinde

Hangi dönemi bildirirseniz bildirin — modern biçimde _meta ile ya da eski biçimde initialize.params ile — desteklenmeyen bir değer, isteğin başka hiçbir yanına bakılmadan reddedilir:

json
{
  "jsonrpc": "2.0",
  "id": 7,
  "error": {
    "code": -32022,
    "message": "Unsupported protocol version",
    "data": { "supported": ["2026-07-28", "2025-06-18"], "requested": "2024-11-05" }
  }
}

data.supported her zaman güncel supportedVersions listesini verir; böylece birden fazla dönemi konuşabilen bir istemci, pes etmek yerine kendisinin de desteklediği bir sürümle yeniden deneyip denemeyeceğine karar verebilir. Bunu, açıkça ele alınmaya değer diğer hatalarla birlikte görmek için Sorun Giderme, yanı başındaki hatalı biçimlendirilmiş _meta durumu için ise MCP Protokolü sayfasına bakın (_meta ayrılmış ad alanını geçerli bir sürüm dizesi olmadan kullandığında dönen -32602).

Bağlandıktan sonra iki dönem de aynı araçlara ulaşır

Hangi dönemi konuştuğunuz, canvas_* ve agent_* araçlarının ne yaptığını veya ne kabul ettiğini değiştirmez — bkz. Araç Ad Alanları. Dönem yalnızca bir çağrının etrafındaki sarmalayıcının biçimini değiştirir, içindeki araç sözleşmesini asla.

Sonraki adımlar

  • MCP Protokolü — eksiksiz, alan alan sözleşme.
  • Araç Ad Alanları — bağlandıktan sonra neler kullanılabilir.
  • Sorun Giderme — başarısız keşif, sürüm uyuşmazlığı ve bağlantı üzerindeki kimlik bilgisi sorunları.

Built with purpose.