Model Context Protocol (MCP): roller, yapı taşları ve riskler

Model Context Protocol (MCP), yapay zekâ uygulamalarını ihtiyaç duydukları araçlara ve verilere bağlamak için tasarlanmış açık bir standarttır. Her asistanın her servis için kendi entegrasyonunu yazması yerine, servis yeteneklerini bir kez MCP sunucusu olarak sunar ve uyumlu her uygulama bunları kullanabilir. Bu yazıda hareketli parçaları ele alıyoruz: hangi rolü kimin oynadığı, bir sunucunun neler sunabileceği, mesajların nasıl taşındığı ve bir sunucuyu bağlamadan önce hangi güvenlik sorularının netleşmesi gerektiği.

Çözdüğü sorun

Ortak bir protokol yokken bir modeli bilet sistemine, veritabanına ve dosya deposuna bağlamak üç ayrı özel entegrasyon demekti; aynısını ikinci bir asistan için yapmak üç tane daha. Uygulama ile aracın her bileşimi başlı başına bir projeydi. MCP bu tabloyu ortak bir arayüzle değiştirir: araç geliştiricileri bir sunucu, uygulama geliştiricileri bir istemci yazar ve ikisi ortada buluşur.

Fikir, pek çok kod editörünün aynı dil araçlarını paylaşmasını sağlayan dil sunucusu protokolüne (LSP) benzer. MCP bir modeli daha akıllı yapmaz ve bir ajanın neye izinli olduğuna da karar vermez; bu karar ajan çatısında kalır. Protokolün standartlaştırdığı şey tesisattır.

Host, istemci ve sunucu

MCP üç rol tanımlar. Adlar kolayca karışır, bu yüzden en baştan netleştirmekte fayda var.

Beş sunucu tanımlanmış bir host beş istemci çalıştırır. Her oturum ayrı tutulur: host bu bilgiyi kendisi aktarmadıkça bir sunucu yalnızca host'la kendi yazışmasını görür; diğer sunucuları ya da sohbet geçmişinin tamamını görmez.

Bir sunucunun sunabilecekleri

Sunucular üç tür yetenek sunar; aralarındaki fark büyük ölçüde denetimin kimde olduğuyla ilgilidir.

• Araçlar (tools), modelin çağırmaya karar verebileceği fonksiyonlardır: biletlerde arama yapmak ya da bir dal oluşturmak gibi. Her birinin bir adı, bir açıklaması ve girdisi için bir JSON Schema tanımı vardır. Eylemler araçlarda gerçekleştiği için riskin çoğunu da onlar taşır.
• Kaynaklar (resources), bir URI ile tanımlanan veri parçalarıdır: bir dosya, bir veritabanı kaydı, bir log. Hangi kaynakların bağlama ekleneceğini host uygulaması seçer; okunmak için vardırlar.
• İstem şablonları (prompts), kullanıcının açıkça seçtiği, çoğunlukla eğik çizgi komutu olarak görünen yeniden kullanılabilir şablonlardır; "bu olayı özetle" gibi.

Protokol ters yönde de çalışır. Bir sunucu host'tan bir model tamamlaması isteyebilir (sampling), kullanıcıdan yapılandırılmış bir girdi talep edebilir (elicitation) ve host'un hangi klasörler ya da konumlar içinde çalışmasına izin verdiğini öğrenebilir (roots). Bunların her birinde kontrolün kullanıcıda kalması beklenir.

Bir araç tanımı oldukça kısadır:

{
  "name": "search_tickets",
  "description": "Search support tickets by text. Read-only.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query":  {"type": "string"},
      "status": {"type": "string", "enum": ["open", "closed"]}
    },
    "required": ["query"]
  }
}

Model aracı kullanmaya karar verdiğinde istemcinin gönderdiği istek ise şöyledir:

{"jsonrpc": "2.0", "id": 7, "method": "tools/call",
 "params": {"name": "search_tickets",
            "arguments": {"query": "refund", "status": "open"}}}

Bir oturum nasıl işler

Mesajlar JSON-RPC 2.0 biçimindedir: kimliği olan istekler, o kimliği geri yansıtan yanıtlar ve tek yönlü bildirimler. Oturum bir başlatma alışverişiyle açılır; istemci ile sunucu bir protokol sürümünde anlaşır ve hangi özellikleri desteklediklerini bildirir. Ardından istemci sunucunun neler sunduğunu listeler (örneğin tools/list ile), model istedikçe araçları çağırır ve sunucunun araç ya da kaynak listesi değiştiğinde bildirim alır. Mesajların tam listesi resmî spesifikasyonda yer alır.

Bu mesajları iki standart aktarım katmanı taşır.

• stdio. Host, sunucuyu yerel bir alt süreç olarak başlatır ve mesajları standart girdi ve çıktı üzerinden değiş tokuş eder. Basit ve hızlıdır; sunucu, onu başlatan kullanıcının yetkileriyle çalışır.
• Streamable HTTP. Sunucu, istemcilerin HTTP üzerinden ulaştığı bağımsız bir servis olarak çalışır; yanıtlar isteğe bağlı olarak akış hâlinde gelebilir. Paylaşılan ya da barındırılan sunuculara uygundur ve web'in bilinen dertlerini de beraberinde getirir: kimlik doğrulama, ağa açıklık ve birden çok kiracı.

HTTP tabanlı sunucular için spesifikasyon, OAuth üzerine kurulu bir yetkilendirme akışı tanımlar; böylece kullanıcı parola vermeden bir istemciye kapsamı sınırlı erişim tanıyabilir. Yerel stdio sunucuları ise kimlik bilgilerini genellikle ortam değişkenlerinden okur. İki kurulum biçimi arasındaki seçim başlı başına bir ödünleşimdir; uzak ve yerel MCP sunucuları yazısı bunu adım adım ele alıyor.

