MCP sunucusu nedir? 2026'da MCP ve MCP UI nasıl çalışır

1 Nisan 2025’te Invariant Labs, add adında bir araç yayımladı. Araç iki sayı alıyor ve toplamlarını döndürüyordu. Açıklamasında ise istemcinin arayüzünde görünmeyen, IMPORTANT ile işaretlenmiş bir blok daha vardı. Bu blok modele ~/.cursor/mcp.json ve ~/.ssh/id_rsa dosyalarını okumasını ve ikisini de boşta duran bir parametre üzerinden dışarı aktarmasını söylüyordu. Model itaat etti. Kullanıcı ise yalnızca bir toplama işlemi gördü.

Bu gösteri, MCP sunucularına dair bildiğim en faydalı giriş, çünkü iki yüzü aynı anda gösteriyor. Protokol tam olarak tasarlandığı gibi çalıştı: bir yapay zekâ istemcisi bir araç keşfetti, açıklamasını okudu ve onu çağırdı. Güven modeli ise henüz kimsenin kurmadığı kısımdı.

MCP sunucusu nedir

MCP sunucusu, araçları, verileri ve istemleri (prompt) Model Context Protocol (MCP) üzerinden yapay zekâ uygulamalarına sunan bir programdır. Resmi dokümantasyon MCP’yi “yapay zekâ uygulamalarını harici sistemlere bağlamak için açık kaynaklı bir standart” olarak tanımlar. Claude, ChatGPT, Visual Studio Code veya Cursor gibi bir yapay zekâ istemcisi sunucuya bağlanır, neler sunduğunu sorar ve bu yetenekleri kullanıcı adına çağırır.

Anthropic, MCP’yi 25 Kasım 2024’te duyurdu ve yanında altı hazır sunucu sundu: Google Drive, Slack, GitHub, Git, Postgres ve Puppeteer. OpenAI protokolü Mart 2025’te benimsedi. Google DeepMind nisan ayında onu izledi. Aralık 2025’te Anthropic, protokolü Linux Foundation çatısı altındaki yönlendirilmiş bir fon olan ve Anthropic, Block ve OpenAI’ın birlikte kurduğu Agentic AI Foundation’a bağışladı.

Sorun bağlantıların çoğalmasıdır. MCP’den önce GitHub’a erişmek isteyen her yapay zeka uygulaması kendi bağlayıcısını yazıyor, her sağlayıcı da her uygulama için ayrı bir bağlantı kuruyordu. On model ve on araç yüz entegrasyona kadar çıkabilirdi. MCP bunu yirmiye indirir: her istemci protokolü bir kez uygular, her sistem bir sunucu sunar.

Onu yapay zekâ entegrasyonlarının konteyneri olarak düşünün. Konteynerden önce her liman her yükü kendi vinçleri ve kendi ekibiyle elle yüklüyordu. Konteyner kutuyu standartlaştırdı; böylece her gemi, her vinç ve her kamyon her yükü taşıyabildi. Kutunun içine ne konacağını standartlaştırmadı ve içindekini hiçbir zaman denetlemedi. MCP de aynı pazarlıktır. İkinci yarıyı aklınızda tutun; güvenlik bölümünde geri dönecek.

MCP sunucusu nasıl çalışır

Güncel spesifikasyon, yani 2026-07-28 sürümü, üç rol arasında JSON-RPC 2.0 mesajları kullanır. Kendi tanımı üç satırdan ibarettir: host’lar “bağlantıyı başlatan LLM uygulamalarıdır”, istemciler “host uygulamasının içindeki bağlayıcılardır” ve sunucular “bağlam ve yetenek sağlayan hizmetlerdir.”

Host, istemci, sunucu

Host, içine yazdığınız uygulamadır: Claude Desktop, bir IDE ya da kendi agent’ınız. Onun içinde her sunucu bağlantısı için bir istemci çalışır. Sunucu ise karşı tarafta durur ve gerçek sistemle konuşur; bu bir Postgres veritabanı, GitHub API’si ya da diskinizdeki bir klasör olabilir. Modelin neyi göreceğine ve kullanıcının neyi onaylaması gerektiğine host karar verir. Arkadaki sistemin ne yapacağına ise sunucu karar verir.

1. Host Claude Desktop · bir IDE · kendi agent'ınız

   araçları modele gösterir, kullanıcıdan onay ister

2. İstemci her sunucu bağlantısı için bir tane

   stdio veya Streamable HTTP üzerinden JSON-RPC konuşur

3. MCP sunucusu araçlar · kaynaklar · istemler

   ne sunduğunu tanımlar ve çağrıları çalıştırır

