MCP Spesifikasyona Göre: Bir Sunucu Gerçekte Nedir

Wire’dan önce aritmetik. Elinde $N$ AI uygulaması ve bunların erişebilmesi gereken $M$ şey var: takvim, ticket tracker, warehouse veritabanı, tasarım aracı. Ortak bir sözleşme yoksa biri $N \times M$ entegrasyon yazar; her biri de bir schema, bir endpoint, bir kimlik doğrulama hikâyesi ve bir bakım yüküdür. Ortak sözleşmeyle tool sağlayıcısı bir sunucu yazar, uygulama sağlayıcısı bir client yazar ve toplam $N + M$ olur.

Bu yeni bir gözlem değil ve spesifikasyon fikrin kimden geldiğini söylüyor:

MCP takes some inspiration from the Language Server Protocol, which standardizes how to add support for programming languages across a whole ecosystem of development tools. In a similar way, MCP standardizes how to integrate additional context and tools into the ecosystem of AI applications.¹

Bu karşılaştırmayı iltifat gibi değil, kelimesi kelimesine al. O protokolden önce bir editörde bir dili desteklemek, editör başına plugin demekti; sonra bir dil ekibi tek sunucu yayınladı ve her editör onu aldı. Başarı ölçütü zarafet değildi; entegrasyon sayısının çarpılmayı bırakmasıydı. Burada da aynı şey geçerli: değer tasarımda değil, implementation sayısındadır. İki ürünün konuştuğu bir protokol, fazladan seremoni eklenmiş bir veri biçimidir.

MCP mesajları JSON-RPC 2.0’dır. Bir request; jsonrpc, bir id, bir method ve isteğe bağlı params içeren bir object’tir; response aynı id değerini ve ya result ya da error taşır; notification, id olmayan bir request’tir ve yanıt almaz. Spesifikasyon bunun üstüne üç kısıt ekler: id string veya sayı olmalı ve null olmamalıdır, uçuşta olan başka bir request ile çakışmamalıdır ve her result bir resultType alanı taşımalıdır.²

stdio transport’unda — yukarıdaki komutun kullandığı transport — framing kuralı mesaj başına bir satırdır:

Messages are delimited by newlines, and MUST NOT contain embedded newlines. […] The server MUST NOT write anything to its stdout that is not a valid MCP message.³

Bu son madde, ev yapımı bir sunucunun en sık kırıldığı yerdir ve sessizce kırılır: başıboş bir console.log, bir progress bar, bir dependency’den gelen deprecation warning’i derken client’ın satır parser’ı JSON olmayan bir şeye çarpar. Kaçış yolu aynı bölümde: sunucu stderr içine istediğini yazabilir ve client bunu hata saymamalıdır. Yukarıdaki reference server her başlatmada stderr üzerinde Starting default (STDIO) server... yazdırıyor; pipe’ın yine de çalışmasının nedeni bu.

Diğer standart transport Streamable HTTP’dir: her mesaj tek bir endpoint’e POST edilir ve yanıt ya bir JSON object ya da request-scoped bir Server-Sent Events akışıdır — 14. Bölüm’ün elle parse ettiği wire format. Semantics ikisinde de aynıdır; çünkü transport bir binding’dir: framing ve delivery tanımlar, anlamı değil.⁴

Yukarıdaki komut tools/list gönderdi, başka hiçbir şey göndermedi. Mevcut revizyona göre bu request malformed’dur ve uyumlu bir sunucu onu reddetmelidir.

2026-07-28 itibarıyla MCP stateless bir protokoldür ve spesifikasyon bunu hiç yumuşatmadan söyler:

The Model Context Protocol (MCP) is a stateless protocol: all the information needed to process a request is contained in the request itself. A server processes each request independently; no state should be inferred from previous requests, even those on the same connection or stream.²

