MCP sunucusu nedir, ne değildir?

Bir dil modelini kurumsal bir sisteme bağlamak, modelle ilgili bir iş değildir; entegrasyon işidir. Model Context Protocol (MCP) tam olarak bu katmanı standartlaştırmak için var. Bu yazı MCP’yi bir ürün olarak değil, bir protokol olarak ele alıyor: neyi tanımlıyor, neyi tanımlamayı reddediyor, kurumsal bir mimaride hangi kutuya oturuyor. Aşağıdaki teknik iddiaların tamamı resmî spesifikasyona dayanıyor. Spesifikasyon sürümleri YYYY-AA-GG biçiminde ve yalnızca geriye dönük uyumsuz bir değişiklik yapıldığında artıyor. Bu yazı 2025-11-25 revizyonuna dayanıyor. 28 Temmuz 2026’da yayımlanacak 2026-07-28 revizyonu protokolü durumsuz (stateless) hâle getiriyor, initialize el sıkışmasını ve oturum kimliğini kaldırıyor, Tasks’i çekirdekten çıkarıp bağımsız bir eklentiye taşıyor, Roots/Sampling/Logging’i on iki aylık kaldırma penceresiyle deprecated ilan ediyor. Aşağıdaki oturum ve primitif ayrıntıları o revizyonda değişiyor.

Her bağlantının ayrı yazıldığı dönem

MCP’den önce bir yapay zeka uygulamasını bir veri kaynağına bağlamak, o uygulama–kaynak çifti için özel kod yazmak demekti. Anthropic’in duyurusu problemi doğrudan böyle tarif ediyor: her yeni veri kaynağı kendi özel entegrasyonunu gerektiriyor, bu da gerçekten bağlı sistemleri ölçeklemeyi zorlaştırıyor. Sektörde bu duruma sık sık N×M deniyor — N tane uygulama, M tane sistem, aralarında N×M tane elle yazılmış köprü. Bu adlandırma resmî bir terim değil, ama tarif ettiği durum resmî metinde açıkça geçiyor. MCP’nin önerdiği takas basit: parçalı entegrasyonların yerine tek bir protokol koy, böylece her taraf yalnızca protokolü uygulasın.

MCP 25 Kasım 2024’te Anthropic tarafından açık kaynak olarak duyuruldu; yaratıcıları David Soria Parra ve Justin Spahr-Summers. İlk sürüm üç parça hâlinde çıktı: spesifikasyon ve SDK’lar, Claude Desktop uygulamalarında yerel MCP sunucu desteği, bir de Google Drive, Slack, GitHub, Postgres, Puppeteer gibi sistemler için hazır açık kaynak sunucu deposu.

9 Aralık 2025’te Anthropic MCP’yi Agentic AI Foundation’a (AAIF) bağışladı — Linux Foundation altında yönlendirilmiş bir fon. Kurucular Anthropic, Block ve OpenAI; destekleyenler arasında Google, Microsoft, AWS, Cloudflare ve Bloomberg var. MCP, goose ve AGENTS.md ile birlikte kurucu projelerden biri. Bakımcı yapısı olduğu gibi kaldı: yönetim kurulu bütçe, üyelik ve yeni proje kabulüyle ilgileniyor; teknik yönde projeler tam özerk. Yani bugün “MCP, Anthropic’in protokolüdür” demek eksik olur. Doğru ifade şu: Anthropic tarafından ortaya konuldu ve açık kaynaklandı, Aralık 2025’ten beri Linux Foundation çatısındaki AAIF altında. Resmî dokümantasyon MCP’yi destekleyen istemciler arasında Claude, ChatGPT, Visual Studio Code, Cursor ve MCPJam’i sayıyor.

Mimari: host, istemci, sunucu

MCP istemci-sunucu mimarisi izliyor ve üç rolü ayrı ayrı tanımlıyor. MCP Host, bir veya birden çok MCP istemcisini koordine eden yapay zeka uygulamasıdır — Claude Code ya da VS Code gibi. MCP Client, tek bir sunucuyla bağlantıyı sürdüren ve host için bağlam elde eden bileşendir. MCP Server ise istemcilere bağlam sağlayan programdır. Kritik ayrıntı: host her sunucu için ayrı bir istemci nesnesi oluşturur ve her istemci kendi sunucusuyla adanmış bir bağlantı tutar. Sunucular birbirini görmez.

