Aralık ayında bir lojistik müşterimizle yaptığımız toplantıda genel müdür masaya tek bir soru koydu: "Bu MCP dedikleri şey nedir, bize lazım mı?" Açık konuşayım, Anthropic protokolü kasımda duyurduğunda biz de kendi içimizde aynı soruyu tartışmıştık. O günden beri, yani yaklaşık iki aydır, test ortamında sunucu kurup söküyoruz; kimi denemeler çöpe gitti, kimi elimizde kalıcı ders bıraktı. Bu yazı o iki ayın süzülmüş hâli. Hem "MCP sunucusu yazacağım" diyen geliştirici arkadaşlar hem de "ne satın aldığımı anlamak istiyorum" diyen yöneticiler için mimariyi elimden geldiğince sadeleştirerek anlatmaya çalışacağım.
Önce meselenin özü: MCP (Model Context Protocol), bir dil modelinin sizin sistemlerinizle — veritabanınız, API'niz, dosyalarınız — standart bir dille konuşmasını sağlayan protokol. Kasımdaki duyuruda "yapay zekânın USB-C'si" benzetmesi yapıldı ve bence yerinde bir benzetme. Her entegrasyon için ayrı fiş, ayrı adaptör üretmek yerine tek bir soket tanımlıyorsunuz. 2010'dan beri müşterilerimize kaç farklı sistemi kaç farklı yöntemle entegre ettiğimizi düşününce (SOAP'tan REST'e, oradan webhook cehennemine), standart bir soketin değerini uzun uzun anlatmama gerek yok sanırım.
Masadaki üç aktör: host, istemci, sunucu
Mimaride üç rol var ve bunları karıştırmamak her şeyin temeli. Host, kullanıcının doğrudan konuştuğu uygulama; bugün için en bilinen örnek Claude Desktop. Host'un içinde çalışan MCP istemcisi, her bir MCP sunucusuna birebir bağlantı kurar. Sunucu ise sizin tarafınızda duran kapıdır: dışarıya hangi araçların var olduğunu ilan eder, gelen çağrıları kendi sisteminizde çalıştırır, sonucu geri döner.
Buradaki en kritik cümleyi yöneticiler için ayrıca yazayım: model, sunucunuzun içini görmez. Veritabanı şemanızı, kodunuzu, bağlantı bilgilerinizi bilmez. Bildiği tek şey sizin ilan ettiğiniz arayüzdür — araç isimleri, açıklamaları ve parametre tanımları. Yani "yapay zekâya sistemimizi açıyoruz" cümlesi kulağa korkutucu gelse de, gerçekte açtığınız şey kendi çizdiğiniz kadar dar bir penceredir. Pencereyi ne kadar dar çizeceğiniz de tamamen sizin elinizde.
Bir aracın hayatı: keşiften sonuca
İşleyişi tek bir aracın yaşam döngüsü üzerinden izlemek en kolayı. İstemci sunucuya bağlandığında ilk iş araç listesini ister; sunucu her araç için bir ad, bir açıklama ve JSON Schema ile yazılmış parametre tanımı döner. Bu keşif adımı masum görünür ama aslında bütün sistemin kader anıdır, çünkü modelin "ne zaman hangi aracı kullanacağım" kararının tek girdisi bu açıklamalardır. Kötü yazılmış açıklama, kötü araç seçimi demek; bunu test ortamında defalarca yaşadık.
Sonra çağrı gelir. Model bir aracı seçer, host devreye girip onay akışını işletir — kullanıcı "evet, bu işlemi yap" der veya demez — ve istemci çağrıyı JSON-RPC ile sunucuya iletir. Bu onay adımını es geçmeyin; kurumsal tarafta bütün güven modeli buraya yaslanıyor. Sunucu işi çalıştırır, yapılandırılmış bir sonuç döner; model sonucu okur, ya cevabını yazar ya da bir sonraki araca karar verir. Döngü bu kadar.
Teknik olarak altta akan şey sade bir JSON-RPC trafiği. Büyü falan yok; büyü gibi görünen kısım, modelin bu sade trafiği akıllıca yönetmesi.
Somut bir örnekle bağlayayım. Kullanıcı "30 günü geçen ödemesi olan müşterileri listele" diye yazsın. Model, araç listesindeki açıklamalardan gec_odeme_listele'nin bu işe uygun olduğunu görür ve gun_esigi parametresine 30 yazar; host kullanıcıya "bu sorgu çalıştırılsın mı?" diye sorar; onayla birlikte sunucu veritabanına gider, sonucu yapılandırılmış biçimde döner; model de bunu okunur bir tabloya çevirip cevabını yazar. Birkaç saniyelik bu akışın her adımında kontrol sizde: hangi araçların var olduğunu siz belirlediniz, onayı kullanıcı verdi, sorguyu sizin yazdığınız ve sizin sınırladığınız kod çalıştırdı.
Bu arada sunucular yalnızca araç sunmakla sınırlı değil; protokolde kaynaklar (modelin okuyabileceği veri parçaları) ve hazır istem şablonları da tanımlı. Ama sahadaki işin ağırlığı şimdilik açık ara araçlarda; ben de bu yazıda oraya odaklandım.
İki ayda öğrendiğimiz dört ders
Birinci ders: araçları iş diliyle tanımlayın. İlk denememizde veritabanına açılan genel bir "sorgu_calistir(sql)" aracı yazmıştık; hem güvenlik açısından kötüydü hem de model her seferinde SQL'i yeniden icat etmeye çalışıyordu. Bunu "gec_odeme_listele(gun_esigi)" gibi tek işi olan araçlara böldüğümüzde modelin hata alanı daraldı, çıktı kalitesi gözle görülür arttı. Araç ne kadar spesifikse model o kadar az yanılıyor — iki ayın en net bulgusu bu.
İkinci ders: yetkiyi sunucu tarafında daraltın. Modelin uslu duracağına güvenmek bir güvenlik stratejisi değildir. Sunucunun veritabanı kullanıcısı salt okunur olsun, yapılabilecek işlemler beyaz listeyle sınırlansın. Model en saçma çağrıyı yapsa bile fiziksel olarak zarar verememeli.
Üçüncü ders: her çağrıyı loglayın. "Yapay zekâ dün ne yaptı?" sorusuna beş dakika içinde cevap veremeyen bir sistem, kurumsal ortamda yaşayamaz. Kim, hangi araç, hangi parametre, ne sonuç — hepsi kayıtta olmalı. Denetim ihtiyacı geldiğinde (ve gelecek) hazırlıksız yakalanmayın.
Dördüncü ders bizi biraz terletti: uzak sunucularda kimlik doğrulamayı baştan tasarlayın. Yerel, stdio üzerinden çalışan bir sunucuda bu dert yok; ama sunucuyu ağa açtığınız an "kim bağlanıyor, hangi yetkiyle" sorusu mimarinin merkezine oturuyor. Biz bunu bir deneme projesinde sonradan eklemeye kalktık ve neredeyse baştan yazdık. Sonradan eklenen kimlik doğrulama acı verir; baştan tasarlanan, doğal durur.
Peki bu iş nereye gidiyor?
Protokol henüz iki aylık ve ekosistem emekleme döneminde; bunu saklamanın anlamı yok. Ama 15 yıldır bu sektördeyim ve bir standardın tutup tutmayacağına dair burnumuz az çok koku alıyor artık. MCP'nin çözdüğü problem gerçek: her yapay zekâ entegrasyonunu sıfırdan, kendi usulünce yazmak sürdürülebilir değildi. Standart soket fikri tam da bu yüzden cazip. Elbette açık sorular var — uzak sunucu senaryolarının olgunlaşması, güvenlik pratiklerinin oturması, ekosistemin ciddi oyuncularla dolması zaman isteyecek. Biz bu bahisleri göze alıp erken girmeyi tercih ettik; erken girenin çukurlara da erken düştüğünü bilerek.
Yönetici koltuğundan okuyanlara küçük bir kontrol listesi bırakayım. Tedarikçiniz "size MCP sunucusu kuruyoruz" dediğinde sorulacak üç soru şu: Sunucu arkadaki sistemlere hangi yetkiyle bağlanıyor? Hangi eylemler kullanıcı onayından geçiyor? Araç çağrılarının kaydı nerede, ne kadar süreyle tutuluyor? Bu üç sorunun net cevabı yoksa, satın aldığınız şey entegrasyon değil risktir — protokol ne kadar parlak olursa olsun.
Bizim tarafta plan net. Şubat ayında kendi araç takip API'mizi MCP'ye açtığımız vaka çalışmasını bu blogda paylaşacağız — gerçek araç tanımları, gerçek sorgular, düştüğümüz çukurlar dahil. O yazıyı beklemek istemeyen, "bizim sistem için bu iş nasıl kurgulanır" diye şimdiden konuşmak isteyen olursa kapımız açık; bu aralar en keyif aldığımız sohbet konusu bu.
Yazının başındaki genel müdürün sorusuna dönersem: "MCP nedir" kısmını umarım netleştirebilmişimdir. "Bize lazım mı" kısmının cevabı sistemlerinize ve iştahınıza bağlı — ama şunu söyleyeyim, o toplantıdan çıkarken müşterimiz "raporları doğal dille sorabilecek miyiz yani?" diye soruyordu. Soru "nedir"den "ne zaman"a dönmüştü bile.