4. Arkadaki sistem veritabanı · SaaS API'si · yerel dosyalar

   işi yapar

Araçlar, kaynaklar ve istemler

Bir sunucu üç tür şey sunabilir:

• Araçlar, modelin çalıştırabileceği fonksiyonlardır: create_issue, query_orders, send_email. Her birinin bir adı, bir açıklaması ve girdileri için bir JSON Schema’sı vardır.
• Kaynaklar, kullanıcının veya modelin okuyacağı bağlam ve verilerdir: bir dosya, bir veritabanı şeması, bir kayıt.
• İstemler, kullanıcının seçebileceği şablonlu mesajlar ve iş akışlarıdır; örneğin “bu pull request’i özetle”.

İlginin çoğunu araçlar alır, çünkü eyleme geçerler. Riskin çoğunu taşımalarının nedeni de budur.

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

2026-07-28 revizyonu MCP’yi durumsuz (stateless) hale getirdi. Artık initialize el sıkışması yok; her istek protokol sürümünü ve istemcinin yeteneklerini bir _meta alanında taşıyor ve sunucuların, istemcinin neyi desteklediklerini baştan sorabilmesi için bir server/discover metodu uygulaması gerekiyor. Tek bir araç çağrısı artık şöyle ilerliyor:

1. Kullanıcı ister: bu hata için bir kayıt oluştur

2. Adım 1

   Keşif

   • İstemci sürümler ve yetenekler için server/discover çağırabilir
3. Adım 2

   Araçları listele

   • tools/list adları, açıklamaları ve girdi şemalarını döndürür
4. Adım 3

   Model bir araç seçer

   • Host, araç tanımlarını modele iletir
5. Adım 4

   Kullanıcı onayı

   • Spesifikasyona göre host'lar herhangi bir aracı çağırmadan önce açık onay almalıdır
6. Adım 5

   Çağrı

   • Argümanlarla tools/call, protokol sürümü _meta içinde

7. Eksik girdi mi var? Sunucu input_required döndürür; istemci yanıtlarla yeniden dener

   Adım 6

   Sonuç

8. Sonuç, bağlam olarak modele geri döner

Adım 6 bu revizyonda yeni. Daha fazla bilgiye ihtiyaç duyan bir sunucu artık istemciye kendi isteğini göndermiyor. input_required olarak işaretlenmiş bir sonuç döndürüyor, istemci yanıtı topluyor ve orijinal çağrıyı yeniden deniyor. Spesifikasyon buna Multi Round-Trip Request kalıbı diyor.

Taşıma katmanları: stdio ve Streamable HTTP

Spesifikasyon iki standart taşıma katmanı tanımlar:

• stdio: istemci sunucuyu bir alt süreç olarak başlatır ve standart girdi ile çıktı üzerinden satır sonlarıyla ayrılmış JSON-RPC mesajları alışverişi yapar. Yerel sunucuların çoğu böyle çalışır ve bu, sunucunun sizin makinenizde sizin yetkilerinizle çalıştığı anlamına gelir.
• Streamable HTTP: her mesaj tek bir uç noktaya yapılan bir HTTP POST’tur ve yanıtlar bir JSON nesnesi ya da isteğe özgü bir olay akışı olarak döner. Uzak, barındırılan sunucular böyle çalışır.

Eski HTTP+SSE taşıma katmanı resmi olarak kullanımdan kaldırıldı. 2026-07-28 revizyonu ayrıca protokol düzeyindeki oturumları ve Mcp-Session-Id başlığını kaldırdı; çağrılar arasında duruma ihtiyaç duyan bir sunucu artık kendi tanıtıcısını üretiyor ve onu sıradan bir araç argümanı olarak geri alıyor.

Yetkilendirme

MCP’de yetkilendirme isteğe bağlıdır ve yalnızca HTTP için geçerlidir. Spesifikasyon, stdio üzerinde sunucuların kimlik bilgilerini ortamdan almasını önerir. HTTP üzerinde ise korunan bir MCP sunucusu bir OAuth 2.1 kaynak sunucusu gibi davranır. İstemcilerin yetkilendirme sunucusunu bulabilmesi için OAuth Protected Resource Metadata (RFC 9728) yayımlamak zorundadır. İstemciler, bir token’ın tam olarak hangi sunucu için olduğunu belirtmek zorundadır (RFC 8707 kaynak göstergeleri). Sunucular kendileri için verilmemiş her token’ı reddetmek zorundadır ve güvenlik kılavuzu, bir istemcinin token’ını değiştirmeden alt akıştaki bir API’ye iletmek anlamına gelen “token passthrough” yöntemini açıkça yasaklar.