“MCP sunucusu” terimi nerede çalıştığından bağımsızdır; yerel de olabilir uzak da. Pratikte stdio kullanan yerel sunucular tipik olarak tek istemciye, Streamable HTTP kullanan uzak sunucular çok istemciye hizmet eder. Protokol iki katmana ayrılıyor: veri katmanı (JSON-RPC 2.0 tabanlı mesajlaşma, yaşam döngüsü, primitifler, bildirimler) ve taşıma katmanı (bağlantı kurulumu, mesaj çerçeveleme, yetkilendirme). MCP durum bilgisi tutan bir protokoldür; oturum initialize ile başlar ve orada yetenek müzakeresi yapılır. İstemci ile sunucu tek bir protokol sürümünde anlaşmak zorundadır.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "roots": { "listChanged": true },
      "sampling": {}
    },
    "clientInfo": { "name": "ornek-host", "version": "1.0.0" }
  }
}

Spesifikasyon iki standart taşıma tanımlıyor: stdio ve Streamable HTTP. İstemcilerin mümkün olduğunca stdio desteklemesi öneriliyor; özel taşımalar da uygulanabilir, yeter ki JSON-RPC mesaj biçimi ve yaşam döngüsü korunsun. Streamable HTTP tek bir MCP endpoint yolu üzerinde hem POST hem GET destekler; sunucu isterse SSE ile akış yapar. 2024-11-05 sürümündeki eski HTTP+SSE taşıması yerini buna bıraktı ve deprecated durumda. HTTP kullanılıyorsa istemci, initialize sonrasındaki tüm isteklerde MCP-Protocol-Version başlığını göndermek zorunda; gönderdiği değer initialize sırasında müzakere edilen sürüm olmalı, başlığı hiç almayan sunucu ise 2025-03-26 varsayar. Sunucu isterse initialize yanıtında MCP-Session-Id verip sonraki isteklerde bunu bekleyebilir.

Spesifikasyon MCP’nin Language Server Protocol’den ilham aldığını açıkça söylüyor. Benzetme işe yarıyor: LSP editör ile dil arasındaki bağlantıyı standartlaştırdı, MCP de yapay zeka uygulaması ile dış sistem arasındakini.

Bir sunucunun sunduğu üç primitif

Sunucular yeteneklerini üç çekirdek primitif üzerinden açar. Bunları birbirinden ayıran şey ne yaptıkları değil, kimin kontrolünde oldukları:

• Tools — modelin çağırabileceği, eylem gerçekleştiren fonksiyonlar. Veritabanına yazabilir, dış API çağırabilir, dosya değiştirebilir. Kontrol: model. Metotlar: tools/list, tools/call.
• Resources — bağlam sağlayan, salt-okunur pasif veri kaynakları: dosya içeriği, veritabanı şeması, API yanıtı. Kontrol: uygulama. Metotlar: resources/list, resources/templates/list, resources/read, resources/subscribe.
• Prompts — yeniden kullanılabilir, parametreli etkileşim şablonları. Kontrol: kullanıcı; spesifikasyon bunların açıkça çağrılmasını öngörüyor. Metotlar: prompts/list, prompts/get.

Araç girdileri JSON Schema ile tanımlanır. Bu, sunucu yazarının modele değil şemaya güvenmesini sağlar: gelen çağrı önce şemaya karşı doğrulanır, sonra iş mantığına girer.

{
  "name": "siparis_durumu_getir",
  "title": "Sipariş durumu getir",
  "description": "Verilen sipariş numarasının güncel durumunu döndürür.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "siparisNo": { "type": "string", "pattern": "^[A-Z]{2}-[0-9]{6}$" },
      "detay": { "type": "boolean", "default": false }
    },
    "required": ["siparisNo"]
  }
}

Kaynak tarafında her kaynağın benzersiz bir URI’si ve MIME türü vardır. Sabit URI’ler dışında parametreli Resource Template’ler de tanımlanabilir — örneğin bir şehir ve tarih alan bir şablon. Akış tek yönlü değil: istemciler de sunuculara primitif sunar. Sampling ile sunucu, host’un modelinden bir tamamlama isteyebilir (sampling/createMessage); elicitation ile kullanıcıdan ek bilgi ya da onay isteyebilir (elicitation/create); roots ile sunucu, kendisine açılan dosya sistemi sınırını sorabilir; bir de logging var. Uzun süren işler için tanımlanan Tasks primitifi mevcut spesifikasyonda deneysel olarak işaretli, dolayısıyla kurulum planına sabit bir varsayım olarak yazılmamalı. Yetenekleri değişen sunucular notifications/tools/list_changed gibi bildirimler gönderebilir; bu yalnızca initialize sırasında listChanged bildiren sunucular için geçerli.

Yetkilendirme nerede yapılır

