İçeriğe geç
Kaynak kütüphanesi
GOCUX / Makalelercli

MCP sunucusu nerede çalışmalı? Güven, yetki, veri ve bakım

Yerel ve uzak MCP sunucularının güven, kimlik bilgileri, makineden çıkan veri, gecikme ve günlük işletim açısından farkları ve eklemeden önce bakılacaklar.

Bir MCP sunucusu birbirinden çok farklı iki yerde çalışabilir: ajan istemcinizin kendi bilgisayarınızda başlattığı küçük bir program olarak ya da istemcinin HTTP üzerinden ulaştığı, ağın bir yerindeki bir hizmet olarak. Protokol mesajları iki durumda da aynıdır; bu yüzden seçim bir kurulum ayrıntısı gibi görünebilir. Öyle değildir. Sunucunun nerede çalıştığı; kimin koduna güvendiğinizi, kimlik bilgilerinin nasıl saklandığını, hangi verinin sınırınızı aştığını ve sistemi kimin ayakta tutacağını belirler. Bu yazı bu ödünleşimleri tek tek ele alıyor ve herhangi bir sunucuyu eklemeden önce kullanabileceğiniz bir kontrol listesiyle bitiyor.

MCP'de yerel ve uzak ne demek

Model Context Protocol, bir istemcinin (ajanı barındıran uygulamanın) bir sunucunun sunduğu araçları nasıl keşfedip çağıracağını, kaynakları nasıl okuyacağını ve istemleri nasıl kullanacağını tanımlar. Spesifikasyon iki standart taşıma yöntemi tarif eder ve bunlar iki kurulum biçimiyle birebir örtüşür.

  • Yerel (stdio). İstemci sunucuyu bir alt süreç olarak başlatır ve onunla standart girdi ve çıktı üzerinden konuşur. Sunucu sizin kullanıcı hesabınızla çalışır, dosya sisteminizi ve ortam değişkenlerinizi görür, istemci kapanınca o da kapanır.
  • Uzak (Streamable HTTP). Sunucu sürekli çalışan bir web hizmetidir. İstemci HTTP üzerinden bağlanır, kimliğini doğrular ve bir oturum sürdürür. Bu hizmeti birileri işletir: bir sağlayıcı, platform ekibiniz ya da siz.

Gerçek kurulumlarda bu çizgi bulanıklaşır. Yerel bir sunucu çoğu zaman arka planda uzak bir API'yi çağırır; yani veri yine makineden çıkar. Uzak bir sunucu ise kendi ağınızda barındırdığınız bir hizmet olabilir; böylece veriyi üçüncü bir tarafa vermeden merkezî işletimin avantajını alırsınız. Bir sunucuyu değerlendirirken iki soruyu ayrı ayrı sorun: sunucu süreci nerede çalışıyor ve dokunduğu veri nereye gidiyor?

Yerel (stdio)Uzak (HTTP)
Kodu kim çalıştırırSiz, kendi makinenizdeHizmeti işleten taraf
Tipik kimlik bilgisiYapılandırma dosyasında ya da ortam değişkeninde duran API anahtarıKişi başına oturum açma; kapsamı dar, iptal edilebilir belirteçler
Neye erişebilirKullanıcı hesabınızın erişebildiği her şeyeHizmete hangi yetki verildiyse ona
GüncellemelerHer makine kendi kopyasını güncellerTek bir kurulum herkes için değişir
KayıtlarTutuluyorsa bile makinelere dağılmışİşleten taraf tutuyorsa merkezde

Güven: kimin kodu, hangi yetkiyle çalışıyor

Yerel bir sunucu, sizin çalıştırdığınız koddur. Tek satırlık bir paket çalıştırıcısıyla kuruyorsanız, paket deposunun o an sunduğu sürümü çekip kendi yetkilerinizle çalıştırıyorsunuz demektir. Bu, herhangi bir bağımlılık için verdiğiniz türden bir tedarik zinciri kararıdır: Bakımını kim yapıyor, sürüm sabitlenmiş mi, kaynak kodu okunabiliyor mu, işinin gerektirdiğinden fazla erişim istiyor mu? Yalnızca tarih biçimlendiren bir sunucu SSH anahtarlarınızı okuyamamalıdır; oysa yerel bir süreç genellikle okuyabilir.

