Yerel büyük dil modellerini (LLM'ler) kullanan geliştiriciler, tek bir Multi-Channel-Protocol (MCP) sunucusunun, kullanıcı henüz bir istem (prompt) yazmadan tüm bağlam penceresini tüketebildiğini fark ediyor. Ya kısıtlı araç açıklamalarıyla ya da bozulan bir konuşma akışıyla karşı karşıya kalıyorlar.

Yerel LLM'ler için token şişmesi neden önemlidir?

MCP, modele her bir aracın açıklamasını besleyerek bir LLM'nin harici araçları —API'ler, betikler veya dosya sistemi yardımcı programları— çağırmasına olanak tanır. 128k token pencereli bulut tabanlı modeller, birçok araç tanımını absorbe edebilir ve hala kullanıcı diyaloğu için yer bırakabilir. Yerel olarak çalışan ve 8k token pencereli 7 milyar parametreli bir model, sadece birkaç aracı yükledikten sonra yer kalmadığı için tıkanır. İkilem oldukça keskindir: kısa ve ucuz açıklamalar çağrıları yanlış yönlendirir; uzun ve ayrıntılı açıklamalar ise sohbet için gereken bütçeyi tüketir.

Buraya yol açan olaylar zinciri

MCP, özel entegrasyon kodlarının yerine birçok veri kaynağına tek bir model odaklı arayüz getirmek için oluşturuldu. Çoğu MCP sunucusu, makineler için değil, insan operatörler için tasarlanmış REST uç noktalarının etrafındaki ince sarmalayıcılar (wrappers) olarak işlev görür. Bu sarmalayıcılar yerel bir LLM oturumuna dahil edildiğinde, model hangi aracı çağıracağına karar vermeden önce her aracın adını, parametrelerini ve kullanım notlarını okumak zorundadır. Küçük bağlam pencereleri, bu "açıklama yükünü" yapısal bir darboğaza dönüştürür.

Kim kazanıyor, kim kaybediyor

  • Cihaz içi asistanlar geliştiren geliştiriciler esnekliği kaybeder. Ya sık sık hata alma riskini göze alarak araç kataloglarını budarlar ya da kullanıcı girdisini kesintiye uğratan şişkin bir istemi kabul ederler.
  • Son kullanıcılar, asistan yanlış aracı seçtiğinde veya bağlam dolu olduğu için işlem yapmayı reddettiğinde tutarsız davranışlarla karşılaşır.
  • Araç sağlayıcıları tek tip bir giriş noktası kazanır.

Maliyet sadece daha kötü bir deneyim değildir; aynı zamanda güvenlik endişelerini de beraberinde getirir. Bir MCP ajanı herhangi bir yerel dosyayı okuyabildiğinde, izin modeli "ya hep ya hiç" noktasına geriler. Bir sandbox (kum havuzu) olmadan, yanlış yapılandırılmış bir araç tüm dosya sistemini açığa çıkarabilir.

Geliştiriciler bu konuda ne yapıyor?

Toplulukta üç çözüm yöntemi hakimdir:

  • Açıklamaları budamak – Araç meta verilerini en temel düzeye indirger. Bu, token tasarrufu sağlar ancak modelin yanlış uç noktayı seçme olasılığını artırarak geliştiricilerin yakalayıp yeniden denemesi gereken hatalara yol açar.
  • Dinamik yükleme – Yalnızca mevcut konuşmayla ilgili olan araç alt kümesini yükler. Hafif bir dağıtıcı (dispatcher), kullanıcının niyetine bağlı olarak hangi araç setinin enjekte edileceğine karar verir. Bu, boşta duran token kullanımını azaltır ancak gecikme süresini ve kod karmaşıklığını artırır.
  • Aktif sunucuları sınırlamak – Oturum başına MCP sunucusu sayısına sınır getirerek geliştiricileri en temel entegrasyonlara öncelik vermeye zorlar. Bu, istem boyutunu yönetilebilir tutar ancak yetenek kapsamından ödün verir.

Bu çözümlerin hiçbiri mucizevi bir çözüm değildir. Açıklamaları budamak güvenilirliği zedeler; dinamik yükleme yanıtları yavaşlatan bir karar katmanı ekler; sunucuları sınırlamak ise hangi veri kaynaklarının destekleneceği konusunda zor seçimler yapmayı gerektirir.

Token sorunuyla birlikte gelen güvenlik riskleri

Yerel ajanlar genellikle kısıtlanmamış dosya sistemi erişimiyle çalışır. MCP protokolü, "bu klasörü oku" ile "her şeyi oku" arasında bir ayrıntı düzeyi (granularity) sunmaz. Bazı ekipler, tam erişim sorununu çözmek için geçit (gateway) katmanları oluşturarak daha fazla karmaşıklık eklemiştir. Bu geçitler "tam kontrol" sorununu hafifletir ancak kod tabanını da büyütür.

Küçük modeller için araç tasarımı

Büyük bulut modelleri kötü açıklamalardan kurtulabilir, bu nedenle geliştiriciler bazen hassas araç tanımlarına duyulan ihtiyacı gözden kaçırabilir. Yerel modeller için şu ilkelere uyun:

  • Dar kapsamlı işlevsellik – Her araç tek bir iş yapmalıdır. Dosya yazma yeteneği de olan bir "arama" aracı, çakışan sorumlulukları takip edemeyen bir modeli şaşırtacaktır.
  • Belirsiz olmayan isimlendirme – "process" veya "handle" gibi genel isimlerden kaçının. İsimler, modelin zihinsel yükünü azaltacak şekilde tam işlemi iletmelidir.
  • Net ve özlü açıklamalar – Yalnızca modelin karar vermek için gerçekten ihtiyaç duyduğu parametreleri dahil edin. Modelin kalıpları hızlıca tanıyabilmesi için tutarlı bir format kullanın.

Karşı görüş: Protokolün hala bir değeri var

Sürtünmeye rağmen MCP, basmakalıp kodları soyutladığı için cazibesini koruyor. Tek bir model odaklı arayüz, her biri için özel adaptörler yazmaya gerek kalmadan düzinelerce servise bağlanabilir. Bulut ölçeğinde modeller kullanabilen ekipler, token şişmesini bir sorun olarak görmez ve sağladığı kolaylık, getirdiği yüke değer. Zorluk, bu kolaylığı cihaz içi LLM'lerin kısıtlı dünyasına aktarabilmektir.

Özet

Cihaz üzerinde çalışan bir asistan geliştiriyorsanız, MCP araç açıklamalarını kıt bir kaynak olarak değerlendirin. Bağlam penceresini asıl konuşma için canlı tutmak adına araçları budayın, dinamik olarak yükleyin ve dar kapsamlı tasarlayın. Aynı zamanda, birkaç ekstra token maliyetine yol açsa bile bir izin katmanı ekleyerek örtük “tam erişim” güvenlik modeline karşı önlem alın. Kuracağınız denge, yerel LLM'nizin yardımcı bir yol arkadaşı mı yoksa bozuk bir sohbet botu mu gibi hissettireceğini belirleyecektir.