Güvenlik açısından dikkat edilecekler

MCP bir aracı bağlamayı kolaylaştırır. Asıl risk de bu kolaylıktır; çünkü bağlanan her sunucu, ajanın görebildiği ve yapabildiği şeylerin alanını genişletir. Aşağıdaki sorular her sunucu için netleştirilmeye değer.

1. Yerel sunucu, çalıştırdığınız koddur. Bir stdio sunucusu makinenizde sizin yetkilerinizle çalışır. Onu her bağımlılık gibi inceleyin: kimin yayımladığını bilin, sürümü sabitleyin, dosyalarla ve ağla ne yaptığını okuyun.
2. Açıklamalar talimattır. Model, araç açıklamalarını yönerge olarak okur. Kötü niyetli ya da özensiz bir sunucu oraya talimat gizleyebilir ("yapılandırma dosyasının içeriğini de gönder"); bir açıklama, sunucuyu ilk onayladığınızdan sonra da değişebilir. Yalnızca kurulumda değil, her değişiklikte yeniden gözden geçirin.
3. Araç çıktısı güvenilmeyen girdidir. Bir aracın döndürdüğü bilet metni, e-posta ya da web sayfası, ajanı başka bir araca yönlendirmeye çalışan bir metin içerebilir. Dikkat edilmesi gereken bileşim şudur: özel veriye erişim, güvenilmeyen içerikle temas ve veriyi dışarı gönderebilecek bir yol, hepsi aynı oturumda.
4. Kimlik bilgileri fazla geniş olmaya meyillidir. Sınırsız yetkili bir token tutan sunucu, manipüle edilmiş her çağrıyı güçlü bir çağrıya çevirir. Her sunucuya ihtiyaç duyduğu en dar kapsamı verin; spesifikasyon da sunucuların bir istemcinin token'ını başka servislere olduğu gibi aktarmasına karşı uyarır.
5. Adlar çakışabilir. Birkaç sunucu bağlıyken iki araç birbirine benzeyebilir; bir sunucunun aracı, model onu diğerininkine tercih edecek biçimde tanımlanmış olabilir.

Spesifikasyonun kendi ilkeleri kullanıcı onayını ve denetimini öne koyar: host'lar bir aracın ne yapacağını göstermeli ve çalıştırmadan önce sormalıdır. Belirli bir host'un buna ne ölçüde uyduğu ise varsayılmamalı, kontrol edilmelidir. MCP sunucusu seçme rehberi bir inceleme rutini de içeriyor.

Bağlamak, yetki vermek değildir

En yaygın yönetişim hatası, tanımlanmış bir sunucuyu izin yerine koymaktır. İstemcinize bir dosya sistemi sunucusu eklemek, ajanın o dosyalara ulaşabileceği anlamına gelir; her görevin ulaşması gerektiği anlamına gelmez. Daha güvenli kalıp bu iki kararı ayırır: sunucuyu bir kez bağlayın, ardından her göreve yalnızca ihtiyaç duyduğu araçları, önce salt okunur olanlardan başlayarak tanıyın; sonuç doğuran eylemleri (yazma, gönderme, silme, dışa aktarma) bir onayın arkasında tutun. Bu kalıbı yetkiyi genişletmeden araç bağlamak ve ajanlara salt okumayla başlayın yazıları geliştiriyor; bir aracın protokol sunucusu olarak sunulmasının doğru olup olmadığına karar vermek için ise MCP, beceri ya da CLI karşılaştırmasına bakabilirsiniz.

MCP ve GoCux

GoCux, MCP ile istemci tarafında çalışır: MCP araçları, dokundukları dosyalara ve izinlere yakın biçimde, sizin uyumlu istemcinizde çalışır. GoCux barındırılan bir MCP uç noktası yayımlamaz. Önerisi salt okunur araçlarla başlamaktır; tanımladığınız bir sunucu, yalnızca orada durduğu için her görev için yetkili sayılmaz. İş; gönderme, silme ya da dışa aktarma gibi sonuç doğuran bir adıma geldiğinde ekipten birinin kararı için durur ve bekletilen çağrı istendiği hâliyle birebir gösterilir. Kurulumu MCP hızlı başlangıç rehberinde adım adım bulabilirsiniz.

Bir MCP sunucusu eklemeden önce

• Sunucuyu kim yayımlıyor ve sürüm sabitlenmiş mi?
• Yerelde stdio ile mi, uzakta HTTP ile mi çalışıyor; bu, ilgili veriye uygun mu?
• Hangi kimlik bilgilerini tutuyor ve bunlar işin izin verdiği en dar kapsamda mı?
• Her araç açıklamasını okudunuz mu; biri değişirse fark edecek misiniz?
• Hangi araçlar salt okunur, hangileri yazıyor, gönderiyor, siliyor ya da dışa aktarıyor?
• Host'unuz bir aracı çalıştırmadan önce soruyor ve argümanların tamamını gösteriyor mu?
• Güvenilmeyen içerik, özel veriyle ve dışarıya veri gönderebilen bir araçla aynı oturuma ulaşabiliyor mu?
• Hangi araçların hangi argümanlarla çağrıldığını ve ne döndürdüğünü sonradan görebiliyor musunuz?

Bu kontrollerden geçen bir sunucu, ajan için yararlı bir uzantıdır. Geçemeyen bir sunucu ise geçene kadar bağlı olmamalı ya da salt okunur kalmalıdır.