MCP sunucuları açıklandı: AI host'larının domain sistemlerine ulaşmasını sağlayan ortak sözleşme

Dev.to'da yazan bir geliştirici, AI uygulamalarına dış verilere ve araçlara kontrollü erişim sağlayan açık standart olan Model Context Protocol (MCP) üzerine bir yazı dizisine başladı. Yazar, hemen bir uygulamaya geçmek yerine ilk yazıda temelleri ele alıyor: MCP nedir, hangi sorunu çözer ve bir AI host'una yöneltilen bir soru aslında bir domain sisteminin içindeki verilere nasıl ulaşır. Yazar, açıklamayı gerçek bir projeye dayandırıyor — geliştirilmekte olan bir bilet sistemi için kurulmuş bir MCP sunucusu.

MCP'nin hedeflediği sorun

Dev.to yazısına göre, bir dil modelinin güncel biletler, iç terminoloji, izinler veya domain araçları hakkında otomatik bilgisi yoktur. Tarihsel olarak her AI uygulaması bu boşluğu kendi başına kapatmıştır: bir sohbet istemcisi bilet sistemi için bir eklenti almış, bir IDE doğrudan REST bağlantısı kurmuş, bir agent betiği ise özel bir API istemcisi edinmiştir. Her entegrasyon tek başına işleyebilir, ancak birlikte ele alındığında araç tanımlarını, doğrulama yollarını, kimlik doğrulama şemalarını ve loglama kurulumlarını katlanarak çoğaltırlar. Bir veri modeli veya güvenlik kuralı değiştiğinde, her köprünün ayrı ayrı yeniden işlenmesi gerekmiştir. Yazı, Anthropic'in MCP'yi Kasım 2024'te tam da AI asistanları ile veri kaynakları arasındaki bu noktadan noktaya entegrasyon parçalanmasını ele almak için tanıttığını belirtiyor.

Protokol nasıl kurulmuştur

Yazıdaki 2026-07-28 tarihli belirtim, bir host-client-server mimarisi, mesajlaşma için JSON-RPC 2.0 ve durumsuz (stateless) bir protokol çekirdeğine dayanır. Host — bir sohbet istemcisi, IDE veya agent aracı — modeli, bağlamı ve MCP bağlantılarını koordine eder. Belirleyici adım şudur: bir sunucu yeteneklerini yalnızca bir kez, uyumlu her host'un okuyabileceği ortak bir biçimde tanımlar. Bir host önce sunucunun sunduklarını keşfeder, sonra belirli bir istek için neyin kullanılacağını kontrollü bir şekilde belirler: hangi teklifler modele ulaşır, hangi sonuçlar bağlama girer ve hangi çağrılara izin verilir.

Üç temel yapı taşı: kaynaklar, prompt'lar ve araçlar

Makale, bileşen modelini bilet sistemi örneğiyle açıklıyor. Kaynaklar (resources), örneğin tek bir bilet gibi, okunabilir bağlam nesneleridir. Prompt'lar, örneğin bir risk analizi yapısı gibi, yeniden kullanılabilir iş şablonlarıdır. Araçlar (tools) ise açıkça adlandırılmış domain işlemleridir; yazı search_tickets, get_ticket ve list_ticket_comments örneklerini veriyor. Bu yapı taşlarıyla, "müşteri onboarding ile ilgili biletlerden hangi riskler, açık kararlar ve sonraki adımlar ortaya çıkıyor?" gibi bir sorgu, tahminlerden veya kopyala-yapıştır bağlamdan değil, güncel ve yetkili verilerden yanıtlanabilir.

MCP ne değildir

Makalenin önemli bir kısmı bilinçli bir sınırlama çizimidir. MCP bir ürün API'si değildir: REST veya GraphQL tipik olarak bir sistemin birincil arayüzü olarak kalır ve sunucu yalnızca seçilmiş yetenekleri açığa çıkarır. Bir agent çerçevesi veya iş akışı motoru da değildir — çok adımlı işin planlanması host'ta, modelde veya üzerindeki bir agent katmanında kalır. Bir veritabanı da değildir, çünkü kaynaklar veriyi bağlam olarak görünür kılar ama depolama, arama veya izin sisteminin yerini almaz. Eksiksiz bir eklenti sistemi de değildir; kurulum, kullanıcı arayüzü ve izin diyalogları protokolün üzerinde yer alır ve yazar, OpenAI'nin kendi bağlayıcılarını rastgele uzak MCP sunucularından ayırmasını bir ürün kararı olarak, belirtimin bir parçası değil, diye işaret eder. Son olarak, MCP bir AI değildir: bir sunucunun kendi dil modeline ihtiyacı yoktur.

Kurucular için bir tasarım kuralı

Yazarın temel önerisi, bir sunucuyu modelden içeri doğru değil, domain sisteminden dışarı doğru tasarlamaktır. Bir bilet sistemi için bu, önce hangi biletleri bir kullanıcının görebileceğini, hangi eylemlerin gerçek etkileri olduğunu, hangi girdilerin geçerli olduğunu ve hangi sonuçların modele bağlamına girebileceğini netleştirmek anlamına gelir. Faydalı bir araç ve kaynak seçimi ancak bu sınırlardan ortaya çıkar. Onaylar, loglama ve denetim her host ve sunucu uygulamasının sorumluluğunda kalır — bu kararları protokol vermez, yazının altını çizdiği gibi.

Neden önemli

AI'yı iç sistemlere bağlayan ekipler için tartışma bakım ekonomisine indirgenebilir: tek bir ortak yetenek tanımı, host başına biriken köprülerin yerini alır, güvenlik kararları dağınık değil karşılaştırılabilir hale gelir ve domain yetenekleri tekrar tekrar değil, bir kez tanımlanır. En az bunun kadar önemlisi, MCP'nin dışarıda bıraktıklarıdır — planlama, depolama, eklenti UX'i — bu da protokolü yalın tutar ve kontrol sınırını, işletmecilerin genellikle istediği yerde, yani host'ta bırakır. Agent'lar demolarından üretime doğru ilerledikçe, standartlaşmış bir entegrasyon katmanı ile açığa çıkardığı sistemler arasındaki bu temiz ayrım, bu tür entegrasyonları her şeyden önce incelenebilir ve denetlenebilir kılan şeydir.