4.951 MCP sunucusunun analizi, yaklaşık 30 tool'dan sonra tanımların ayırt ediciliğini yitirdiğini ortaya koydu

Rakam ve nereden geldiği

MCP sunucusu bakımı yapan herkes zamanla sunucunun kaç tool açması gerektiğini merak eder ve şimdiye kadar buna yanıt verecek neredeyse hiç kanıt yoktu. dev.to'da yayımlanan bir analizde, gerçek trafik geldiğinde modellerin tool'larla gerçekte ne yaptığını raporlamayı amaçlayan bir SDK olan MCPulse'ü geliştiren geliştirici, 4.951 herkese açık sunucunun şemalarını — toplam 87.146 tool ve 270.487 parametre — inceleyip bir rakama ulaştı: otuz civarı. Bu noktanın ötesinde, diye devam ediyor argüman, kaygı sunucunun çalışıp çalışmadığından bir modelin tool'larını hâlâ birbirinden ayırıp ayıramadığına kayıyor.

Ayırt ediciliğin ölçülmesi

Yazar, her tool için distinctive share adını verdiği bir değer hesaplamış: tool'un tanımındaki, aynı sunucudaki başka hiçbir tool tanımında geçmeyen içerik kelimeleri. Sıfır alan bir tool, modele yazılı metinde seçim yapacağı hiçbir şey bırakmaz; bu durumda farklılaştırmayı tek başına tool'un adı üstlenmek zorundadır.

Sunucu büyüklüğüne göre gruplandırıldığında, sıfır ayırt ediciliğe sahip tool'ların oranı istikrarlı biçimde yükseliyor: bir ila üç tool'luk sunucularda %0,5, dört ila yedide %1,6, sekiz ila on beşte %4,3, on altı ila otuzda %7,7, otuz bir ila altmışta %16,3 ve altmıştan fazla tool'luk sunucularda %31,3 — yani her üç tooldan neredeyse biri hiç ayırt edici kelime içermiyor. Kovalar arasında bu kabaca altmış katlık bir artış.

Eğri neden otuz civarında dikleşiyor

Eğilimin bir kısmı aritmetik: daha fazla tool, iki tanımın örtüşmesi için daha fazla fırsat demek. Ama yazar, otuz civarındaki keskin kırılmayı yazım davranışındaki bir değişime bağlıyor. Bu büyüklüğün ötesinde tanımlar tek tek yazılmayı bırakıp bir kalıptan üretilmeye başlıyor ve şablondan gelen metin birbirine benzeyen tool'lar ortaya çıkarıyor. Corpus'taki en çarpıcı örnek, 275 tool'unun tümüne aynı 51 kelimelik bağlam bloğunu ekleyen bir sunucu; burada create-collection tool'u ile buy-NFT tool'u yalnızca elli dokuz kelimeden sekizinde farklılaşıyor.

İyi yazılmış, ayırt edilebilir demek değil

Analiz, yaygın biçimde kurulu bir Gmail sunucusu üzerinden sezgilere aykırı bir noktaya değiniyor. Taslağı silme, taslak gönderme, etiketleri listeleme ve konuşmaları arama tool'larının her biri, hiçbir gözden geçirenin eleştiremeyeceği düz ve doğru bir İngilizceyle tanımlanmış — ama bu tanımlardaki delete ve draft'tan email, API, list, search ve mailbox'a kadar her kelime set içinde yineleniyor. Bir tanım, bir tool'un ne yaptığını söyleyebilir ama bu tool'un kardeşlerinin yapmadığını söyleyemeyebilir ve modelin seçim anında ihtiyaç duyduğu ikinci özellik işte tam budur.

Sunucuyu bölmek yalnızca bir sorunu çözüyor

Verideki ikinci metrik olan hiç tanımı olmayan parametrelerin oranı, sunucu büyüklüğüyle neredeyse hiç değişmiyor: en küçük kovadaki %14,8 düzeyinin üstündeki her seviyede kabaca %20 ile %25 arasında. İki tool'luk bir sunucu, iki yüz tool'luk bir sunucu kadar bu alışkanlığa sahip. Sonuç: iki sorun birbirinden bağımsız — büyük bir sunucuyu bölmek tanım çakışmalarını azaltıyor ama tanımsız parametrelere hiçbir şey yapmıyor; onların kendi başına bir çözüme ihtiyacı var.

Bakımcılar gerçekte ne yapmalı

Öneri, bir eşiğin aşıldığı için değil, çakışmalar gerçek olduğunda bölmek. Otuz, bir popülasyon ortalaması; gerçekten birbirinden farklı işlemlerden oluşan kırk tool'luk bir sunucu sorun olmayabilirken, birbirine neredeyse özdeş dört arama varyantı barındıran on iki tool'luk bir sunucu sorun olabilir. Önerilen test, tool listesini bir modelin aldığı biçimde, README ya da repository bağlamı olmadan tek bir blok olarak okumak ve makul biçimde ikisine de gidebilecek bir istek için hangi tool'u seçeceğinizi kendinize sormak.

Yanıt belirsizse üç çare var. Tanımları netlik için değil karşıtlık için yeniden yazın; tek ayırt edici cümleyi sulandıran ortak giriş metinlerini çıkarın. Birbirine neredeyse özdeş tool'ları, bir mode parametresine sahip tek bir tool'a indirin; bu, modelin seçimini bir tool seçmekten, bir enum'un kısıtlayabileceği bir değer seçmeye taşır. Ya da sunucuyu bölin; tool'lar gerçekten farklı alanlara aitse buna değer, yalnızca rasgele bir listeyi ikiye bölüyorsa o kadar değil.

Bilinen sınırlılıklar

Çalışma statik bir analiz: bu sunuculara karşı hiçbir model çalıştırılmadı, bu yüzden sıfır ayırt ediciliğe sahip bir tanımın gerçekte ne sıklıkla yanlış seçime yol açtığını ya da net bir tool adının bunu ne kadar telafi ettiğini söyleyemiyor. Sinyalleri gerçek hatalarla sıralamak için devrede bir model gerekiyor ve yazar bunu bir sonraki çalışma olarak belirliyor. Parametre rakamı da yalnızca yokluğu ölçüyor — yalnızca parametre adını yineleyen bir tanım hâlâ geçerli sayılıyor; bu boşluk, yayından sonra bir sunucu yazarı tarafından işaretlendi — yani bildirilen oran bir taban değer. Veri seti ve analiz betikleri GitHub'da yayımlandı ve ücretsiz, tarayıcı tabanlı bir denetleyici tek bir sunucunun tool listesini corpus'a karşı puanlıyor.

Neden önemli

MCP, modeller ile harici yazılım arasındaki standart arayüz hâline geliyor ve bu, sunucu tasarımının bir modelin ne görebileceğini nasıl şekillendirdiğine dair ilk popülasyon ölçekli kanıtlardan biri. En faydalı katkısı bir bakış açısı değişikliği: kısıt ham tool sayısı değil, tanımların ayırt edici olması — büyüklükle ve şablonsuz yazımla öngörülebilir biçimde yıpranan bir özellik. Ayrıca bölmek yalnızca birbirinden bağımsız iki başarısızlık biçiminden birini ele alarak kolay çözümü de geçersiz kılıyor. Agent'ların runtime'da göz atacağı MCP sunucuları gönderen herkes için tanım yazmak, belgeleri cilalamak değil, ölçülebilir başarısızlık biçimlerine sahip arayüz mühendisliğidir.