Yani her request kendi protokol sürümünü ve kendi client capabilities bilgisini, params içindeki ayrılmış bir _meta object’inde taşır. Bu alanlardan ikisi her tek request’te zorunludur; ikisinden biri eksik olan request malformed’dur ve sunucu -32602 yanıtlamalıdır:²

Açık yazıldığında doğru bir tools/list budur — ve bu bölüm metadata’yı tam olarak son kez gösteriyor; çünkü bundan sonra her request’te var:

{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientCapabilities":{"elicitation":{"form":{}}},
  "io.modelcontextprotocol/clientInfo":{"name":"bare-hands","version":"0.0.1"}}}}

Capability object negotiation’ın kendisidir. Artık ayrı bir negotiation adımı yok: client her request’te ne yapabildiğini bildirir, sunucu result içinde ne yapabildiğini bildirir ve iki taraf da diğerinin sahip olduğunu iddia etmediği bir özelliği kullanamaz. Client’ın bildirmediği bir capability’ye ihtiyaç duyan sunucu -32021 yanıtlamalı ve eksik capability’yi data.requiredCapabilities içinde adlandırmalıdır. İstenen sürümü konuşmayan sunucu -32022 yanıtlamalı ve konuştuğu sürümleri listelemelidir.²

Yanıtı baştan isteyen client’lar bunu sorabilir: server/discover, supported versions, capabilities, identity ve isteğe bağlı bir instructions bloğunu tek round trip’te döndüren zorunlu bir RPC’dir.⁵ Onu çağırmak isteğe bağlıdır. Onu implement etmek değildir.

Komut çalıştı. Mevcut revizyona göre çalışmaması gerekirdi; çalışmasının nedeni bir paragraftan çok bir ölçümü hak ediyor, çünkü tüm ekosistemin durumunu tek satırda gösteriyor.

Reference server’ı, spesifikasyonun modern bir client’a probe etmesini söylediği şekilde probe et:

echo '{"jsonrpc":"2.0","id":1,"method":"server/discover","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientCapabilities":{}}}}' \
  | npx @modelcontextprotocol/server-everything stdio

{"jsonrpc":"2.0","id":1,"error":{"code":-32601,"message":"Method not found"}}

Bu, compatibility kuralının üçüncü dalıdır: DiscoverResult modern demektir, tanınan modern bir error modern-ama-yanlış-sürüm demektir ve başka her şey — -32601 dahil — legacy demektir; initialize handshake’e geri dön.³ Öyleyse current revision’ı isteyerek bunu yap:

→ {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2026-07-28",
   "capabilities":{},"clientInfo":{"name":"bare-hands","version":"0.0.1"}}}

← {"result":{"protocolVersion":"2025-11-25","capabilities":{"tools":{"listChanged":true},
   "prompts":{"listChanged":true},"resources":{"subscribe":true,"listChanged":true},
   "logging":{},"tasks":{…},"completions":{}},"serverInfo":{"name":"mcp-servers/everything",
   "title":"Everything Reference Server","version":"2.0.0"},"instructions":"…"}}

Client 2026-07-28 istedi, sunucu 2025-11-25 yanıtladı. 7 Eylül 2026’da resmi reference server — npm package @modelcontextprotocol/server-everything, sürüm 2026.8.31, 31 Ağustos 2026’da yayınlanmış — current revision’ı implement etmiyor. Tarihlere bakınca, üzerine kurulu olduğu TypeScript SDK de etmiyor: 1.30.0 release’i 27 Temmuz 2026’da, revizyondan bir gün önce çıktı.

Dedikoduyu değil sonucu oku. MCP hakkında yazılan neredeyse her şey initialize handshake’i, session’ı, sunucunun client’a gönderdiği roots/list request’i ve HTTP+SSE transport’u olan bir protokolü anlatıyor. Dördü de gitti ya da gidiyor. Bu sayfa dahil MCP hakkında herhangi bir şey okurken bakacağın ilk şey revizyon numarasıdır.