Uzak sunucu kodu makinenizden uzaklaştırır; bir risk sınıfını ortadan kaldırırken yenisini ekler. Artık onların kodunu çalıştırmıyorsunuz, ama onlara girdi gönderiyor ve çıktılarını kabul ediyorsunuz; aradaki adımları ise göremiyorsunuz. Araç listesi ve araç açıklamaları, sizin tarafınızda hiçbir güncelleme olmadan sunucu tarafında değişebilir. Ajan neyi çağıracağına bu açıklamalara bakarak karar verdiği için, değişen bir açıklama değişen bir talimat demektir. Sabitleyebildiğiniz her şeyi sabitleyin ve bir sunucunun ilan ettiği araçlar değiştiğinde bunu fark edeceğiniz bir düzen kurun.

İki biçimin ortak bir riski var: araç çıktısı doğrudan ajanın bağlamına akar. Bir aracın döndürdüğü sayfa, e-posta ya da kayıt, ajanı yönlendirmek için yazılmış metin içerebilir. Taşıma yöntemi sizi bundan korumaz; sizi koruyan, dar kapsamlar ve onay adımlarıdır.

Kimlik doğrulama ve kimlik bilgileri

Yerel sunucular alt servislere genellikle istemcinin yapılandırma dosyasına ya da bir ortam değişkenine konmuş uzun ömürlü bir anahtarla bağlanır. Basittir ve çevrimdışı da çalışır; ama anahtar, sunucuyu çalıştıran her makinede düz metin olarak durur, çoğu zaman onu oluşturan kişinin bütün yetkilerini taşır ve iptal etmek her kopyayı tek tek bulmayı gerektirir.

HTTP taşımaları için spesifikasyonun yetkilendirme bölümü OAuth 2.1 üzerine kuruludur: kullanıcı oturum açar, istemci yalnızca o sunucu için verilmiş bir belirteç alır ve işleten taraf bu belirteci merkezden iptal edebilir. Sunucu üzerine düşeni yaptığı sürece bu model ekipler için daha uygundur. Belirteçlerin gerçekten kendisi için verildiğini doğrulayıp doğrulamadığını, belirtecinizi olduğu gibi başka servislere aktarmaktan kaçınıp kaçınmadığını ve salt okunur kapsamlar sunup sunmadığını kontrol edin. Oturum açarken bütün kapsamları isteyen uzak bir sunucu, uzun ömürlü anahtarı yalnızca göremeyeceğiniz bir yere taşımış olur.

Hangi biçimi seçerseniz seçin aynı alışkanlığı koruyun: her sunucuya kendi kimlik bilgisini verin, bu bilgiyi işin gerektirdiği en dar eylem kümesiyle sınırlayın ve okuma ile yazma yetkilerini ayrı tutun; böylece salt okunur bir kurulum gerçekten salt okunur kalır.

Veri: sınırı neyin geçtiğini çıkarın

Yerelin gizli anlamına geldiğini varsaymayın. Gerçekçi tek bir çağrı için veri akışını çizin. Araç argümanlarına ne giriyor: bir arama terimi mi, bir dosya yolu mu, yoksa ajanın içine yapıştırdığı koca bir doküman mı? Sunucu bunu nereye gönderiyor? Neyi, ne kadar süreyle kaydediyor? Geriye ne dönüyor ve bu yanıt artık başka bir yerde işlenen bir model bağlamında mı duruyor?

Uzak bir sunucuda araç argümanlarındaki her şey tanımı gereği sınırınızın dışına çıkar. Ajanlar argüman konusunda cömerttir; eline bir özetleme aracı verirseniz gizli bir dosyanın tam metnini seve seve gönderir. Bir sunucu iç ya da kısıtlı olarak sınıflandırdığınız veriyi işliyorsa ya onu kendiniz barındırın ya da onu çağıran işin yalnızca dışarı göndermenize izin verilen veriyle sınırlı kalmasını sağlayın.

Gecikme, erişilebilirlik ve işletim

stdio sunucusunda istemciyle sunucu arasında ağ adımı yoktur; sunucu istemciyle birlikte başlar ve işin kendisi ağa ihtiyaç duymadığı sürece uçakta bile çalışır. Uzak sunucu gidiş dönüşler ve başkasının ayakta kalmasına bağımlılık ekler; ama hizmet verdiği verinin yanında durabilir ve bu çoğu zaman dizüstü bilgisayarınızdan çıkan adımdan daha önemlidir. Hangisinin daha hızlı olduğunu varsaymak yerine kendi iş yükünüzde ölçün.

