MCP Nedir? Model Context Protocol ve Yapay Zeka Ajanları

MCP (Model Context Protocol), bir yapay zeka modelinin dış sistemlere — veritabanına, dosyalara, API'lere, kurumsal uygulamalara — tek ve standart bir arayüz üzerinden bağlanmasını sağlayan açık protokoldür. Anthropic Kasım 2024'te yayımladı; resmî protokol sitesinde spesifikasyon ve SDK'lar herkese açık duruyor.

İlk kez duyuyorsanız meseleyi şöyle kurun. Dil modeli tek başına yalnızca metin üretir; sipariş tablosunu okuyamaz, dosya açamaz, CRM'e not düşemez. Bunları yapabilmesi için ona "araç" vermek gerekir. MCP'den önce her araç, her uygulama için ayrı ayrı elle yazılırdı: aynı ticket sistemine bağlanan 3 ajanınız varsa 3 farklı entegrasyon kodu bakımdaydı. MCP, bu bağlantının biçimini standarda bağlar. Bir sistemi bir kez MCP sunucusu olarak tanımlarsınız; protokolü konuşan her yapay zeka istemcisi o sistemi kullanabilir.

Yaygın benzetme: yapay zeka uygulamaları için USB-C. Cihaz başına ayrı kablo taşımak yerine tek bir soket.

Pratikte nasıl bir şey olduğunu merak ediyorsanız: açık kaynak referans sunucu deposunda hazır duran bir MCP sunucusunu bir istemciye tanıtmak, kimlik bilgisi elinizde olduğunda 5-10 satırlık yapılandırma ve 10 dakikalık iştir. Kendi sunucunuzu yazmak daha uzun sürer — o kısma aşağıda geliyoruz.

MCP hangi sorunu çözüyor?

Bir dil modelinin işe yarar bir yapay zeka ajanı olabilmesi için CRM'den kayıt okuması, veritabanında sorgu çalıştırması ya da sipariş sistemine yazması gerekir. Bu yeteneklere araç (tool) denir ve MCP'den önceki tablo klasik N×M problemiydi: N tane yapay zeka uygulaması, M tane sistem, teorik olarak N×M ayrı entegrasyon. 4 ajan uygulaması ile 6 kurumsal sistem, en kötü durumda 24 ayrı entegrasyonun bakımı demek. Faturası şöyle geliyordu:

• Tekrarlanan iş: Aynı veritabanı ya da ticket sistemi bağlantısı her ajan projesinde baştan yazılır.
• Her entegrasyon kendi kimlik doğrulamasını ve anahtar saklama yöntemini getirdiği için ortada denetlenebilir tek bir yetki noktası kalmaz.
• Sağlayıcıya bağımlılık: Araç tanımları belirli bir model sağlayıcısının biçimine gömüldüğünde, model değiştirmek entegrasyon katmanını yeniden yazmak anlamına gelir.
• Hedef sistemin API'si değiştiğinde o sisteme dokunan bütün ajanlar tek tek güncellenir. 5 ajanınız varsa 5 ayrı yerde.

MCP bu ilişkiyi N+M'e indirir: her sistem için 1 sunucu, her uygulama için 1 istemci. Aynı 4 uygulama ve 6 sistem, 24 entegrasyon yerine 10 bileşenle karşılanır. Aradaki sözleşme sabit kalır.

MCP nasıl çalışır? İstemci, sunucu ve araçlar

MCP, JSON-RPC 2.0 üzerine kurulu bir istemci–sunucu protokolüdür ve 3 tarafı vardır. Spesifikasyon tarihli sürümlerle ilerliyor; bu yazının dayandığı sürüm 2025-06-18 revizyonudur.

Host ve istemci (client)

Host, kullanıcının karşısındaki yapay zeka uygulamasıdır: bir sohbet arayüzü, bir kod editörü ya da kendi kurduğunuz ajan çalışma zamanı. Host, bağlanacağı her MCP sunucusu için ayrı bir istemci örneği açar. İstemci, el sıkışma sırasında sunucunun hangi yetenekleri sunduğunu öğrenir ve bunları modele bildirir.

Sunucu (server)

MCP sunucusu, belirli bir sistemin yeteneklerini protokolün diliyle dışa açan küçük bir programdır. Bir dosya sistemi sunucusu "dosya oku" ve "dizin listele" verir; bir veritabanı sunucusu "şemayı getir" ve "sorgu çalıştır" verir. Yerel makinede çalışabileceği gibi uzak bir servis olarak da barındırılabilir.

Araçlar, kaynaklar ve istemler