Ve en baştaki komutun çalışmasının nedeni spesifikasyonda özellik değil tehlike olarak geçer:

some legacy servers do not validate that a request arrives after initialize and would process an era-ambiguous method (such as tools/call) under legacy semantics. Probing yields a deterministic failure instead.³

Ölçüldü: o sunucuya hiçbir handshake olmadan tools/list göndermek tüm kataloğu döndürüyor. Reddedilmesi gereken bir method servis edildi; spesifikasyonun, yalnızca modern sürümleri desteklesen bile önce server/discover ile probe et demesinin nedeni tam olarak bu.

MCP’de üç taraf vardır ve insanların birbirine karıştırdığı ayrım ilk ikisi arasındadır:

Sunucu. Resources, araçlar ve prompts expose eden bir process veya service. Local ya da remote olabilir, bağımsız çalışır ve tüm işi tek bir odak alanıdır.⁶

Bu “tam olarak bir sunucu” kuralı defter tutma değildir. Aşağıdaki tasarım ilkesini uygulanabilir kılan şeydir ve spesifikasyondan tek cümle alacaksan o cümle budur:

Servers should not be able to read the whole conversation, nor "see into" other servers. Servers receive only necessary contextual information. Full conversation history stays with the host. Each server maintains isolation. Cross-server interactions are controlled by the host.⁶

Bu, çoğu insanın geldiği zihinsel modeli tersine çevirir. Assistant’ına bağladığın bir hava durumu sunucusu, ne sorduğunu görmez. Modelin seçtiği arguments ile bir tools/call görür, başka hiçbir şey görmez — önceki turn’leri, system prompt’unu, takvim sunucusunun az önce döndürdüğü sonuçları değil. İki sunucunun işbirliği yapması gerekiyorsa host, bir değeri birinden diğerine bilinçli olarak taşır; çünkü model bunu istemiştir. Bu yüzden isolation, 30. Bölüm’ün dayandığı security property’dir: ele geçirilmiş bir sunucunun küçük ve tanımlı bir blast radius’u vardır; bunu büyütmek host’un işbirliğini gerektirir.

İlk komut o sunucudan araçları istedi ve on üç tane aldı. Diğer iki soruyu da sorarsan onları da yanıtlıyor: resources/list yedi, prompts/list dört döndürüyor. Hiçbiri görünmedi; çünkü hiçbir şey sormadı. Bu bizi MCP’nin pedagojik omurgasına getiriyor: spesifikasyonda duran ama neredeyse kimsenin alıntılamadığı bir tablo.

“Bir capability expose etmenin üç yolu” değil. Bunun olmasına kim karar veriyor sorusuna üç yanıt. Model bir aracı çağırmaya karar verir. Uygulama bir resource eklemeye karar verir. Kişi bir prompt çalıştırmaya karar verir. Bunu yanlış anlarsan özellik yine çalışır ama yanlış anda ve yanlış nedenle çalışır.

Bunu hissetmenin en net yolu bir takvimdir. İşte aynı takvimi üç kez, her primitive olarak birer kez expose eden, dependency’siz yüz satırlık düz Node sunucusu:

const TOOL = {
  name: "create_event",
  description: "Create a calendar event. Writes to the calendar.",
  inputSchema: {
    type: "object",
    properties: {
      title:    { type: "string", description: "Event title." },
      startsAt: { type: "string", format: "date-time", description: "Start, ISO 8601 UTC." },
    },
    required: ["title"],
  },
};

switch (method) {
  case "resources/read":                                          
    return ok(id, { contents: [{ uri: "calendar://week",
      mimeType: "application/json", text: JSON.stringify(EVENTS) }],
      ttlMs: 60000, cacheScope: "private" });

  case "prompts/get":                                             
    return ok(id, { description: PROMPT.description, messages: [{ role: "user",
      content: { type: "text", text: `Read calendar://week and draft a plan. ` +
        `Focus: ${params.arguments?.focus ?? "balance"}.` } }] });

  case "tools/list":                                              
    return ok(id, { tools: [TOOL], ttlMs: 300000, cacheScope: "public" });
}

