MCP Nedir? Model Context Protocol ve Yapay Zeka Ajanları

MCP (Model Context Protocol), bir yapay zeka uygulamasının 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 25 Kasım 2024'te yayımladı; Aralık 2025'te ise protokolü Linux Foundation bünyesindeki Agentic AI Foundation'a devretti. Belirtim ve SDK'lar resmî protokol sitesinde herkese açık.

İ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ı yazılırdı: aynı talep sistemine bağlanan üç ayrı ajan uygulamanız varsa üç ayrı entegrasyon kodunun bakımını yapardınız. MCP bu bağlantının biçimini standarda bağlar. Bir sistemi bir kez MCP sunucusu olarak tanımlarsınız; protokolü destekleyen istemciler o sistemi kullanabilir.

Resmî sitedeki benzetmeyle MCP, yapay zeka uygulamaları için bir USB-C girişi gibidir: cihaz başına ayrı kablo yerine tek bir standart soket.

Hazır sunucu arıyorsanız iki adres var. Resmî MCP Registry yayımlanmış sunucuları listeler. Referans sunucu deposundaki sunucular ise deponun kendi ifadesiyle eğitim amaçlı örneklerdir, üretime hazır çözüm olarak sunulmaz. Hazır bir sunucuyu bir istemciye tanıtmak çoğu zaman birkaç satırlık bir yapılandırmadır; kendi sunucunuzu yazmak ise daha uzun bir iştir, 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. Dört ajan uygulaması ile altı kurumsal sistem, en kötü durumda 24 ayrı entegrasyonun bakımı demek. Faturası şöyle geliyordu:

• Tekrarlanan iş: Aynı veritabanı ya da talep sistemi bağlantısı her ajan projesinde baştan yazılır.
• Dağınık yetki: 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.
• Değişikliğin yayılması: Hedef sistemin API'si değiştiğinde o sisteme dokunan bütün ajanlar tek tek güncellenir; beş ajanınız varsa beş ayrı yerde.

MCP bu ilişkiyi N+M'e indirir: her sistem için bir sunucu, her uygulama için bir istemci. Aynı dört uygulama ve altı 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 mesajlarıyla çalışan bir istemci–sunucu protokolüdür ve üç tarafı vardır. Belirtim (spesifikasyon) tarihli sürümlerle ilerliyor; bu yazı Ekim 2026 itibarıyla güncel olan 2026-07-28 sürümüne dayanıyor. Bu sürüm önemli bir değişiklik getirdi: protokol durumsuz (stateless) hâle geldi, bağlantı başındaki el sıkışma kaldırıldı ve her istek kendi protokol sürümünü ve istemci yeteneklerini kendisi taşıyor. Ayrıntılar sürüm değişiklik listesinde.

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; her istemci tek bir sunucuyla konuşur. İstemci, sunucunun hangi yetenekleri sunduğunu server/discover çağrısıyla öğrenebilir ve sunucudaki araçları 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): Sunucunun sunduğu hazır, parametreli mesaj ve iş akışı şablonları; tekrar eden görevleri standart hâle getirmeye yararlar.

Protokol, sunucunun istemciden ek bilgi isteyebildiği yolları da tanımlar. Güncel sürümde öne çıkanı, eksik bilginin kullanıcıya sorulmasıdır (elicitation). Önceki sürümlerde bulunan, sunucunun istemciden model çıktısı istemesi (sampling) ve çalışma dizinlerini sorması (roots) 2026-07-28 sürümünde kullanımdan kaldırılacak özellikler arasına alındı; yeni uygulamalarda önerilmiyor. Taşıma katmanında iki standart seçenek tanımlı: yerel süreçler için stdio, uzak sunucular için Streamable HTTP.

Bir çağrı nasıl ilerler?

Kullanıcı "geçen haftanın açık taleplerini özetle" dedi diyelim. Zincir şöyle 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 üç iş 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: sunucu yalnızca okuma araçları sunuyor ve arka planda salt okunur bir hesapla bağlanıyorsa, ajan ne kadar ısrar ederse etsin yazma işlemi yapamaz. Bu sınırın gerçek olması için kısıtın araç açıklamasında değil, sunucunun kodunda ve kullandığı kimlik bilgisinde uygulanması gerekir. Son olarak aynı sunucu farklı ajanlar, ekipler ve modeller tarafından ortak biçimde kullanılabilir.

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 ayrışır. Bu ayrım olmadan ajan hata ayıklaması yorucu bir işe dönüşür.

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

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