• Araçlar (tools): Modelin çağırabileceği eylemler. Her aracın adı, açıklaması ve girdi şeması vardır; model bu tanıma bakarak hangi aracı ne zaman çağıracağına karar verir.
• Kaynaklar (resources): Modele bağlam olarak verilebilecek okunabilir veriler — bir doküman, bir tablo şeması, bir log dosyası.
• İstemler (prompts) ise sunucunun sunduğu hazır ve parametreli iş akışı şablonlarıdır; tekrar eden görevleri standart hale getirmeye yararlar.

Protokol istemci tarafında da yetenek tanımlar. En sık karşılaşacağınız 2 tanesi, sunucunun istemciden model çıktısı talep etmesi (sampling) ve eksik bilginin kullanıcıya sorulmasıdır (elicitation). Taşıma katmanında 2 seçenek tanımlı: yerel süreçler için stdio, uzak sunucular için HTTP tabanlı akış.

Bir çağrı nasıl ilerler?

Kullanıcı "geçen haftanın açık taleplerini özetle" dedi diyelim. Zincir 6 adımda ilerler: istemci bağlı sunuculardan araç listesini alır, listeyi modele sunar, model uygun aracı ve parametreleri seçer, istemci çağrıyı sunucuya iletir, sunucu gerçek sistemle konuşup sonucu döndürür, model dönen veriyle yanıtı hazırlar. Model hiçbir aşamada hedef sisteme doğrudan dokunmaz; her çağrı sunucudan geçer. Güvenlik modelinin dayandığı ayrım da budur.

MCP sunucusu ne işe yarar?

MCP sunucusu 3 iş birden görür. Kurumsal API'nin karmaşık uç noktalarını modelin anlayabileceği sade araçlara çevirir. Hangi işlemlerin mümkün olduğunun sınırını çizer — salt okunur bir sunucu tanımladıysanız ajan ne kadar ısrarcı olursa olsun yazma işlemi yapamaz. Ve aynı sunucu farklı ajanlar, farklı ekipler, farklı modeller tarafından ortak biçimde kullanılır.

Az konuşulan bir faydası daha var: test edilebilirlik. Araç davranışını ajandan bağımsız doğrulayabildiğiniz için "model mi yanlış karar verdi, araç mı yanlış sonuç döndürdü" sorusu net biçimde ayrışır. Bu ayrım olmadan ajan hata ayıklaması gerçekten yorucu bir işe dönüşüyor.

MCP öncesi ve MCP ile: karşılaştırma

MCP öncesi ile MCP sonrası tablo 6 başlıkta ayrışıyor:

MCP nasıl kullanılır?

Hazır bir MCP sunucusuna bağlanmak

Hazır bir MCP sunucusuna bağlanmak, sunucuyu istemcinizin yapılandırmasına tanıtmakla başlar: nasıl çalıştırılacağı, hangi kimlik bilgisiyle bağlanacağı, hangi kapsamlara sahip olacağı. Bağlantı kurulduğunda istemci araç listesini kendisi alır. Bizim gözlemimizde işin 10 dakikası yapılandırmaya, kalan 1-2 saati o kimlik bilgisini doğru kapsamla çıkarmaya gidiyor.

2 karar kritiktir: hangi sunucuların bağlanmasına izin verdiğiniz ve hangi işlemlerin kullanıcı onayı istediği.

Kendi MCP sunucunuzu geliştirmek

Resmî SDK'lar protokol ayrıntılarının çoğunu üstlenir; tek aracı olan çalışan bir sunucu 2-4 saatte yazılır. Gerçek bir kurumsal sistemi düzgün açmak ise — şema tasarımı, yetki, hata mesajları, yanıt sadeleştirme dahil — 2-3 haftalık bir iştir. Kurduğumuz sistemlerde o sürenin 2 haftasını araç tanımlarının kalitesi yiyor; protokol katmanının kendisi 1 günlük iş.

• Kapsamı dar tutun. Tüm API'yi olduğu gibi dışa açmayın; ajanın gerçekten ihtiyaç duyduğu işlemleri tanımlayın.
• Araç adı ve açıklaması modelin tek yol göstericisidir. En çok zaman kaybettiren hata sınıfı bu: ajan tuhaf davranır, model hatası sanılır, saatlerce log okunur, sonunda ortaya bir cümlelik araç açıklamasının 2 farklı işi çağrıştırdığı çıkar.
• Hata mesajlarını modele okunur verin. "400 Bad Request" yerine eksik alanın adını döndüren bir mesaj, ajanın kendini düzeltmesini sağlar.
• Salt okunurla başlayın, yazma yeteneklerini kademeli ekleyin.
• Devasa JSON gövdeleri döndürmeyin. 50 alanlık bir kaydın 10 alanı yetiyorsa 10 alan dönün.