Çalıştır ve üç şekilde de sor. Gerçek çıktı; wire üzerinde satır başına bir mesaj, sayfa için burada sarıldı, request _meta ve sunucunun identity block’u çıkarıldı:

→ resources/read  {"uri":"calendar://week"}
← {"resultType":"complete","contents":[{"uri":"calendar://week",
   "mimeType":"application/json","text":"[{\"id\":\"e1\",\"title\":\"Standup\",
   \"startsAt\":\"2026-09-07T09:00:00Z\"},{\"id\":\"e2\",\"title\":\"Design review\",
   \"startsAt\":\"2026-09-09T15:00:00Z\"}]"}],"ttlMs":60000,"cacheScope":"private"}

→ prompts/get    {"name":"prepare_week","arguments":{"focus":"deep work"}}
← {"resultType":"complete","description":"Read the week and draft a plan.",
   "messages":[{"role":"user","content":{"type":"text",
   "text":"Read calendar://week and draft a plan. Focus: deep work."}}]}

→ tools/call     {"name":"create_event","arguments":{"title":"Dentist",
                  "startsAt":"2026-09-10T08:30:00Z"}}
← {"resultType":"complete","content":[{"type":"text",
   "text":"Created e3: Dentist at 2026-09-10T08:30:00Z"}],
   "structuredContent":{"id":"e3","title":"Dentist","startsAt":"2026-09-10T08:30:00Z"},
   "isError":false}

Üç method, üç shape, tek takvim. Şimdi mesele:

Neredeyse herkes bu üçünü de araç yapar. Sonuç; uygulamanın sessizce eklemesi gereken bir read’in, approval gerektiren bir write ile modelin attention’ı için yarıştığı ve kişinin buton istediği tek şeyin schema içine gömüldüğü bir katalogdur. Doğru yapmak hiçbir şeye mal olmaz ve tek satır yazmadan önce karar verilir.

Takvim aracının bir zorunlu argument’i, title, ve isteğe bağlı bir startsAt alanı var. Ondan tarihsiz bir etkinlik oluşturmasını iste ve ilginç bir şey geri gelir:

→ tools/call {"name":"create_event","arguments":{"title":"Dentist"}}

← {"resultType":"input_required",
   "inputRequests":{"when":{"method":"elicitation/create","params":{"mode":"form",
     "message":"When should \"Dentist\" start?",
     "requestedSchema":{"type":"object",
       "properties":{"startsAt":{"type":"string","format":"date-time"}},
       "required":["startsAt"]}}}},
   "requestState":"eyJ0aXRsZSI6IkRlbnRpc3QifQ=="}

Sunucu request göndermedi. Kendisine verilen request’e, resultType: "input_required" ve hâlâ neye ihtiyaç duyduğunun açıklamasıyla yanıt verdi. Client yanıtı kişiden toplar ve sonra original call’u yeniden gönderir — yeni bir id ile, inputResponses taşıyarak ve opaque requestState değerini geri echo ederek:

→ tools/call {"name":"create_event","arguments":{"title":"Dentist"},
   "inputResponses":{"when":{"action":"accept",
     "content":{"startsAt":"2026-09-10T08:30:00Z"}}},
   "requestState":"eyJ0aXRsZSI6IkRlbnRpc3QifQ=="}

← {"resultType":"complete","content":[{"type":"text",
   "text":"Created e3: Dentist at 2026-09-10T08:30:00Z"}],"isError":false}

