Yerel geliştirme ortamınız için MCP sunucusu
Bir asistana makinenizde kabuk erişimi vermek kolay ve pervasız. Model Context Protocol daha dar bir şey sunuyor: tanımlı bir işlem kümesi ve sizin belirlediğiniz bir sınır.
"Terminal versek yeter" yaklaşımının sorunu
Bir asistanın geliştirme ortamınızı yönetmesinin en hızlı yolu ona kabuk vermek. Hemen çalışır ve iş için yanlış biçimdir.
Kabuğun sözlüğü yoktur. Asistanın sizin tam dizin düzeninizi bilmesi, yapılandırma yollarını tahmin etmesi ve sürümler arasında değişen insan okunur çıktıyı ayrıştırması gerekir. Her işlem serbest metin olduğu için "okuyabilirsin ama yazamazsın" demenin bir yolu yoktur — veritabanlarını listeleyen komut, birini silen komutla aynı kapıdan geçer.
Üstelik sonuçlar araçlarınıza görünmez. Asistan bir yapılandırma dosyasını doğrudan düzenlerse, o dosyayı yöneten uygulamanın haberi olmaz; bellekteki durumu ile diskteki dosya sessizce ayrışır.
MCP gerçekte nedir
Model Context Protocol, bir asistan ile yetenek sunan bir program arasındaki JSON-RPC arayüzü. Program bir araç listesi yayınlar — her birinin adı, açıklaması ve argümanları için tipli bir şeması vardır — asistan da onları adıyla çağırır.
Bundan üç özellik doğar ve kabuğa tercih etmenin bütün gerekçesi bunlardır:
- Sözlük açıktır.
list_domainsya vardır ya yoktur. Deneme yanılmayla keşfedilecek bir şey kalmaz. - Argümanlar tipli ve doğrulanmıştır; hatalı bir çağrı iş yarıda kalmadan sınırda reddedilir.
- Yüzey sonludur. Araç olmayan şey yapılamaz — "yapılmamalı" değil, yapılamaz.
Sunucu neden uygulamanın içinde olmalı
Geliştirme ortamı için bir MCP sunucusu, aynı servislerle konuşan bağımsız bir süreç olabilir. Akla ilk gelen tasarım budur ve çözmesi gereken sorunu geri getirir: aynı yapılandırmayı yöneten iki program, biri bir şey değiştirdiğinde ayrışır.
Sunucuyu, o durumun zaten sahibi olan uygulamanın içinde çalıştırmak bunu ortadan kaldırır. Araçlar, düğmelerin çağırdığı kod yollarını çağırır. Ayrışacak ikinci bir uygulama yoktur ve pencere araç çalıştığı anda güncellenir, çünkü aynı nesne grafiğidir.
Bedeli bir bağımlılıktır. Uygulama kapalıysa uç nokta da yoktur. Bunu örtmek yerine açıkça söylemek gerekir — çözüm sunucuyu dışarı taşımak değil, uygulamanın oturumla birlikte başlamasıdır.
İzin kapsamları araç sayısından önemli
"23 araç" güvenlik hakkında hiçbir şey söylemez. Önemli olan, alan bazında asistanın neye izinli olduğuna karar verebilmeniz — ve bu kararın birden fazla yerde uygulanması.
İşe yarayan model, araçları kapsamlara ayırıp her kapsama üç düzey verir:
| Kapsam | İzin yok | Okuma | Okuma + yazma |
|---|---|---|---|
| Alan Adları | görünmez | listeleme | oluşturma, güncelleme, uygulama başlatma |
| Servisler | görünmez | durum, sağlık | başlat, durdur, yeniden başlat |
| Veritabanları | görünmez | listeleme, salt-okunur SQL | oluşturma, yedek, geri yükleme, yazma |
| Loglar | görünmez | okuma | — |
Bunu süsten çıkarıp gerçek yapan iki ayrıntı var.
İzin verilmeyen araç hiç gönderilmez. tools/list yanıtını süzmek, asistanın o yeteneğin varlığını bilmemesi demektir; denemeye karar veremez, size seçenek olarak da söyleyemez.
Çağrı ayrıca reddedilir. Liste süzmesi tek başına güvenlik sınırı değildir — araç adını sabit yazmış bir istemci onu atlar. İzin, çağrı geldiğinde yeniden denetlenmelidir.
Varsayılan salt okuma, özellikle SQL'de
Geliştirme ortamındaki en tehlikeli araç serbest SQL'dir ve naif uygulama ilk kelimeye bakar. Bu hemen çöker:
-- WITH ile başlıyor, her şeyi siliyor
WITH gitti AS (DELETE FROM users RETURNING *) SELECT * FROM gitti;
-- SELECT ile başlıyor, diskten dosya okuyor
SELECT LOAD_FILE('/etc/passwd');
Önek kontrolü ikisini de geçirir. İfadenin gövdesi hem veri değiştiren komutlar hem de dosya sistemine uzanan fonksiyonlar için incelenmelidir — LOAD_FILE, pg_read_file, lo_import, INTO OUTFILE.
Zor olan yarısı, dürüst sorguları bozmadan katı kalmak. Şunların hepsi meşru okumadır ve geçmelidir:
SELECT 'delete me' AS not_; -- tehlikeli kelime, dizge içinde
SHOW CHARACTER SET; -- içinde SET geçiyor
SELECT updated_at FROM siparis; -- içinde UPDATE geçiyor
Yazmak mümkün kalmalı — ama hem açık bir bayrağın hem yazma izninin arkasında, yani bir dikkatsizlikle değil iki bilinçli adımla.
Loopback'te tutun, varsayılan kapalı
Yerel bir geliştirme sunucusunun ağdan bağlantı kabul etmesi için sebep yok. 0.0.0.0 yerine 127.0.0.1'e bağlanmak, asistanınızın kullandığı bir araçla kafedeki herkesin erişebileceği bir servis arasındaki farktır.
Varsayılan kapalı olması aynı sebeple önemli: kimsenin açmadığı yetenek kötüye kullanılamaz. Gelen isteklerde Origin başlığını denetlemek, ziyaret ettiğiniz bir web sayfasının kendi tarayıcınızdan o porta ulaşmaya çalıştığı boşluğu kapatır.
Asistana nasıl kullanacağını anlatın
Araç listesi belge değildir. Adlar ve şemalar neyin var olduğunu söyler; ne zaman başvurulacağını ya da işlemlerin hangi sırayla yapılacağını söylemez. Beceri dosyalarının doldurduğu boşluk budur: istemcinin araçlarla birlikte yüklediği, iş akışlarını ve kısıtları anlatan düz metin.
Değerli olan kısım şemanın ifade edemediğidir — döküm uygulamadan önce yedek al; yıkıcı SQL'i önce kullanıcıya doğrulat; veritabanı adını tahmin etme, listele; bir araç eksikse bu bir izin ayarıdır, kabuğa dönmek için gerekçe değil.
BRAMPP bunu nasıl yapıyor
BRAMPP çalışan uygulamanın içinden 127.0.0.1 üzerinde bir MCP sunucusu yayınlıyor; siz açana kadar kapalı. Yukarıdaki beş kapsamda 23 araç sunuyor, burada anlatılan iki katmanlı izin modelini ve SQL kurallarını uyguluyor, ayrıca asistanın bunları nasıl kullanacağını bilmesi için iki beceri dosyası kuruyor.
MIT lisanslı, ücretsiz ve açık kaynak — sunucu, izin denetimleri ve SQL süzgeci sınırların tam olarak nerede olduğunu görmek isterseniz depoda.
← BRAMPP'e dön