MCP nedir, neyi açar

Bir dil modeli tek başına yalnız metin üretir. Dosya okumaz, veritabanına bakmaz, bilet açmaz. Bu işleri yapabilmesi için dışarıya bağlanması gerekir.

Model bağlam protokolü, kısa adıyla MCP, bu bağlantıyı tek bir sözleşmeye indirger. Anthropic protokolü 2024 sonunda açtı ve kısa sürede birçok araç onu benimsedi. Bu derste önce protokolün neyi çözdüğünü görürsün, sonra bir araç çağrısını altı adımda izlersin.

Son olarak protokolün yaslandığı üç sessiz güven varsayımını sayarsın. Amaç henüz saldırı değil, zemin kurmaktır: güvenliği ancak iş bölümünü doğru yere koyduğunda tartışabilirsin.

Protokolde üç rol var. Host, modeli barındıran uygulamadır: sohbet arayüzü, kod düzenleyici ya da bir ajan çerçevesi. İstemci, host içinde her sunucuya ayrı açılan bağlantıdır ve bir istemci tam olarak bir sunucuyla konuşur. Sunucu ise yeteneği sunan taraftır: dosya sistemi sunucusu, bilet sunucusu, veritabanı sunucusu.

Host birden çok istemci açar, her istemci kendi sunucusuna bağlanır. Bu ayrım bir güvenlik sınırıdır. Resmi mimari belgesine göre sunucu konuşmanın tamamını görmemeli ve başka bir sunucunun içine bakmamalı. Konuşma geçmişi host'ta kalır, sunucular arasındaki her etkileşimi host yönetir.

İstemci sunucuya bağlanınca tek soru sorar: elinde ne var. Sunucu cevabında araçlarını listeler. Bu alışverişe tools/list denir.

Her araç için ad, açıklama ve argüman şeması döner. İstemci bu listeyi alır ve modele anlayacağı biçimde sunar.

Model artık o aracın var olduğunu bilir ve gerektiğinde çağırmak ister. Bu üç alan sözleşmenin çekirdeğidir. Ad kısa bir kimlik verir, açıklama modelin ne zaman çağıracağını anlatır, şema hangi argümanların zorunlu olduğunu belirler. Model bu üçünü okur ve kararını verir; sunucunun kodunu asla görmez.

Sunucu yalnız araç sunmaz. İki yetenek daha vardır: hazır bağlam parçaları ve hazır komut şablonları. Bağlam parçaları modelin okuması için veri getirir; şablonlar kullanıcının seçebileceği hazır istemlerdir.

Araçlar bu ikisinden ayrılır, çünkü yalnız veri taşımaz, iş yaptırır: dosya yazar, istek atar, kayıt siler. Bu dersin odağı araçlardır, çünkü asıl risk eylemde ve o eylemi tetikleyen tanım metnindedir. Bir aracı okurken üç soruyu birlikte sor: ne yapıyor, hangi veriye dokunuyor, çıktısı nereye gidiyor.

{
  "name": "dosya_oku",
  "description": "Verilen yoldaki metin dosyasini okur.",
  "inputSchema": {
    "type": "object",
    "properties": { "yol": { "type": "string" } },
    "required": ["yol"]
  }
}

Araç tanımını gördükten sonra bir çağrının tüm yolunu izle. Dikkat edeceğin nokta şu: model aracı çalıştırmaz, yalnız çağrı niyetini üretir. Çalıştırma kararını istemci verir. Yani gerçek yetki modelde değil, istemcinin kodundadır.

Aşağıdaki akışta dördüncü adıma bak; karar orada istemcinindir. İstemci onayı geciktirebilir, aracı hiç çağırmayabilir ya da argümanı değiştirip gönderebilir. Akışı okurken her adımda kimin konuştuğuna ve kimin karar verdiğine ayrı ayrı bak.

1. istemci -> sunucu : tools/list
2. sunucu  -> istemci: [dosya_oku, dosya_yaz, komut_calistir]
3. model   -> istemci: dosya_oku(yol="/etc/hosts") cagirmak istiyorum
4. istemci -> sunucu : tools/call dosya_oku
5. sunucu  -> istemci: dosya icerigi
6. istemci -> model  : icerik, baglama eklendi

Akışı satır satır oku. Birinci adımda istemci bağlanır ve listeyi ister. İkinci adımda sunucu araç tanımlarını döner. Üçüncü adımda model bir aracı çağırmak istediğini söyler, ama henüz hiçbir şey çalışmaz.

Dördüncü adımda istemci çağrıyı onaylar ve sunucuya iletir; onay ekranı burada devreye girer. Beşinci adımda sunucu sonucu döndürür. Altıncı adımda sonuç modelin bağlamına girer.