Bu, current revision’da tanıtılan Multi Round-Trip Requests’tir ve sunucuların client’lara JSON-RPC request’leri geri gönderdiği eski tasarımın yerini almıştır. Transport specification artık kuralı açıkça koyuyor: “servers do not initiate JSON-RPC requests and clients do not send JSON-RPC responses”.⁴ İnisiyatifin tek yönü vardır ve host’a aittir.

İki client-side özellik bu mekanizmanın üzerinde ilerler ve birinin adı seni yanıltacak.

Elicitation, sunucunun kişiden bir şey istemesidir: bilerek kısıtlanmış JSON Schema’ya sahip bir form — flat objects, primitive properties, no nesting — böylece herhangi bir client onu layout engine olmadan render edebilir. Sert bir kural taşır: sunucular “passwords, API keys, access tokens, or payment credentials” istemek için form mode’u kullanmamalıdır ve bunlar için kullanıcıyı client’ın hiç okumadığı bir sayfaya gönderen URL mode’u kullanmalıdır.⁷

Sampling, sunucunun host’un modelinden bir generation istemesidir; böylece sunucu API key tutmadan intelligent olabilir. Ve burada vocabulary uyarısı var; çünkü bu kelime bu kursta zaten başka bir anlama geliyor: bu, 17. Bölüm’ün sampling’i değildir. Burada temperature, top-p veya probability distribution’ın şekliyle ilgili hiçbir şey yok. Bu, protokol üzerinden geriye doğru giden nested bir model call’dur.

Ona sarılmamak için ikinci bir neden var: bu revizyon itibarıyla sampling deprecated, roots ve logging ile birlikte SEP-2577 kapsamında; önerilen migration da gayet net: “integrate directly with LLM provider APIs instead of Sampling”.⁸ Fikir teknik olarak başarısız olmadı; surface area’sını haklı çıkaramadı ve bir şeyleri kaldırabilen protokol, kaldıramayandan daha sağlıklıdır.

Statelessness, test edene kadar wire-format detayı gibi görünür. Yukarıdaki üç mesajlı exchange’i al ve her mesajı ayrı bir process içinde çalıştır — yepyeni bir node calendar.mjs, shared memory yok, taşınan hiçbir şey yok:

process A   tools/call (no date)   → resultType: input_required
                                     requestState: eyJ0aXRsZSI6IkRlbnRpc3QifQ==
process B   tools/call (with the answer, same requestState)
                                   → resultType: complete
                                     "Created e3: Dentist at 2026-09-10T08:30:00Z"
process C   resources/read calendar://week
                                   → events: 2  (Standup, Design review)

Soruyu hiç görmeyen Process B, Process A’nın başlattığı multi-round-trip call’u tamamladı. requestState noktasının anlamı bu: continuation mesajın içinde seyahat eder, bu yüzden hiçbir şey process’in aynı olmasına bağlı değildir.

Process C başarısızlıktır. Etkinlik oluşturuldu ama orada değil — çünkü toy server EVENTS değerini module-level array’de tutuyor ve module-level array connection state’tir. Spesifikasyonun notu hatayı tam adıyla söyler:

an open connection, such as a STDIO process, is not a conversation or session: clients may interleave unrelated requests on the same transport, and a server must not treat connection or process identity as a proxy for conversation or session continuity.²

Önerilen düzeltme session değildir. Explicit handle’dır: creation tool opaque bir identifier döndürür ve sonraki her call bunu sıradan bir argument olarak alır. Protokolde buna dair hiç kavram yoktur — “from the wire's perspective a handle is an ordinary string in a tool result and an ordinary argument to subsequent tool calls”.⁹ Bu, onu taşımayı modelin sorumluluğuna verir; her tek call’da bu caller’ın onu kullanmaya izinli olduğunu validate etmeyi de sunucunun sorumluluğuna verir. Çünkü handle bir addır, permission değildir.

Bir sunucunun expose ettiği her araç, her request’te prompt’una giren bir schema’dır ve 24. Bölüm bunun context window’a ne yaptığını ölçtü. MCP, gözden kaçırması kolay ikinci bir kalem ekler; bu yüzden yukarıdaki reference server’da ikisini de saymaya değer.