Araç sayısının da bir sınırı var. Bağladığınız her sunucunun araç tanımları her istekte modelin bağlamına giriyor. Bizim ölçümümüzde 30 araç tanımı, henüz tek bir çağrı yapılmadan 3.000-6.000 token yer kaplıyor. Saha gözlemimiz şu: bir ajanın önüne konan araç sayısı 20'yi geçtikten sonra yanlış araç seçimi görünür biçimde artıyor, 40'ı geçtiğinde ajanı ikiye bölmek ya da araçları göreve göre gruplayıp çalışma anında yüklemek dışında çare kalmıyor.

Asıl kazanç "entegrasyon kolaylığı" değil

MCP anlatılırken en çok öne çıkarılan başlık entegrasyon maliyetinin düşmesi. Doğru ama meselenin can alıcı kısmını ıskalıyor.

Önemli olan şu: MCP'den önce bir ajanın araç seti derleme zamanında sabitti. Yeni bir yetenek eklemek, uygulamanın kodunu değiştirip yeniden dağıtmak demekti. MCP ile araç seti çalışma anında keşfedilen bir şeye dönüşüyor. Ajan çalışırken bir sunucu bağlarsınız, yeteneği o anda kazanır; kaldırırsınız, kaybeder.

Çalışma anında keşif, ajan tasarımını doğrudan değiştiren bir farktır. Göreve göre araç seti yükleyebilir, kullanıcı rolüne göre farklı araç kümeleri açabilir, riskli araçları yalnızca gerektiği anda devreye alabilirsiniz. 20-40 araç eşiğinin pratik cevabı da tam burada duruyor: ajanın önüne aynı anda 8-12 araç koyup gerisini göreve göre yüklemek. Entegrasyon maliyetindeki düşüş bunun yanında küçük kalır.

Kurumsal senaryolar

MCP, "sohbet botuna internet erişimi vermek" gibi dar bir konu değil; kurum içi sistemlerin ajanlara denetimli biçimde açılması. 5 tipik kullanım alanı:

• Müşteri operasyonu: Ajanın talep kayıtlarını okuması, sipariş durumunu sorgulaması, yanıt taslağı hazırlaması.
• Doküman arşivi, prosedürler ve teknik dokümantasyonun kaynak olarak modele açılması.
• Raporlama: Veri ambarına salt okunur sorgu araçları tanımlayıp doğal dille rapor üretilmesi.
• Stok, planlama ve bakım sistemlerinden durum bilgisi çekilmesi.
• Depo, hata takip ve dağıtım sistemlerinin tek protokol üzerinden geliştirici ajanlarına bağlanması.

Beşinde de sonucu belirleyen aynı şey: araçların ne kadar iyi tasarlandığı. Model seçimi bu listede 2. sırada geliyor.

Güvenlik ve yetkilendirme: bir ajana araç vermek risk de açar

MCP yalnızca yetenek eklemez, saldırı yüzeyi de ekler. Metin üreten bir modeli, sisteminizde gerçekten işlem yapabilen bir aktöre dönüştürüyorsunuz. Dikkate alınması gereken 5 başlık var:

• İstem enjeksiyonu: Araçtan dönen içerik (bir e-posta gövdesi, bir web sayfası, bir kayıt notu) modele talimat vermeye çalışır. OWASP'ın büyük dil modeli uygulamaları için ilk 10 risk listesi bu maddeyi 1. sıraya koyuyor. Araç çıktısı her zaman veri olarak ele alınmalı, talimat olarak değil.
• Aşırı geniş yetki: Kolaylık olsun diye verilen tam erişimli hesaplar, ajanın tek bir hatasını sistem çapında bir hataya dönüştürür.
• Sunucu kendi yüksek yetkisiyle kullanıcı adına işlem yaparsa, kullanıcının görmemesi gereken verilere erişim açılır. Buna "kafası karışmış vekil" deniyor ve çözümü tek: yetki kontrolü sunucu tarafında da yapılacak. Protokolün yetkilendirme bölümü bu noktayı OAuth 2.1 kapsamları üzerinden tanımlıyor.
• Güvenilmeyen sunucular: Üçüncü taraf bir sunucu, araç tanımlarını sonradan değiştirerek davranışını dönüştürebilir. Kaynağı bilinmeyen sunucular kurumsal ortama bağlanmamalı; bağlananlar sürümlenip gözden geçirilmelidir.
• Token'ların model bağlamına ya da loglara düşmesi ciddi bir risktir. Kimlik bilgilerinin yeri sunucu tarafıdır; istem içine taşındığı anda kontrolü kaybettiniz demektir.