Burası okuyucunun en çok karıştırdığı yer. MCP’de yetkilendirme taşıma seviyesinde tanımlıdır ve opsiyoneldir. HTTP tabanlı taşımalar bu bölüme uymalı; STDIO taşıması bu bölümü izlememeli, kimlik bilgilerini ortamdan almalı. Yani stdio ile çalışan yerel bir sunucuda OAuth akışı aramak yanlış katmana bakmak olur.

HTTP tarafında roller net: korunan bir MCP sunucusu OAuth 2.1 resource server’dır, MCP istemcisi OAuth 2.1 client’tır, authorization server ise ayrı bir taraftır — sunucuyla aynı yerde barındırılabilir ya da tamamen ayrı olabilir. Bu ayrım, “MCP sunucusu bir yetki sınırıdır” cümlesinin dayanağıdır: sunucu token üreten taraf değildir, token doğrulayan ve erişimi kısıtlayan taraftır. Bölümün uyum listesinde OAuth 2.1 taslağı, RFC 8414, RFC 7591, RFC 9728 ve OAuth Client ID Metadata Documents taslağı yer alıyor. Ayrıca aynı doküman resource parametresi için RFC 8707’yi zorunlu tutuyor.

Kurulum sırasında somut karşılığı olan zorunluluklar şunlar:

• MCP sunucuları RFC 9728 (Protected Resource Metadata) uygulamak zorunda; istemciler authorization server keşfi için bunu kullanmak zorunda.
• İstemciler PKCE uygulamak ve teknik olarak mümkün olduğunda S256 yöntemini kullanmak zorunda; PKCE desteği yetkilendirme sunucusunun (authorization server) metadata’sındaki code_challenge_methods_supported alanından doğrulanamıyorsa devam etmeyi reddetmek zorunda.
• Sunucular yalnızca kendilerine özel olarak düzenlenmiş token’ları kabul etmek zorunda; audience alanında kendilerini görmedikleri token’ları reddetmek zorunda.
• Sunucu yukarı akış bir API’ye giderken kendisi ayrı bir OAuth istemcisi olur ve istemciden aldığı token’ı olduğu gibi aktarmamalıdır. Token passthrough açıkça yasaklanmış bir kalıp.
• Token’lar URI sorgu dizesinde taşınamaz; her HTTP isteğinde Authorization: Bearer başlığı gerekir — aynı mantıksal oturumun parçası olsa bile.
• Oturum kimliği kimlik doğrulama aracı değildir: sunucular oturumları kimlik doğrulama için kullanmamalıdır.

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
                         scope="siparis:oku siparis:yaz",
                         resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         error_description="Yazma yetkisi gerekli"

Hata kodları da tanımlı: 401 yetkilendirme gerekli ya da token geçersiz, 403 yetersiz kapsam, 400 bozuk istek. 403 durumunda sunucu gereken kapsamları WWW-Authenticate başlığında bildirir ve istemci bir step-up yetkilendirme turu başlatabilir. Kapsam minimizasyonu resmî olarak öneriliyor; kapsam adı olarak *, all ya da full-access kullanmak yaygın bir uygulama hatası olarak listeleniyor.

MCP ne değildir

MCP bir model değildir. Açık bir standarttır — yapay zeka uygulamalarını dış sistemlere bağlamak için. İçinde ağırlık, çıkarım motoru ya da model davranışı yoktur; hangi modeli kullandığınız protokolün ilgi alanı dışındadır.

MCP bir ajan çerçevesi değildir. Resmî kapsam notu bunu açıkça söylüyor: MCP yalnızca bağlam değişimi protokolüne odaklanır, yapay zeka uygulamalarının modelleri nasıl kullanacağını ya da sağlanan bağlamı nasıl yöneteceğini belirlemez. Planlama, döngü yönetimi, hafıza, yeniden deneme mantığı — hepsi protokolün dışında, uygulamanın içinde kalır.

MCP bir RAG sistemi değildir. Resources tarafında yapılan tarif nettir: uygulamalar bu bilgiye doğrudan erişir ve nasıl kullanacağına kendisi karar verir — ilgili bölümleri seçerek, gömmelerle arayarak ya da tamamını modele geçirerek. İndeksleme, parçalama ve vektör araması protokolde tanımlı değil; bunlar uygulamanın kararı.

MCP bir API gateway yerine geçmez. Bir MCP sunucusu yukarı akış API’lere giderken şeffaf bir geçiş katmanı değildir; yukarı akışta kullanılan erişim token’ı ayrı bir token’dır ve yukarı akıştaki authorization server tarafından düzenlenir. Sunucu kendi kimliğini ve kendi yetki sınırını taşır. Rate limiting, kota, protokol dönüşümü, kenar yönlendirme gibi işler hâlâ gateway’in işidir.