Bu son kural göründüğünden daha önemli. Aldığı her token’ı aktaran bir sunucu, token taşıyan herkes için bir proxy’ye dönüşür.

MCP UI ne katar: arayüz döndüren sunucular

Bir kullanıcının kırk satırı karşılaştırması, on iki alanlı bir formu düzenlemesi ya da bir grup değişikliği tek tek onaylaması gerektiği anda metin yanıtlar işe yaramaz hale gelir. “MCP UI”, insanların bu sorunun çözümünü aradığı addır: sunucu, yapay zekâ istemcisinin içinde, sohbetin hemen yanında görüntülenen etkileşimli bir arayüz döndürür.

Durumu doğru anlatmak gerekir. Fikir, topluluk projesi MCP-UI olarak başladı. OpenAI, Apps SDK içinde benzer bir mekanizma geliştirdi. MCP projesi 21 Kasım 2025’te iki tarafla ortak bir standart önerdi; 26 Ocak 2026’da MCP Apps’i ilk resmî MCP uzantısı olarak yayımladı. MCP-UI paketleri artık bu belirtimi uygular ve gelecekteki geliştirmeler için topluluk deneme alanı işlevi görür.

Yani bugün MCP UI, MCP Apps demek. Resmi, ama çekirdek protokol değil, bir uzantı. Uzantılar isteğe bağlıdır: hem istemcinin hem sunucunun desteklemesi gerekir ve dokümantasyon açıkça “host desteğinin istemciye göre değiştiğini” söyler. MCP Apps dokümantasyonu destekleyen host’lar olarak Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam ve Archestra.AI’ı sayar. Araçları arayüz döndüren bir sunucu, yalnızca metin gösteren bir istemci için de çalışmaya devam etmek zorundadır.

Mekanik olarak MCP’nin kendi parçalarını yeniden kullanır:

1. Bir aracın açıklaması, bir ui:// kaynağını işaret eden bir _meta.ui.resourceUri içerir.
2. Host bu kaynağı, yani betikleriyle birlikte bir HTML sayfasını getirir ve araç çağrılmadan önce önceden yükleyebilir.
3. Host onu, üst sayfayı, çerezlerini veya depolamasını okuyamayan korumalı (sandbox) bir iframe içinde görüntüler.
4. Uygulama ve host, MCP’nin JSON-RPC lehçesiyle postMessage üzerinden konuşur. Uygulama araç çağrısı isteyebilir; hangilerine izin verileceğine host karar verir.

Maliyet gerçek. Artık başkasının uygulamasının içine, beyan etmeniz gereken bir içerik güvenliği politikasıyla, kontrol etmediğiniz görüntüleme kurallarıyla ve onu yok sayan her host için bir metin yedeğiyle birlikte bir web ön yüzü gönderiyorsunuz. Kazanç ise onay işinin bir sohbet dökümü olmaktan çıkması. Dokümantasyonun uygun kullanım örnekleri listesi “gider raporlarını onaylamak, kod değişikliklerini incelemek ya da sorunları önceliklendirmek” ile biter ve dürüst merkez de budur: MCP UI süslemede değil, kararlarda en iyisidir.

Salt okunur bir Tajo örneği

Tajo’nun Alto MCP yüzeyinde, bağlı çalışma alanında saklanan kişileri arayan query_contacts bulunur. Var olan bir kişiyi e-posta adresiyle arayın; dönen kimliği, e-posta izin durumunu ve son görülme zamanını inceleyin. Ayrı get_contact_topic_status aracı bu kişinin konu aboneliklerini okur.

Bunlar çalışma alanı okumalarıdır. Sağlayıcıdan güncel bir anlık görüntü almaz, senkronizasyon başlatmaz veya mesaj göndermez. Her sağlayıcı bağlayıcısının çalıştığını da göstermez. Eksik ya da eski veriyi kaynağında araştırın. Boş sonuç, kişinin Brevo’da bulunmadığını kanıtlamaz.

Desteklenen istemciyi bağlamak ve yetkili çalışma alanınızın gerçekten sunduğu araçları görmek için Tajo MCP belgelerini kullanın. Ana uygulama MCP Apps’i destekliyorsa etkileşimli panel incelemeyi kolaylaştırabilir; metin sonucu yine de sonucu açıklamalıdır.

Araç çağrısı kalıcı senkronizasyon değildir

Düzenli senkronizasyon ayrıca zamanlama, kararlı kayıt kimliği, kaydedilmiş ilerleme, yeniden deneme kararları ve tamamlanan yazma kayıtları gerektirir. Bunlar işi yürüten uygulamanın sorumluluğundadır. MCP araç erişimini standartlaştırır; araçların listelenmesi bu iş kurallarını sağlamaz.