13 tool definitions (name + description + inputSchema):  1,307 tokens
  cheapest tool, get-tiny-image                              52
  costliest tool, gzip-file-as-resource                     235
server `instructions`, returned by discovery:               312 tokens
                                                          ------
one server, connected, before it is used:                 1,619 tokens

İki gözlem. İlki aritmetik: bu boyutta beş sunucu bağla ve window’unun yaklaşık sekiz bin token’ı, model bunlardan herhangi birini kullansın kullanmasın, her turn’de sonsuza kadar ayrılmış olur — 24. Bölüm’ün alıntıladığı 150.000’den 2.000’e düşüşün arkasındaki mekanizma ve just-in-time tool discovery’nin varlık nedeni budur.

İkincisi accounting kostümü giymiş bir security notu. instructions, sunucu yazarı tarafından yazılmış, host’un prompt’una düşen natural-language text’tir; yanındaki tool descriptions da aynıdır. Spesifikasyon kendi security principles bölümünde bununla ilgili ne yapılacağını söyler: tool annotations ve descriptions “should be considered untrusted, unless obtained from a trusted server” ve hosts “must obtain explicit user consent before invoking any tool”.¹ Bir MCP sunucusu bağlamak dependency eklemek değildir. Bir yabancıya system prompt’unun 1.619 token’ını ve çağrılma hakkını vermektir. 30. Bölüm, o yabancı hostile olduğunda olan şeydir.

Bu bölümdeki her şey, 2026-07-28 protokol revizyonu için doğrudur; 7 Eylül 2026’da okunan current revision. Revizyonlar YYYY-MM-DD biçiminde tarihlenir ve tarih, backwards-incompatible bir değişikliğin en son yapıldığı zamandır.¹⁰ Normative document bir TypeScript dosyasıdır, schema/2026-07-28/schema.ts; yanındaki JSON Schema ondan generated’dır. Bu yüzden spesifikasyon burada TypeScript’ten okunur ve MCP’yi başka herhangi bir şeyden öğretmek bir translation öğretmektir.

Bu tablonun altındaki governance değişikliği, tek tek satırların hepsinden daha önemlidir. Bu revizyon bir feature lifecycle and deprecation policy benimsedi: features Active, Deprecated veya Removed olur; deprecated feature migration path’ini belgeler ve removal için eligible olmadan önce en az on iki ay spesifikasyonda kalır; Deprecated durumundaki her şeyi listeleyen bir registry vardır.⁸ Bu politikadan önce bir AI protokolünde “deprecated”, son blog post’un ne dediğine bağlıydı. Artık bir tarih demek.

Bu bloktaki vocabulary tek yerde.

Bunlardan ikisi birer cümleyi hak ediyor; çünkü kafa karışıklığı gerçekten orada yaşıyor.

MCP ile A2A bir rekabet değildir ve iki spesifikasyon da bunu söyler. A2A documentation çizgiyi karşı uçta ne olduğuna göre çizer: MCP “defines how an AI agent interacts with and utilizes individual tools and resources, such as a database or an API”; burada tool “specific, often stateless, functions” gerçekleştirir. A2A ise agents’a, “more autonomous systems”a yöneliktir; bunlar “reason, plan, use multiple tools, maintain state over longer interactions, and engage in complex, often multi-turn dialogues” yapar. Kendi özeti hatırlanacak cümledir: “A2A is about agents partnering on tasks, while MCP is more about agents using capabilities.”¹¹ İkisi iç içe geçer — bir uygulama başka agents’a ulaşmak için A2A kullanır; her agent kendi araçlarına ulaşmak için MCP kullanır. 25. Bölüm, aynı process içinde sub-agent’a sormak ile conversation’ı ona devretmek arasındaki çizgiyi çizmişti; A2A bunu organizasyonlar arasında çizer.