Her halka ayrı bir denetim noktasıdır. Resmi belgeye göre istemci, çağrıdan önce kullanıcıya hangi aracın hangi argümanla çalışacağını göstermeli ve duyarlı işlemlerde onay istemeli. Bu altı adım her taşıma biçiminde aynıdır.

Sunucu çoğu zaman yerel bir süreçtir ve standart akışlar üzerinden konuşur; uzak sunucu ise HTTP üzerinden. Taşıma değişse de anlam değişmez: istemci ister, sunucu yanıtlar. Değişen tek şey mesajların nasıl paketlendiğidir. Senin için önemli olan, kararın hangi adımda verildiğidir.

Dördüncü adımı kim denetliyorsa, sistemin güvenliğini o taraf taşır. Model değil, istemci.

// 4. adim: istemci -> sunucu
{"jsonrpc": "2.0", "id": 7, "method": "tools/call",
 "params": {
   "name": "dosya_oku",
   "arguments": {"yol": "/srv/proje/notlar.md"},
   "_meta": {
     "io.modelcontextprotocol/protocolVersion": "2026-07-28",
     "io.modelcontextprotocol/clientCapabilities": {}}}}

// 5. adim: sunucu -> istemci
{"jsonrpc": "2.0", "id": 7,
 "result": {
   "resultType": "complete",
   "content": [{"type": "text", "text": "Sprint toplantisi persembe 14.00"}],
   "isError": false}}

Bu iki mesajı satır satır oku. İstekte method alanı tools/call der; params içinde aracın adı ve argümanları durur. _meta alanı protokol sürümünü ve istemcinin yeteneklerini taşır.

Güncel sürümde her istek bu bilgiyi kendisi taşır, çünkü sunucu istekler arasında oturum tutmaz. Yanıt aynı id ile döner, böylece istemci hangi isteğin cevabını aldığını eşleştirir.

resultType alanı işin tamamlandığını söyler, content dizisi modele gidecek metni taşır. isError false ise araç hatasız çalışmıştır. Bu metin altıncı adımda modelin bağlamına girer. Şunu unutma: sunucunun döndürdüğü her cümle, modelin okuyacağı yeni bir girdidir.

Durumsuz yapının pratik bir sonucu daha var. İstemci araç listesini gerektiğinde yeniden ister ve sunucunun listeyi hep aynı sırada döndürmesi beklenir. Sabit sıra, istemcinin listeyi önbelleğe almasını ve bir değişikliği fark etmesini kolaylaştırır.

Liste değiştiğinde sunucu bir bildirim de gönderebilir. Senin için çıkarım şudur: araç listesi beklenmedik biçimde değişmişse, bu başlı başına bir inceleme nedenidir. Hangi aracın eklendiğine, hangi açıklamanın uzadığına bak.

Bu ayrımı kaybedersen tüm güvenlik tartışması bulanıklaşır. Model yalnız öneri üretir; ne çalıştıracağına istemci karar verir. Bu yüzden onay, kota ve kısıt da istemcinin işidir.

Modelin kandırılması tek başına zarar vermez; zarar, istemci o öneriyi sorgusuz uyguladığında doğar. Resmi güvenlik ilkeleri bunu açıkça yazar: host, herhangi bir aracı çağırmadan önce kullanıcının açık onayını almalıdır ve kullanıcı her aracın ne yaptığını önce anlamalıdır. Son sözü koda bırakırsan, model yanılsa bile sistem güvende kalır.

İstemcinin elinde üç seçenek var. Çağrıyı onaylayıp iletebilir. Çağrıyı reddedip modele geri dönebilir. Ya da argümanı değiştirip öyle gönderebilir.

Üçü de modelin bilgisi dışında olur. Bu yüzden iyi bir istemci riskli çağrıları varsayılan olarak durdurur ve kullanıcıya sorar. Model bir aracı çağırmak istediğinde bu bir komut değil, bir öneridir. Öneriyi emre çeviren, istemcinin onayıdır.

Resmi belge bunu insan döngüde ilkesiyle özetler: araç çağrılarını reddedebilecek bir insan her zaman devrede olmalı. İyi bir istemci üç şey yapar. Hangi araçların modele açıldığını gösterir.

Bir araç çalıştığında görünür bir işaret koyar. Duyarlı işlemlerde onay ekranı çıkarır. Bu üçü olmadan model sessizce iş yaptırabilir ve kullanıcı olup biteni ancak sonradan öğrenir.

Sahada en sık görülen hata otomatik onaydır. Birçok istemci bir araç için her zaman izin ver seçeneği sunar. Kullanıcı gün içinde onlarca onay penceresi görünce yorulur ve bu kutuyu işaretler. O andan sonra dördüncü adım sessizleşir.

Altay Kargo'nun destek ekibinde bir asistan bilet okuma aracını bu yolla serbest bıraktıysa sorun küçüktür. Aynı serbestlik dış adrese istek atan araca verildiyse, onay ekranı artık hiçbir şeyi durdurmaz. Kuralı basit tut: otomatik onayı yalnız salt okunur ve dar kapsamlı araçlara ver; yazan, silen ya da dışarı istek atan araçlarda her çağrıda sor.