Zaman aşımından sonra bir okuma genellikle tekrarlanabilir. Gönderim veya ödeme ise gerçekleşmiş olabilir. Yeniden denemeden önce yürütme kaydını koruyup sonucu uzlaştırın. Modelin güven puanı eyleme izin vermez ve tekrarı güvenli yapmaz.

Somut bir kişinin hedefe yazılması için Brevo API kılavuzuna bakın. Hesaplanan alanların ne zaman ayrı, bakımı yapılan bir senkronizasyon gerektirdiğini reverse ETL açıklar.

Güvenlik faturası protokolle birlikte gelir

İtirazı eksiksiz dile getirmek gerekir: “MCP, olasılıksal bir modele veri silebilen ve e-posta gönderebilen fonksiyonların bir listesini verir, sonra bunları tanımlamak için yabancıların yazdığı metne güvenir. Bu bir entegrasyon standardı değil. Spesifikasyonu olan bir tedarik zinciri saldırısı.” Bunun çoğu doğru. Spesifikasyon da öncüle katılıyor. Güvenlik bölümü, araçların “keyfi kod çalıştırmayı temsil ettiğini ve gereken özenle ele alınması gerektiğini”, araç açıklamalarının “güvenilir bir sunucudan alınmadıkça güvenilmez kabul edilmesi gerektiğini” ve MCP’nin “bu güvenlik ilkelerini protokol düzeyinde uygulayamayacağını” söylüyor.

Bugüne kadarki sicil şöyle:

• Araç zehirleme (tool poisoning). Invariant Labs’in Nisan 2025 tarihli ifşası, yani yukarıdaki add aracı. Aynı yazı, bir sunucunun siz onayladıktan sonra bir aracın açıklamasını değiştirdiği rug pull (halı çekme) saldırısını ve kötü niyetli bir sunucunun modelin güvenilir bir sunucuya karşı davranışını yeniden yazdığı shadowing (gölgeleme) saldırısını da anlattı.
• Yerel sunucu ihlali. Temmuz 2025’te JFrog, mcp-remote paketinin 0.0.5 ile 0.1.15 arasındaki sürümlerinde, kötü niyetli bir sunucunun kullanıcının makinesinde komut çalıştırmasına izin veren CVE-2025-6514 açığını duyurdu. Aynı yaz CVE-2025-49596, varsayılan olarak kimlik doğrulama olmadan gelen Anthropic’in kendi MCP Inspector aracını vurdu.
• Kapsam şişmesi. Resmi güvenlik en iyi uygulamaları bu kalıbı adıyla anıyor: bir sunucu tüm kapsamları listelediği ve istemci de hepsini istediği için token’lara en baştan files:* veya admin:* verilmesi.
• Resmi kaygı. Mayıs 2026’da ABD Ulusal Güvenlik Ajansı (NSA), MCP’nin “hızlı yayılışının güvenlik modelinin gelişimini geride bıraktığını” söyledi.

İtirazın yanıldığı yer sonuçtur. Çözüm hiçbir zaman modelleri sistemlere bağlamayı bırakmak değildi; ekipler bunu zaten istemlere ve betiklere yapıştırılmış ham API anahtarlarıyla, hiçbir denetim izi olmadan yapıyordu. Çözüm, bir MCP sunucusuna diğer ayrıcalıklı bağımlılıklar gibi davranmaktır:

• Sunucuları yalnızca, MCP dışında da aynı kimlik bilgilerini emanet edeceğiniz kaynaklardan kurun.
• Uzun ömürlü anahtarlar tutan yerel ikili dosyalar yerine OAuth ve dar kapsamlı uzak sunucuları tercih edin.
• Her yazma işlemi için insan onayı şart koşun ve kimin neyi onayladığını kaydedin.
• Sunucu sürümlerini sabitleyin ve bir aracın açıklaması değiştiğinde yeniden inceleyin.
• Tüm API’yi değil, göreve göre biçimlenmiş araçları açın; model hiç açılmamış bir silme uç noktasını kötüye kullanamaz.

Protokol kutuyu standartlaştırdı. Yükü denetlemek hâlâ sizin işiniz.

MCP sunucusu kurun ya da mevcut olanı kullanın

mcp.so gibi herkese açık dizinler topluluğun kurduğu sunucuları listeler ve birçok SaaS sağlayıcısı kendi sunucusunu yayımlar. Örneğin Brevo, ayrı sunuculara da bölünmüş bir MCP sunucusu sunar; böylece bir agent’a kampanyalar olmadan yalnızca kişiler verilebilir. Karar emekten çok, araçların biçimine kimin sahip olması gerektiğiyle ilgilidir.