Konu	MCP öncesi	MCP ile
Entegrasyon modeli	Her uygulama–sistem çifti için özel kod (N×M)	Sistem başına bir sunucu, uygulama başına bir istemci (N+M)
Yeni araç eklemek	Uygulamanın kodu değiştirilir ve yeniden dağıtılır	Sunucu bağlanır; istemci yetenekleri çalışma anında keşfeder
Model veya sağlayıcı değişimi	Araç tanımları sağlayıcı biçimine gömülü olduğu için yeniden yazılır	Araç sözleşmesi aynı kalır; model değişse de sunucu değişmez
Yetkilendirme	Her entegrasyonda ayrı anahtar ve ayrı mantık	Sunucu düzeyinde kimlik doğrulama ve kapsam yönetimi
Bakım	Hedef API değişikliği tüm entegrasyonlara yayılır	Değişiklik tek sunucuda karşılanır
Test	Ajan uçtan uca çalıştırılmadan doğrulama zordur	Sunucu bağımsız olarak test edilebilir

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ğı ya da hangi adreste durduğu, hangi kimlik bilgisiyle bağlanacağı, hangi kapsamlara sahip olacağı. Belirtime göre yerel (stdio) sunucular kimlik bilgilerini çalıştıkları ortamdan alır; uzak (HTTP) sunucular için ise OAuth 2.1 tabanlı bir yetkilendirme akışı tanımlanmıştır. Bağlantı kurulduğunda istemci araç listesini kendisi alır. Bu aşamada en çok özen isteyen iş, kimlik bilgisini gereken en dar kapsamla oluşturmaktır.

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

Kendi ürünlerimizden Lekta ve TheGlitch de bu yolla bağlanır: ikisinin de MCP sunucusu vardır; Claude gibi bir istemciye tanıtıldıklarında sayfa denetimi ve görsel işleme, sohbetin içinden araç olarak çağrılabilir.

Kendi MCP sunucunuzu geliştirmek

Resmî SDK'lar protokol ayrıntılarının çoğunu üstlenir; tek araçlı basit bir sunucu kısa sürede yazılabilir. Gerçek bir kurumsal sistemi düzgün açmak ise şema tasarımı, yetki, hata mesajları ve yanıt sadeleştirme dahil çok daha uzun bir iştir. İşin ağırlığı protokol katmanında değil, araçların nasıl tanımlandığındadır.

• 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ç adlarını ve açıklamalarını özenle yazın. Model hangi aracı çağıracağına bu bilgilere bakarak karar verir. Anthropic'in gelişmiş araç kullanımı yazısı en sık hataları yanlış araç seçimi ve hatalı parametre olarak sayıyor, özellikle adları birbirine benzeyen araçlarda. İki farklı işi çağrıştıran bir açıklama, model hatası gibi görünen bir soruna yol açabilir.
• Hata mesajlarını modelin okuyabileceği biçimde 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.
• Yanıtları sadeleştirin. Büyük JSON gövdeleri döndürmeyin; kaydın birkaç alanı yetiyorsa yalnızca onları dönün.

Araç sayısının da bir bedeli var. Bağladığınız sunucuların araç tanımları her istekte modelin bağlamına girer. Anthropic'in aynı yazısındaki örnekte beş sunucudan gelen 58 aracın tanımları, konuşma başlamadan yaklaşık 55 bin token tutuyor. Yazı, ondan fazla araç olduğunda ya da araç tanımları 10 bin token'ı aştığında araçların baştan yüklenmesi yerine gerektiğinde aranıp yüklenmesini öneriyor. Araç seti büyüdükçe ajanı göreve göre bölmek ya da araçları gruplayıp gerektiğinde yüklemek bu yüzden önem kazanır.

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 tek başına meselenin önemli bir kısmını ıskalıyor.

Birçok uygulamada ajanın araç seti koda gömülüdür; yeni bir yetenek eklemek, uygulamanın kodunu değiştirip yeniden dağıtmak demektir. MCP ile araç seti çalışma anında keşfedilen bir şeye dönüşür: bir sunucu bağlarsınız, ajan o yeteneği kazanır; kaldırırsınız, kaybeder. Sunucudaki araç listesi değiştiğinde istemci bundan haberdar olabilir.