Kurduğumuz ajan sistemlerinde en sık kırılan yer, uzak ara, yetkilendirme oluyor. Senaryo neredeyse hep aynı: prototip aşamasında hız kazanmak için tam yetkili bir servis hesabı tanımlanır, o hesap üretime kadar taşınır ve kimse geri dönüp kapsamı daraltmaz. 6-12 ay sonra "ajan bu tabloyu neden görebiliyor" sorusu geldiğinde izi hep o ilk haftaki kısayola kadar sürüyorsunuz.

Uygulanabilir önlemler 6 maddelik kısa bir liste: yıkıcı işlemler için insan onayı, sunucu izin listesi, kapsam bazlı kimlik doğrulama, hassas sistemler için kendi altyapınızda barındırma, salt okunur varsayılan ve bütün araç çağrılarının denetim kaydına alınması. Bunların hiçbiri egzotik değil; sadece prototip hızının kurbanı oluyorlar.

MCP'nin ajan mimarisindeki yeri

Bir ajan sistemini 4 katman olarak düşünebilirsiniz: muhakemeyi yapan model, görevi planlayan ve döngüyü yöneten orkestrasyon katmanı, dış dünyaya erişimi sağlayan araç katmanı ve nihayet gerçek sistemler. MCP, bu tablonun araç katmanı standardıdır.

Katman ayrımını görmek işe yarıyor, çünkü MCP planlamayı, hafızayı, değerlendirme (evaluation) altyapısını veya maliyet yönetimini çözmüyor; 4 katmandan yalnızca 1'ini standarda bağlıyor. Bağlantı sorununu çözüyor ve tam da bu sayede geri kalan 3 katman üzerinde çalışacak alanı açıyor. Ajanların genel çalışma mantığını hatırlamak isterseniz yapay zeka ajanları (AI agents) nedir yazımıza göz atabilirsiniz. Kurumunuzdaki sistemleri ajanlara denetimli biçimde açmayı planlıyorsanız hizmetlerimiz sayfasında bu çalışmaların nasıl yürütüldüğünü bulabilirsiniz.

Sıkça Sorulan Sorular

MCP ile normal bir API arasındaki fark nedir?

API, yazılımların birbiriyle konuşma yöntemidir. MCP ise yapay zeka istemcilerinin araçları keşfetmesi ve çağırması için ortak bir sözleşme tanımlar. İkisi rakip değil: bir MCP sunucusu mevcut API'nin önünde durur ve onu modelin anlayacağı biçime çevirir.

MCP sunucusu kurmak için ne bilmek gerekir?

Temel düzeyde bir programlama dili ve hedef sistemin API'si yeterli; resmî SDK'lar protokol ayrıntılarının çoğunu üstleniyor. Zorluk daha çok tasarım tarafında: hangi araçların tanımlanacağına, girdi şemalarının nasıl kurgulanacağına ve yetki sınırlarının nerede çizileceğine karar vermek. Bu 3 karar iyi verilmediğinde protokolün hiçbir faydası kalmıyor.

MCP sadece belirli bir model ailesiyle mi çalışır?

Hayır. MCP açık bir standart ve model bağımsız tasarlandı; protokolü destekleyen herhangi bir istemci aynı sunucuya bağlanabilir. Modelin araç kullanma becerisi sonucun kalitesini etkiler, ama protokol tek bir sağlayıcıya bağlı değildir.

MCP kullanmak verilerimi dışarıya gönderir mi?

Tamamen mimariye bağlı. Sunucuyu kendi altyapınızda çalıştırırsanız veri kurum sınırları içinde kalır; modele yalnızca aracın döndürdüğü içerik gider. Üçüncü taraf bir uzak sunucuya bağlanırsanız o servisin veri işleme politikası devreye girer. Hassas sistemlerde kendi sunucunuzu barındırmak tercih edilen yol.

MCP, function calling'in yerini mi alıyor?

Hayır, onu tamamlıyor. Function calling modelin bir aracı çağırma kabiliyetidir; MCP ise o aracın nasıl tanımlanacağını, keşfedileceğini ve bağlanacağını standartlaştıran katman. Model yine fonksiyon çağırıyor — değişen şey, çağrılabilir araçların artık her uygulama için baştan yazılmaması.