Protokol sade olduğu için üç sessiz varsayıma yaslanır. Birincisi sunucunun dürüst olduğu varsayımıdır: açıklama alanında yazan şey aracın gerçekten yaptığı iştir. İkincisi kaynağın doğru olduğu varsayımıdır: bağlandığın sunucu sandığın sunucudur.

Üçüncüsü dönen verinin veri olarak kalacağı varsayımıdır: sonuç, talimat değil, salt içerik sayılır. Üçü de gündelik kullanımda görünmez, ama saldırının tamamı bu üç varsayımı kırmaya dayanır. Üç varsayımı somutla. Dürüstlük varsayımı kırılırsa, açıklaması hava durumu getirmek olan bir araç arka planda anahtar okur.

Kaynak varsayımı kırılırsa, dosya_oku sandığın araç saldırganın sahte sunucusundan gelir. Veri varsayımı kırılırsa, bir web sayfasından dönen paragraf içinde emir gibi duran bir cümle bulunur ve model onu uygular. Üç kırılmayı sonraki derslerde tek tek açacaksın, ama hepsi aynı yere çıkar: model metni kaynağına göre ayıramaz.

Her varsayımın bir tespit sorusu var. Dürüstlük için tanımı oku: açıklama, aracın adına ve şemasına uyan bir işi mi anlatıyor, yoksa başka bir dosyadan ya da başka bir araçtan mı söz ediyor. Kaynak için sunucunun nereden geldiğine bak: paket adı, yayımcı, sürüm. Veri için dönen içeriği izle; araç sonucu emir cümleleri taşıyorsa modele gitmeden işaretle.

Araç etiketleri burada ayrı bir tuzak kurar. Sunucu bir aracı salt okunur diye etiketleyebilir. Resmi belgeye göre istemci bu etiketleri güvenilir bir sunucudan gelmedikçe güvenilmez saymalı, çünkü etiket de sunucunun yazdığı bir metindir.

Kurumsal kurulumda bir istemci onlarca sunucuya aynı anda bağlanır. Her sunucu birkaç araç getirir. Model otuz kırk aracı tek listede görür ve bu liste tek bir metin bloğu olarak bağlama girer. Liste büyüdükçe modelin doğru aracı seçme olasılığı düşer, karıştırma olasılığı artar.

Uzun açıklamalar dikkati dağıtır ve yanlış çağrıyı kolaylaştırır. İyi bir kurulumda her istemci yalnız işine yarayan sunucuları bağlar. Kullanılmayan sunucuyu kapatmak hem bağlam maliyetini hem saldırı yüzeyini düşürür.

Bir pratik not daha. Sunucular çoğu zaman yerel süreç olarak çalışır ve standart girdi çıktı üzerinden konuşur. Yerel olması güvenli olduğu anlamına gelmez.

Yerel süreç senin kullanıcı yetkilerinle çalışır; ev dizinine, anahtarlarına ve ortam değişkenlerine erişir. Altay Kargo'nun geliştirici ekibi bir kod düzenleyiciye git, dosya ve terminal sunucularını aynı anda bağlarsa, model tek bir istekle bu geniş listeden araç seçer. İyi tasarlanmış bir istemci çağrıdan önce hangi aracın hangi argümanla çalışacağını gösterir.

Uzak bir sunucuya bağlanırken yetkilendirme devreye girebilir. Protokol yetkilendirmeyi isteğe bağlı tutar, ama HTTP üzerinden konuşan sunucular için OAuth tabanlı bir akış tanımlar. Bu akışta istemci, erişim belirtecini isterken resource parametresine hedef sunucunun adresini yazar. Bu parametre RFC 8707'deki kaynak göstergesidir.

Sunucu yalnız kendisi için verilmiş belirteci kabul etmeli; başka bir hizmet için verilmiş belirteci ne kabul etmeli ne de aşağıdaki bir servise iletmeli. Yerel sunucular bu akışı kullanmaz, kimlik bilgisini ortam değişkenlerinden alır. Bu yüzden yerel sunucuya verdiğin her ortam değişkeni, o sürecin elindeki bir anahtardır.

Rol ayrımını oturttuysan günlük okumaya hazırsın. İstemci günlüğünde araç kullanımı hep aynı alışverişle başlar: istemci sunucudan araç listesini ister ve dönen her tanım o andan sonra modelin bağlamında durur.

Güncel sürümde istemci bu listeyi tek seferde değil, gerektiğinde yeniden ister. Bu alışverişin adını bilmek, sonraki derslerde değişen bir tanımı günlükte yakalarken ilk kancan olacak. Bir tanımın uzunluğu iki liste arasında aniden değiştiyse, inceleme oradan başlar.