Çalışma anında keşif, ajan tasarımını doğrudan etkiler. 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. Yukarıdaki araç sayısı sorununun pratik cevabı da burada: ajanın önüne aynı anda yalnızca görevle ilgili araçları koymak, gerisini gerektiğinde yüklemek.

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ı. Tipik kullanım alanlarından beşi:

• Müşteri operasyonu: Ajanın talep kayıtlarını okuması, sipariş durumunu sorgulaması, yanıt taslağı hazırlaması.
• Bilgi erişimi: 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.
• Operasyon: Stok, planlama ve bakım sistemlerinden durum bilgisi çekilmesi.
• Yazılım geliştirme: Depo, hata takip ve dağıtım sistemlerinin tek protokol üzerinden geliştirici ajanlarına bağlanması.

Bu senaryoların hepsinde araçların ne kadar iyi tasarlandığı, model seçimi kadar belirleyicidir.

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 beş 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ışabilir. OWASP'ın büyük dil modeli uygulamaları için ilk 10 risk listesi bu maddeyi birinci 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.
• Kafası karışmış vekil: Sunucu kendi geniş yetkisiyle kullanıcı adına işlem yaparsa, kullanıcının görmemesi gereken verilere erişim açılabilir. Çözüm, yetki kontrolünü sunucu tarafında da kullanıcı bazında yapmaktır. MCP'nin güvenlik rehberi bu sorunu özellikle üçüncü taraf API'lere bağlanan aracı sunucular için ele alıyor ve sunucunun kendisi için verilmemiş bir token'ı kabul edip arkadaki API'ye aynen aktarmasını (token passthrough) açıkça yasaklıyor.
• Güvenilmeyen sunucular: Belirtim, araç açıklamalarının güvenilir bir sunucudan gelmedikçe güvenilmez sayılması gerektiğini söylüyor. Üçü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.
• Kimlik bilgisi sızıntısı: Token'ların model bağlamına ya da loglara düşmesi ciddi bir risktir. Kimlik bilgilerinin yeri sunucu tarafıdır; istemin içine taşındığı anda kontrolünü kaybedersiniz.

Kolayca düşülen bir yetkilendirme tuzağı şöyle işler: 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. Aylar sonra "ajan bu tabloyu neden görebiliyor" sorusu geldiğinde iz, o ilk kısayola çıkar.

Uygulanabilir önlemler 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; çoğu zaman prototip hızının kurbanı oluyorlar.

MCP'nin ajan mimarisindeki yeri

Bir ajan sistemini dört 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 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; dört katmandan yalnızca birini standarda bağlıyor. Bağlantı sorununu çözüyor ve bu sayede geri kalan katmanlar ü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.

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 üç karar iyi verilmediğinde protokolün sağladığı faydanın çoğu kaybolur.

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

Hayır. MCP açık bir standarttır ve model bağımsız tasarlandı. Protokolün resmî sitesine göre Claude ve ChatGPT gibi asistanlar, Visual Studio Code ve Cursor gibi geliştirme araçları MCP'yi destekliyor; Anthropic'in Aralık 2025 duyurusu Gemini ve Microsoft Copilot'u da benimseyenler arasında sayıyor. Modelin araç kullanma becerisi sonucun kalitesini etkiler, ama protokol tek bir sağlayıcıya bağlı değildir. İstemcilerin hangi belirtim sürümünü ve hangi özellikleri desteklediği ise farklılık gösterebilir.

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

Mimariye bağlı. Sunucuyu kendi altyapınızda çalıştırırsanız hedef sistemdeki veri yerinde kalır, ama aracın döndürdüğü içerik modele gider; model bir bulut API'si üzerinden çalışıyorsa bu içerik model sağlayıcısına iletilir. Üçüncü taraf bir uzak sunucuya bağlanırsanız o servisin veri işleme politikası da devreye girer. Hassas sistemlerde sunucuyu kendi altyapınızda barındırmak ve araçların yalnızca gereken alanları döndürmesini sağlamak tercih edilen yoldur.

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, çağrılabilir araçların artık her uygulama için baştan yazılmaması.

Son güncelleme: 15 Ekim 2026