Resmî dokümantasyondaki benzetme yerinde: MCP’yi yapay zeka uygulamaları için bir USB-C portu gibi düşünün. Port, kabloya neyin bağlandığını ya da bağlanan cihazın ne yaptığını tanımlamaz.

Kurumsal kurulumda sunucu nerede durur

Spesifikasyonun güvenlik bölümü dört ilke sayıyor: kullanıcı onayı ve kontrolü, veri gizliliği, araç güvenliği, LLM örnekleme kontrolleri. Aynı bölümde şu nüans da var — MCP bu ilkeleri protokol seviyesinde zorlayamaz, uygulayıcıların uygulaması beklenir. Bu cümle, kurumsal kurulumda mimari kararların neden bu kadar belirleyici olduğunu tek başına açıklıyor: kontrolün büyük kısmı protokolde değil, sunucuyu kimin çalıştırdığında ve nerede çalıştırdığında.

Spesifikasyondaki güvenlik gereklilikleri kurum içi barındırmayı doğal kılıyor. Yerel çalışan sunucuların tüm arayüzler yerine yalnızca 127.0.0.1’e bağlanması öneriliyor; Streamable HTTP kullanan sunucuların Origin başlığını doğrulaması ve uygun olmayan değerlerde 403 dönmesi zorunlu — DNS rebinding’e karşı korunma bu; tüm bağlantılar için kimlik doğrulama öneriliyor. Yerel bir sunucu, host makinede kod çalıştıran bir süreçtir; spesifikasyon istemcinin bu süreci sandbox içinde ve asgari ayrıcalıkla çalıştırmasını, yerelde çalışan sunucunun da erişimi stdio’ya ya da kısıtlı bir IPC kanalına (örneğin unix domain socket) daraltmasını öneriyor. OAuth keşif URL’lerini çeken MCP istemcilerinin özel ve ayrılmış IP aralıklarına giden istekleri engellemesi öneriliyor; sunucu tarafında çalışan istemci kurulumlarında egress proxy kullanımı öneriliyor — sunucu tarafı istek sahteciliğini (SSRF) kapsayan kısım bu, yani bir sunucunun istemciyi iç ağ adreslerine yönlendirmesini engelleyen kural. Statik client ID kullanan proxy sunucuların, dinamik olarak kayıtlı her istemci için ayrı kullanıcı onayı alması zorunlu — confused deputy durumunu kapatan kural bu. Token audience izolasyonu ise zaten sunucunun sınır olduğunu söylüyor.

Bunları bir araya koyduğunuzda ortaya çıkan tablo şu: MCP sunucusu, kurumsal verinin ve kurumsal eylemlerin geçtiği yerdir. Model dışarıda çalışsa bile, hangi aracın var olduğu, hangi kaynağın okunabildiği, hangi çağrının hangi kimlikle yukarı akışa gittiği sunucuda belirlenir. Sunucu kurum ağında ve kurum kontrolündeyse, bu kararların tamamı denetlenebilir bir yerde durur. Araç açıklamalarının ve annotation’ların güvenilir bir sunucudan gelmedikçe güvenilmez kabul edilmesi gerektiği de spesifikasyonda yazılı — “güvenilir sunucu” tanımını kim yapıyorsa, sınırı da o çiziyor.

MCP’yi doğru konumlandırmanın en kısa yolu şu: bir dil modelini kurumsal bir sisteme bağlarken yazdığınız kodun büyük kısmı hiçbir zaman modelle ilgili değildi — keşif, şema, kimlik, yetki, hata biçimi ve yaşam döngüsüyle ilgiliydi. MCP bu kısmı standartlaştırıyor, gerisine karışmıyor. Bir MCP sunucusu tasarlarken sorulacak sorular da bu yüzden protokolle ilgili değil: hangi eylemler araç olarak açılacak, hangi veriler kaynak olarak okunabilir olacak, hangi kimlik hangi kapsamla hangi yukarı akış sistemine gidecek. Protokol bu soruların sorulacağı yeri netleştiriyor; cevapları hâlâ mimarinin işi.

Kaynaklar

• Model Context Protocol — spesifikasyon, 2025-11-25 revizyonu
• MCP spesifikasyonu — Yetkilendirme bölümü (OAuth 2.1 rolleri, RFC 9728, hata kodları)
• MCP spesifikasyonu — Sürümleme ve özellik yaşam döngüsü
• MCP Blog — The 2026-07-28 MCP Specification Release Candidate
• MCP Blog — MCP joins the Agentic AI Foundation (9 Aralık 2025)
• Anthropic — Introducing the Model Context Protocol (25 Kasım 2024)