MCP Mimari Diyagramı: Host'lar, İstemciler, Sunucular ve Taşıma Yöntemleri

Kodlama ajanınız depoyu okur, build'i kontrol eder ve takip sisteminize issue açar. Bu kurulumun tipik bir diyagramı, model ile araçlar arasında “MCP” etiketli tek bir kutu gösterir. Sonra bir güvenlik incelemecisi hangi sürecin ev dizininizi okuyabildiğini, hangi token'ın takip sistemine ulaştığını ve issue oluşturan çağrıyı kimin onayladığını sorar. Kutunun bir cevabı yoktur.

Model Context Protocol (MCP) kesin tanımlı bir mimariye sahiptir ve 2026-07-28 sürümü bu mimarinin bir kısmını değiştirdi. Bu yazı katılımcıları, protokol katmanlarını, taşıma yöntemlerini, özellikleri, tek bir araç çağrısını, uzak yetkilendirmeyi ve güven sınırlarını, kopyalayabileceğiniz bir diyagramla birlikte ele alıyor.

Host'lar, istemciler ve sunucular

MCP'den önce her AI uygulaması her araç için kendi adaptörüne ihtiyaç duyuyordu: Beş uygulama ve yirmi araç, 100'e kadar entegrasyon demekti. MCP ile 25 implementasyon (uygulama başına bir istemci, araç başına bir sunucu) tüm eşleşmeleri karşılar.

Host her sunucu için bir istemci oluşturur ve her istemci tam olarak tek bir sunucuyla konuşur. Model bir sunucuyu asla kendisi çağırmaz: Bir araç çağrısı ister; çağrının çalıştırılıp çalıştırılmayacağına ve hangi istemcinin göndereceğine host karar verir. Sunucular yalıtılmış kalır: Konuşmanın tamamını da birbirlerini de görmemelidirler.

İki katman ve 2026-07-28'de değişenler

Veri katmanı JSON-RPC 2.0'dır: istekler (id'leri asla null olmaz), sonuçlar, hatalar ve tek yönlü bildirimler. Taşıma katmanı bu mesajları taşır; çerçeveleme, iptal ve yetkilendirmeyle ilgilenir.

28 Temmuz 2026'da yayımlanan 2026-07-28 spesifikasyonu MCP'yi durumsuz hâle getirdi. Önceki sürümler her bağlantıyı, sürümü ve yetenekleri sabitleyen bir initialize el sıkışmasıyla açıyordu; HTTP sunucuları da Mcp-Session-Id ile bir oturumu sabitleyebiliyordu. Artık her istek kendi protokol sürümünü ve istemci yeteneklerini _meta içinde taşıyor; böylece sıradan bir round-robin yük dengeleyicinin arkasındaki herhangi bir sunucu örneğine düşebilir.

Eski SDK'larla yazılmış sunucular hâlâ el sıkışmayı bekler; bu yüzden iki dönemi de destekleyen istemciler önce yoklama yapar, gerekirse initialize'a geri döner. Yalnızca 2026-07-28 konuşan bir istemci, yalnızca eski sürümü destekleyen bir sunucuyu kullanamaz. Değişiklik günlüğü geriye dönük uyumluluğu bozan tüm değişiklikleri listeler.

Taşıma yöntemleri: stdio ve Streamable HTTP

Streamable HTTP, 2025-03-26 sürümünde HTTP+SSE taşımasının (bir GET akışı ve ayrı bir POST uç noktası) yerini aldı; HTTP+SSE artık resmen kullanımdan kaldırılmış durumda. Ağ geçitleri, gövdeyi ayrıştırmadan Mcp-Method ve Mcp-Name üzerinden yönlendirme ve hız sınırlama yapabilir; sunucular da başlıkları gövdeyle uyuşmayan istekleri reddeder. HTTP sunucuları DNS rebinding'e karşı Origin başlığını doğrulamak zorundadır; yerel sunucular da 127.0.0.1 adresini dinlemelidir.

Sunucu ve istemci özellikleri

Elicitation'ın form modu asla parola, API anahtarı ya da token istememelidir; URL modu ise bunun yerine kullanıcıyı istemcinin dışındaki bir sayfaya gönderir. Sampling, roots ve sunucu loglaması 2026-07-28'de kullanımdan kaldırıldı ve en erken, 28 Temmuz 2027'de ya da sonrasında yayımlanan ilk sürümde kaldırılabilir.

Adım adım tek bir araç çağrısı

Model, uzak bir sunucu üzerinden bir issue açar:

1. İsteğe bağlı olarak istemci, sürümleri ve yetenekleri öğrenmek için server/discover çağırır.
2. İstemci tools/list çağırır. Host tüm sunuculardan gelen listeleri birleştirir, çakışan adlara önek ekler ve sonucu modele verir.
3. Model create_issue ister. Host çağrıyı gösterir ve kullanıcı onaylar.
4. İstemci, aşağıda gösterilen tools/call isteğini gönderir.
5. Sunucunun bir onaya ihtiyacı varsa bir elicitation isteğiyle birlikte input_required döndürür. İstemci kullanıcıya sorar ve yanıtla birlikte sunucunun opak requestState değerini göndererek yeniden dener.
6. Sonuç complete olarak gelir. Araç hatası isError: true değerini ayarlar; böylece model kendini düzeltebilir.
7. Bir subscriptions/listen akışında gelen notifications/tools/list_changed, istemciye araçları yeniden listelemesini söyler.

POST /mcp HTTP/1.1
Host: mcp.tracker.example
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: create_issue

{"jsonrpc": "2.0", "id": 7, "method": "tools/call",
 "params": {"name": "create_issue",
  "arguments": {"title": "Login fails on Safari"},
  "_meta": {"io.modelcontextprotocol/protocolVersion": "2026-07-28",
   "io.modelcontextprotocol/clientInfo": {"name": "my-ide", "version": "1.4.0"},
   "io.modelcontextprotocol/clientCapabilities": {"elicitation": {}}}}}

{"jsonrpc": "2.0", "id": 7, "result": {"resultType": "complete",
 "content": [{"type": "text", "text": "Created issue #482"}], "isError": false}}

Uzak sunucular ve yetkilendirme

Uzak bir MCP sunucusu bir OAuth kaynak sunucusudur; token'ları, aynı firmanın ya da ayrı bir kimlik sağlayıcının işlettiği bir yetkilendirme sunucusundan gelir. İlk bağlantıda:

1. İstemci token olmadan çağrı yapar ve 401 alır; yanıtta genellikle sunucunun korumalı kaynak meta verilerini (RFC 9728) gösteren bir WWW-Authenticate başlığı bulunur.
2. Bu belge ya da yedek olarak /.well-known/oauth-protected-resource, yetkilendirme sunucusunu belirtir; istemci onun meta verilerini okur ve PKCE desteği ilan edilmemişse durur.
3. İstemci önceden kaydedilmiş bir istemci kimliği (client ID), bir Client ID Metadata Document (istemci kimliği olarak bir HTTPS URL'si) ya da 2026-07-28 ile kullanımdan kaldırılan dinamik istemci kaydını kullanır.
4. İstemci, PKCE (S256) ve MCP sunucusunu belirten bir resource parametresiyle (RFC 8707) authorization code akışını çalıştırır. Kullanıcı tarayıcıda giriş yapıp onay verir; istemci de yanıttaki iss değerini doğrular (RFC 9207).
5. Her istek Authorization: Bearer taşır. insufficient_scope içeren bir 403, kademeli yetkilendirmeyi (step-up) tetikler.

Sunucu yalnızca kendisi için verilmiş token'ları kabul eder ve onları asla başka bir yere aktarmaz: Upstream bir API'ye yapılan çağrılar ayrı bir token kullanır. OAuth 2.0 akış diyagramı PKCE'yi açıklıyor; yetkilendirme spesifikasyonu ise OAuth 2.1 taslağı üzerine kurulu kuralların tamamını içeriyor.

Güven sınırları nerede

stdio taşıması bir sandbox değildir: MCP'nin yerel sunucu güvenliği rehberi, bir stdio sunucusunun istemcinin yetkileriyle çalıştığını ve yalıtımın host'a ve makineyi işleten kişiye kaldığını söyler. Durumsuz bir sunucunun ürettiği durum handle'ı da bir kimlik bilgisi değildir; onu kimliği doğrulanmış kullanıcıya bağlayın. Tehdit modelleme veri akış diyagramı, bu tür sınırları STRIDE ile nasıl tek tek inceleyeceğinizi gösteriyor.

MCP mimari diyagramı

Nasıl okunur:

• Yeşil çerçeve tek bir güven alanıdır: Host, üç istemcisi ve iki stdio sunucusu, geliştiricinin işletim sistemi kullanıcısıyla çalışır.
• Sunucu başına bir istemci. 1. ve 2. istemciler stdin ve stdout kullanır; 3. istemci Streamable HTTP kullanır.
• Modelden çıkan gri kenarlar, host'un yönlendirdiği araç çağrılarıdır; sunucular modele asla doğrudan ulaşmaz.
• Mavi, ağı bir bearer token'la geçer. Kesikli mor, OAuth akışıdır ve yalnızca istemcinin geçerli bir token'ı olmadığında çalışır.
• Petrol mavisi, uzak sunucunun kendi token'ıyla kendi API'sini çağırmasıdır: Token aktarımı yok.
• Markdown bloğu, 2026-07-28 sürümünü özetler.

MCP mimari diyagramlarını net çizmek

• Sunucu başına bir istemci. Tek bir “MCP” kutusu, her sunucunun neyi görebildiğini gizler.
• Kenarları taşıma yöntemi ve içerikle etiketleyin: stdin ve stdout, bearer token'lı bir POST, bir OAuth akışı, örnek araç adları.
• Güven sınırlarını çerçeve olarak çizin: makine, host, her sağlayıcı. Sandbox'taki sunucuları işaretleyin.
• Yetkilendirme sunucusuna ve upstream API'lere ayrı düğümler verin; böylece token kaynakları ve token aktarımı yasağı görünür olur.
• Protokol sürümünü belirtin. 2026-07-28 diyagramında el sıkışma ya da oturum kimliği olmaz.
• Dışarıda bırakın: SDK'nın iç yapısı, araç listelerinin tamamı ve model sağlayıcısının altyapısı.

AI ajan mimari diyagramı, bu çağrıları çevreleyen ajan döngüsünü ele alıyor.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Geliştirici makinesi için Temel paketinden bir Çerçeve, onun içine de host için C4 Modeli paketinden bir Container sınırı ekleyin.
3. Sınırın içine ML paketinden bir Model ve istemciler için C4 Modeli paketinden üç Component (Bileşen) düğümü ekleyin; teknoloji alanlarına sırasıyla stdio, stdio ve Streamable HTTP yazın.
4. Yerel sunucular için C4 Modeli paketinden iki Container (Konteyner) düğümü ekleyip “stdin / stdout” kenarlarıyla bağlayın; aynı paketten bir Person (Kişi) ekleyip modele bağlayın.
5. Çerçevenin dışına C4 Modeli paketinden bir Sistem sınırı ekleyin; içine uzak sunucu için bir Container, onun API'si için bir External System (Harici sistem) ve Güvenlik paketinden bir Kimlik sağlayıcı koyun. Ardından bearer token, kesikli OAuth ve “own token” kenarlarını çizin.
6. Protokol bilgileriyle Temel paketinden bir Markdown bloğu, sınırları açıklamak için de Temel Metin öğeleri ekleyin.

MCP istemci yapılandırma dosyalarını okuyan ücretsiz bir araç yok; bu yüzden sunucuları kendiniz çizin ya da MCP spesifikasyonundaki gibi bir Mermaid akış şemasını Mermaid akış şemasından düzenlenebilir diyagrama aracına yapıştırın.

Bu yazının yazıldığı sırada (Kasım 2026) Archboard'un kendisi de https://getarchboard.app/mcp adresinde uzak bir MCP sunucusudur: Streamable HTTP; Archboard'un kendi yetkilendirme sunucusundan PKCE (S256) ile ve kaynak göstergesi (resource indicator) olarak bu URL'yle OAuth 2.1; Client ID Metadata Document ya da dinamik istemci kaydıyla istemci kaydı. MCP sunucusu dokümantasyonu araçlarını listeler, AI ajanları sayfası da uygulamanızı nasıl bağlayacağınızı gösterir.

Örnek 14 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

MCP host'u, istemcisi ve sunucusu arasındaki fark nedir? Host, IDE gibi AI uygulamasıdır. Her sunucu için bir istemci oluşturur; her istemci de araçları, kaynakları ve prompt'ları sunan tek bir sunucuyla özel bir bağlantı tutar.

MCP artık durumsuz mu? Evet, 2026-07-28 sürümünden beri: initialize el sıkışması yok, oturum kimliği yok ve her istek kendi sürümünü ve yeteneklerini taşıyor. Eski sürümlerdeki sunucular hâlâ el sıkışmayı kullanır.

MCP hangi taşıma yöntemlerini destekler? İki standart yöntem: yerel sunucular için stdio, uzak sunucular için Streamable HTTP. HTTP+SSE kullanımdan kaldırıldı; özel taşıma yöntemleri de JSON-RPC mesaj biçimini korumak zorundadır.

Yerel MCP sunucularının OAuth'a ihtiyacı var mı? Hayır. Spesifikasyona göre stdio sunucuları kimlik bilgilerini ortamdan almalıdır. Her birine dar kapsamlı bir token verin ve üçüncü taraf sunucuları sandbox'ta çalıştırın.

MCP'de token passthrough nedir? Bir MCP sunucusunun kendisi için verilmemiş bir token'ı kabul etmesi ya da istemcinin token'ını başka bir API'ye iletmesi. Spesifikasyon bunu yasaklar; upstream çağrılar sunucunun kendi token'ını gerektirir.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.