Asıl fark işletimde ortaya çıkar. On geliştiricinin her birinde çalışan yerel bir sunucu; on kopya, on yapılandırma dosyası ve bir ay sonra birkaç farklı sürüm demektir. Kimse "geçen salı silme aracını kim çağırdı?" sorusunu yanıtlayamaz. Uzak bir kurulum size tek sürüm, erişimi iptal edeceğiniz tek bir yer ve tek bir kayıt verir; bedeli bir hizmet işletmektir: izleme, yükseltme, kimlik doğrulama ve olay müdahalesi ya da bunları üstlenen bir sağlayıcıya bağımlılık.

Hangisini seçmeli

  • Yereli tercih edin: kendi dosyalarınız ya da masaüstü uygulamalarınız üzerinde çalışan araçlar, tek geliştiricinin kullandığı kurulumlar, denemeler ve verinin makineden çıkmaması gerektiği, aracın da dışarıyı çağırmadığı durumlar için.
  • Uzağı tercih edin: aynı araca çok kişinin ihtiyaç duyduğu, erişimin kişi bazında verilip geri alınması gerektiği, tek bir denetim kaydı istediğiniz ya da sunucunun ortak bir sisteme yakın durması gerektiği durumlarda.
  • Kendi barındırdığınız uzak sunucuyu tercih edin: merkezî işletim istediğiniz ama verinin üçüncü bir tarafa gidemediği durumlarda.

Belirli sunucuları seçerken ajanınız için MCP sunucusu seçmek, arama özelinde ise web araması için MCP sunucusu seçmek yazılarına bakabilirsiniz.

Yetki, taşıma yönteminden ayrı bir sorudur

İki taşıma yöntemi de en önemli soruyu yanıtlamaz: bu görev bu aracı şu anda kullanabilmeli mi? Bir sunucuyu bağlamak bir aracı kullanılabilir kılar; aracın her kullanımını uygun kılmaz. Makul bir kurulum salt okumayla başlar, yazma araçlarını bilinçli olarak ekler ve göndermek, silmek ya da dışa aktarmak gibi sonuç doğuran çağrıları bir insanın kararına bağlar.

GoCux bu ayrımı izler. Barındırılan bir MCP uç noktası yayımlamaz; MCP araçları sizin uyumlu istemcinizde çalışır ve müşteri CLI'ı kendi yerel araçlarının ve izinlerinin sahibi olarak kalır. Bir sunucunun yapılandırılmış olması her görevin onu kullanabileceği anlamına gelmez; kayıtlı bir bağlayıcı da tek başına hiçbir şeye yetki vermez. Kimlik bilgileri tarayıcıda değil, sunucu tarafında referans olarak tutulur; sonuç doğuran eylemler ekipten biri karar verene kadar bekler; istekler, kararlar, araç çalıştırmaları ve bunların sonuçları ekibin okuyabildiği tek bir denetim izi oluşturur. Kurulum adımları MCP hızlı başlangıç sayfasında, gerekçesi ise yetkiyi genişletmeden araç bağlamak yazısında.

Sunucu eklemeden önce kontrol listesi

  • Sunucu sürecinin nerede çalıştığını ve dokunduğu verinin nereye gittiğini biliyor musunuz?
  • Sürüm sabitlenmiş mi; kaynak koduna ya da değişiklik kaydına bakabiliyor musunuz?
  • Sunucunun en dar kapsamla sınırlanmış, okuma ve yazması ayrılmış kendi kimlik bilgisi var mı?
  • Uzak sunucular için: oturum kişi bazında mı açılıyor, kapsamlar dar mı, erişimi tek bir yerden iptal edebiliyor musunuz?
  • İlan edilen araçlar ya da açıklamaları değişirse bunu fark edecek misiniz?
  • Hangi araç çağrıları bir insanın kararını beklemeli ve bu nerede uygulanıyor?
  • Çağrılar nerede kaydediliyor, kaydı kimler okuyabiliyor ve ne kadar süre saklanıyor?
  • Salt okunur araçlarla mı başladınız? Ayrıntısı için ajanlara salt okumayla başlayın.

Bu iş akışını çalışma alanınıza taşıyın.

Kapsamı belirleyin. Kanıtları inceleyin. Gereken adımları onaylayın.

Çalışma alanını aç

Sıradaki adım