MCP ile araç ve kaynak sunmak
Araç, kaynak ve istem şablonu ayrımını ve bir yeteneği MCP sunucusu olarak mı süreç içi araç olarak mı sunmak gerektiğini öğretir.
Önkoşul: AI Agent
BU DERSİN SONUNDA
- Araç, kaynak ve istem şablonu ilkellerini kime ait karar oldukları üzerinden ayırmak
- Bir yeteneği MCP sunucusu veya süreç içi araç olarak sunma kararını ölçüte bağlamak
- Sunucu sınırını bir güven sınırı olarak tasarlamak
- Araç kümesini API uç noktaları yerine görevlere göre tanımlamak
- 1
Teori
Kavramın çalışma mantığı
- 2
Örnek
Gerçek bir senaryo üzerinde gösterim
- 3
Lab
Uygulamalı alıştırma
- 4
Test
Kısa ölçüm
- 5
Proje
Rotadaki projeye katkı
Kısa cevap
MCP, bir ajan istemcisinin araçları, kaynakları ve istem şablonlarını aynı arayüzle keşfedip çağırmasını sağlayan bir protokoldür. Kazancı yeni bir yetenek değil: her istemci ile her araç için ayrı tümleştirme yazma zorunluluğunu ortadan kaldırması ve araç kümesini çalışma anında keşfedilebilir hâle getirmesi.
Teori: tümleştirme sayısı sorunu#
Her ajan istemcisi kendi araç arayüzünü tanımladığında, M aracı N istemciye bağlamak N çarpı M ayrı tümleştirme demektir. Ortak bir protokol bunu N artı M’ye indirir: araç bir kez sunucu olarak yazılır, istemciler aynı el sıkışmayı konuşur. Fikir yeni değil; sürücü modelinin yaptığı işin aynısı.
Protokol bir yetenek pazarlığıyla başlar: istemci ve sunucu hangi sürümü ve hangi yetenekleri desteklediklerini bildirir, ardından istemci sunucudan araç, kaynak ve şablon listesini ister. Liste çalışma anında alınır. Yani ajanın araç kümesi koda gömülü değildir, bağlantı kurulduğunda öğrenilir.
Dinamik keşfin bir bedeli var: araç listesi değiştiğinde ajanın davranışı yeniden dağıtım yapılmadan değişir. Bu, esneklik ile denetlenebilirlik arasında bir ödünleşim. Üretimde yaygın tercih, sunucu sürümünü ve beklenen araç kümesini sabitlemek ve listedeki değişikliği bir dağıtım olayı gibi ele almak.
Üç ilkel: araç, kaynak, şablon#
| İlkel | Ne sunar | Seçim kimde | Uygun kullanım |
|---|---|---|---|
| Araç | Çağrılabilir işlev; sorgulayan veya yan etkili | Model seçer, istemci yürütür | Kayıt sorgulama, güncelleme, hesaplama, mesaj gönderme |
| Kaynak | Kimlikle okunabilir içerik | Uygulama veya kullanıcı seçer | Bağlama eklenecek dosya, belge, tablo dökümü |
| İstem şablonu | Parametreli hazır iş tanımı | Kullanıcı seçer | Tekrarlanan iş kalıplarını tek biçime bağlamak |
Taşıma katmanı ve süreç sınırı#
- Yerel süreç: sunucu istemciyle aynı makinede ayrı bir süreç olarak çalışır, standart girdi/çıktı üzerinden konuşur. Kimlik işletim sistemi kullanıcısına dayanır, ağa açılmaz.
- Uzak sunucu: HTTP tabanlı taşıma ile çok kullanıcılı ortamda paylaşılır. Kimlik doğrulama, yetki kapsamı ve hız sınırı artık sunucunun kendi sorumluluğudur.
- Süreç sınırı bir güven sınırıdır: sunucu, istemciden gelen argümanı kendisi doğrulamak zorundadır; istemcinin doğruladığını varsayamaz.
- Sunucunun döndürdüğü metin ajanın bağlamına girer. Bu metin güvenilmeyen kaynaktan geliyorsa sunucu aynı zamanda bir enjeksiyon yüzeyidir; alanın kaynağını etiketlemek gerekir.
Karar: sunucu mu, süreç içi araç mı?#
- 1Aracı kaç istemci kullanacak?
Tek uygulamaya gömülü tek kullanım için süreç içi işlev yeterlidir; protokolün getirdiği ek katman karşılığını vermez.
- 2Araç bağımsız bir yetki alanına mı ait?
Farklı kimlik, farklı ağ erişimi veya ayrı denetim gereksinimi varsa ayrı süreç hem taşınabilirlik hem izolasyon kazandırır.
- 3Araç kümesi ayrı bir ekip tarafından mı geliştiriliyor?
Ayrı sürüm ve dağıtım döngüsü varsa sunucu sınırı bu ayrımı somutlaştırır ve sözleşmeyi görünür kılar.
- 4Gecikme bütçesi ek atlamayı taşıyor mu?
Her çağrı bir süreç veya ağ sınırı geçer. Sıkı gecikme bütçesi olan akışlarda süreç içi çağrı daha uygundur.
Sık yapılan hata#
En yaygın hata, eldeki API’nin her uç noktasını birebir araca çevirmek. Ortaya uç nokta sayısı kadar kabarık bir araç listesi çıkar: model hangisini seçeceğini bulamaz, şemalar bağlamın önemli bir kısmını kaplar ve iki aracın açıklaması kaçınılmaz olarak örtüşür. Sunucu tasarımı API yüzeyinin haritası değil görevlerin haritasıdır. "Müşterinin son siparişinin durumu" tek araçtır, arkada üç uç nokta çağrısı gerektirse bile.
LAB · UYGULAMALI ALIŞTIRMA
Bir görev için ince sunucu yüzeyi tasarlayın
- 1Kendi sisteminizden bir ajan görevi seçin ve o görevi bitirmek için gereken API çağrılarını sırayla yazın.
- 2Çağrıları görev birimlerine toplayın; üçten fazla araç çıkıyorsa hangi ikisinin tek araçta birleşebileceğini gerekçesiyle gösterin.
- 3Her birim için ad, hangi durumda seçilmesi gerektiği ve argüman kısıtlarını tek sayfaya yazın; hangisinin araç, hangisinin kaynak olacağını gerekçelendirin.
- 4Sunucu sınırında yapılacak doğrulamaları listeleyin: argüman kısıtları, kimlik, yetki kapsamı, hız sınırı.
- 5Sunucunun döndürdüğü metinde güvenilmeyen kaynaktan gelen alanları işaretleyin ve bu alanların nasıl etiketleneceğine karar verin.
Beklenen çıktı
Tek bir görev için üç aracı geçmeyen sunucu yüzeyi tanımı, araç/kaynak ayrım gerekçesi ve sunucu tarafı doğrulama listesi.
Sık sorulan sorular
MCP kullanmak ajanı daha yetenekli yapar mı?
Yetenek araçtan gelir, protokolden gelmez. MCP’nin kazancı tümleştirme maliyeti ve taşınabilirliktir: aynı sunucu farklı istemcilerle çalışır, araç kümesi tek yerde bakım görür.
Araç listesi çalışma anında değişebiliyorsa davranış nasıl sabit kalır?
Kendiliğinden sabit kalmaz. Bu yüzden üretimde sunucu sürümü sabitlenir ve araç listesindeki değişiklik bir dağıtım olayı gibi ele alınır: liste değiştiğinde görev setini yeniden koşturmak gerekir.
Kaynak yerine her şeyi araç olarak sunsam olur mu?
Çalışır ama seçim yükünü modele yığar. Hangi belgenin bağlama gireceği uygulamanın zaten bildiği bir şeyse, bunu kaynak olarak sunmak modelin karar vermesi gereken kümeyi küçük tutar.
LEARN
AI Agent Developer rotasına devam et
Dersler tek başına da okunabilir, ama sıralı ilerlemek önkoşul boşluklarını kapatır.