Agent'ınız hangi MCP sunucusunu kullanmalı?

1. Sağlayıcı görevi kapsayan bir sunucu yayımlıyor

   Sağlayıcının sunucusunu kullanın

   API'yi takip eder ve bakımını sağlayıcı yapar.

2. Tek bir sistem, ama daha az ya da daha güvenli işlem gerekiyor

   Kapsamı daraltarak kullanın

   En dar kapsamları verin ve yalnızca agent'ın ihtiyaç duyduğu araç gruplarını açın.

3. İç veriler ya da sunucusu olmayan bir sistem

   Küçük bir sunucu kurun

   Kendi API'nizin üzerinde, kendi kimlik doğrulamanızla göreve göre biçimlenmiş birkaç araç.

4. Görev iki veya daha fazla sisteme yayılıyor

   Yönetişimli bir katman kurun ya da benimseyin

   Hepsi için tek bir araç seti, onay kuralları ve denetim geçmişi.

Temel bir sunucu kurmak işin kolay kısmı. Resmi bir SDK ile tek araçlı, çalışan bir stdio sunucusu bir öğleden sonralık iştir. Maliyet sonra gelir: HTTP sürümü için OAuth, kullanımdan kaldırmalar (2026-07-28 revizyonu Roots, Sampling ve Logging ile Dynamic Client Registration’ı kullanımdan kaldırdı) ve bir modelin doğru okuyacağı araç açıklamaları yazmanın sürekli işi. Bir API’yi her uç nokta için bir araçla sarmak en yaygın hatadır. Her araç açıklaması, modelin okuyup tartması gereken bir metindir; bu yüzden göreve göre biçimlenmiş kısa bir araç listesi, tüm API yüzeyinden daha iyidir.

MCP, API’ler, entegrasyonlar ve iPaaS

MCP, API’lerin yerini almaz. Neredeyse her MCP sunucusu bir API’nin sarmalayıcısıdır. İş hâlâ kendi hız sınırları, veri modeli ve tuhaflıklarıyla API’de yapılır. MCP’nin değiştirdiği şey onu kimin çağırabildiğidir: çağrıyı önceden koda gömen bir geliştirici yerine, çalışma anında bir açıklamaya bakarak seçen bir model.

Bu ayrım, MCP’nin sıkça karıştırıldığı diğer iki şeyle arasına net bir çizgi çeker:

• Entegrasyonlar ve iPaaS (başlıca platformlar burada karşılaştırılıyor) veriyi bir zamanlamaya ya da tetikleyiciye göre, deterministik biçimde taşır; birinin sohbette olup olmaması fark etmez. 40.000 siparişin bir CRM’e gecelik senkronizasyonu, bir modelin 40.000 araç çağrısı yapmaya karar vermesine bağlı olmamalıdır.
• Ters ETL (reverse ETL) modellenmiş veriyi bir veri ambarından operasyonel araçlara geri iter. Ters ETL nedir ve ne zaman uygundur ayrı bir konudur ve bir sohbet değil, bir veri hattıdır.
• MCP ise bir kişinin ya da bir agent’ın bu sistemler genelinde ihtiyaç anında soru sorması, inceleme yapması veya eyleme geçmesi gereken anlar içindir.

Hata iki yönde de yapılır. Bazı ekipler toplu senkronizasyon için MCP sunucuları kurar ve yavaş, pahalı, tekrarlanamayan veri hatları elde eder. Diğer ekipler özenle entegrasyonlar kurar, sonra bunları sorgulasın diye yapay zekâ asistanlarına ham bir API anahtarı verir ve yönetişimsiz bir yan kapı elde eder.

Desteklenen bir entegrasyonda kalıcı iş ile onu inceleyen araçların açık bir izin sınırını paylaşması gerekir. Belirli iş akışının bağlayıcısını, izinli eylemlerini ve kaydedilen sonuçlarını doğrulayın. Entegrasyon belgeleri, kurulum yönergeleriyle üretim kanıtı hâlâ gereken yolları ayırır. MCP ayrı onaylı araçlar sunabilir; liste, düzenli senkronizasyonun veya bütün kontrollerin etkin olduğunu kanıtlamaz.

MCP 22 ayda altı referans sunucudan, Claude, ChatGPT, VS Code ve Cursor’ın hepsinin konuştuğu bir Linux Foundation projesine dönüştü. Bir modeli bir sisteme bağlamak artık işin ucuz kısmı. Orada neyi yapmasına izin verildiğine karar vermek ise asıl iş.