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.

MCP'nin yerel geliştirmede değiştirdikleri · izin kapsamları · güvenli bir araç yüzeyi neye benzer

"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:

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 yokOkumaOkuma + yazma
Alan Adlarıgörünmezlistelemeoluşturma, güncelleme, uygulama başlatma
Servislergörünmezdurum, sağlıkbaşlat, durdur, yeniden başlat
Veritabanlarıgörünmezlisteleme, salt-okunur SQLoluşturma, yedek, geri yükleme, yazma
Loglargörünmezokuma

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