MCP ile ACP bayat bir premise’e sahip bir karşılaştırmadır; tam da bu yüzden yanıtlamaya değer. Agent Communication Protocol, agent-to-agent messaging için ayrı bir open standard’dı. Kendi documentation’ı artık şu notice ile açılıyor: “ACP is now part of A2A under the Linux Foundation!”¹² Eylül 2026’da “MCP mi ACP mi?” sorusunun dürüst yanıtı, sıralama alan sayfaların ima ettiğinden bir seçenek daha az olduğudur.

Ve insanların en çok istediği karşılaştırma, mcp vs api, en az ilginç yanıta sahip: MCP bir API’dir. Eklediği şey güç değil, conventions’dır — sabit bir method names kümesi, discovery call, primitives üzerinde control hierarchy ve isolation model. Kendi interface’ini tasarlama özgürlüğünden vazgeçersin ve karşılığında protokolü konuşan her host’u alırsın; her protokolün şimdiye kadar sunduğu trade-off budur.

Artık spesifikasyonu tercümansız okuyabilir, resource ile tool ile prompt’u kimin kontrol ettiğine bakarak ayırabilir, client library sana yalan söylediğinde bir request’i elle yazabilir ve okuduğun herhangi bir MCP yazısını, hâlâ current diye öğrettiği deprecated features’a bakarak tarihleyebilirsin.

Henüz yapmadığın şey bir tane ship etmek. 27. Bölüm aynı sunucuyu iki kez yazıyor — TypeScript ve Python, yan yana; çünkü MCP bu kurstaki gerçekten bilingual tek alan ve sayılar iki yönde de bunu söylüyor. İki live transport’u doğru düzgün, inspector’ı, packaging’i ve bu bölümün bilerek kenarda bıraktığı protocol yarısını kapsıyor: authorization. Çünkü sunucun kendi laptop’ındaki bir subprocess değil de remote olduğu anda bir yabancının client’ı bir token sunacak ve spesifikasyonun onunla ne yapabileceğine dair kuralı alışılmadık derecede strict.

Bu da bir sonraki bölümün yanıtlaması gereken soruyu doğuruyor; dostça bir soru değil: sunucuna bir token gelirse ve başka birinin audience’ı için issued edilmişse, onu forward etmeni tam olarak ne durdurur?

Bu bölümdeki her quotation, method name, error code ve rule, 7 Eylül 2026 tarihinde Model Context Protocol specification’ın 2026-07-28 revizyonundan okundu. Her trace local olarak Node 22 üzerinde üretildi: toy calendar server dependency’siz 101 satırdır ve reference server aşağıda adı verilen published npm package’tır. Bu bölümü yazmak için paid API çağrılmadı — burada hiçbir şey bir model gerektirmiyor; zaten mesele de bu.

Ölçümler: @modelcontextprotocol/server-everything@2026.8.31, 31 Ağustos 2026’da yayınlandı, @modelcontextprotocol/sdk@1.30.0 üzerine kurulu, 27 Temmuz 2026’da yayınlandı — bu bölümün anlattığı revizyondan bir gün önce. server/discover isteğine -32601 yanıtlıyor, 2026-07-28 istendiğinde 2025-11-25 negotiate ediyor ve hiçbir handshake olmadan tools/list servis ediyor. Kataloğu 7.663 byte içinde 13 tool; token counts, her definition’ın name, description ve inputSchema alanları üzerinden tiktoken aracılığıyla o200k_base; bu bir provider’ın prompt’una render ettiği şeydir, JSON-RPC frame’in ağırlığı değil.

Anthropic, Code execution with MCP: building more efficient agents, 4 Kasım 2025, 150.000’den 2.000’e figürünün kaynağıdır; 24. Bölüm’de alıntılanıp kullanılmış, burada yalnızca referans verilmiştir.