37.000 MCP sunucusuna toplu test: %89,6'sı yanıt verdi, üçte biri anahtar istiyor

Resmi Model Context Protocol kayıt defteri 62.000 sunucu kaydını aşmış durumda, ancak yayınlanan tavsiyelerin çoğu elden seçilmiş birkaç düzine sunuculuk listelere dayanıyor. Kendi MCP sunucu dizinini işleten NestDaddy farklı bir yol izledi: Şirket, kayıt defterindeki her uzak sunucuya bir MCP istemcisi gibi her gün bağlanıyor ve olan biteni kaydediyor. dev.to'da yayınlanan ilk kapsamlı çalışması, uzak uç noktalı 37.383 sunucyu inceledi ve agent araç ekosisteminin ilk geniş ölçekli ampirik resimlerinden birini sunuyor.

Test nasıl çalışıyor

Rapora göre her kontrol, bir kullanıcı sunucu eklediğinde Claude, Cursor veya VS Code'un yaptığı şeyi yansıtıyor: Streamable HTTP üzerinden initialize gönderiyor (ya da eski SSE transport'u için akışı açıyor), notifications/initialized gönderiyor, ardından tools/list istiyor. Hiçbir kimlik bilgisi gönderilmediği için HTTP 401, 403 veya 429 ile yanıt veren sunucu canlı ama anahtarın arkasına kilitli olarak sayılıyor. Her isteğin zaman aşımı 10 saniye ve tüm kontroller Avrupa'daki tek bir makineden yürütülüyor; yani yanıt süreleri internet üzerindeki yolculuğu da içeriyor.

Sunucuların onda dokuzu yanıt veriyor

Test edilen 37.383 uzak sunucudan 33.496'sı — %89,6 — yanıt verdi; rapor bu sonucu, herkesin yayın yapabildiği bir kayıt defteri için beklentiden iyi olarak niteliyor. 3.555 başarısızlık şöyle dağıldı: 1.156 bağlantı sorunu (DNS, reddedilen bağlantılar, TLS hataları veya zaman aşımları), 997 HTTP 404, 230 adet 503 yanıtı, 173 adet 400, 170 adet 405, 113 adet 502, 105 geçerli MCP initialize sonucu olmayan yanıt ve herhangi bir şey yapmadan önce ödeme isteyen 104 sunucu. 404 veya 405 genellikle kayıt girdisinin yanlış yolu işaret ettiği anlamına geliyor — örneğin gerçek MCP uç noktası yerine site kökünü — ki NestDaddy bunu bakımcıların doğrulaması gereken bir şey olarak işaretliyor.

Anahtarlar, gecikme ve araç şişkinliği

İki bulgu kullanılabilirliği zorluyor. Birincisi, 12.447 sunucu — yaklaşık üçte biri — 401 veya 403 ile yanıt verdi ve kimlik doğrulamasından önce hiçbir şey söylemeyi reddetti. Rapor bunun gerçek bir maliyeti olduğunu savunuyor: dizinler sunucunun araçlarını listeleyemiyor ve bir agent sunucunun işe yarar olup olmadığını değerlendiremiyor. NestDaddy, daha dostane bir yaklaşım olarak initialize ve tools/list'e açıkça yanıt verip anahtarı yalnızca tools/call üzerinde istemeyi öneriyor; böylece kullanıcılar kayıt olmadan önce ne kazanacağını görebiliyor.

İkincisi, ekosistem bağlam-ağırlıklı. Araçlarını açığa çıkaran 20.241 sunucuda toplam 292.447 araç sayıldı; sunucu başına medyan yedi; 815 sunucu tam olarak bir araç sunarken 4.325 sunucu yirmi veya daha fazla araç sunuyor. Her araç adı ve açıklaması, araç kullanılsa da kullanılmasa da her görüşmede modele gönderiliyor; dolayısıyla 30'ar araçlı beş sunucu bağlama 150 araç açıklaması önyüklüyor — rapora göre bu token maliyeti, modellerin doğru aracı seçmesini de zorlaştırıyor.

Buna karşılık gecikme sağlıklı görünüyor: sunucuların dörtte biri initialize'a 320 ms altında yanıt verdi, medyan yaklaşık 500 ms idi, %75'i 780 ms altında ve %90'ı 1,2 saniye altında kaldı; yalnızca 842 sunucu iki saniyeden yavaştı. Avrupa'dan ölçüldüğü için rakamlar yakın sunucuları şımartıyor, ama NestDaddy bunları protokolün kendisinin darboğaz olmadığının kanıtı olarak okuyor: Selam vermesi saniyeler süren bir sunucu genellikle soğuk başlatılıyor ya da ertelemesi gereken bir işi yapıyor.

Kayıt girdilerinin sekizde biri spam

Herhangi bir test yapmadan önce NestDaddy, 7.839 girdiyi — kayıt defterinin %12,6'sını — bariz şekilde toplu yayınlanmış olarak gizledi. Tek bir GitHub deposu 2.356 yayınlanmış sunucunun arkasındaydı, iki depo daha 2.200 sunucuya karşılık geliyordu ve bazı açıklamalar 150'den fazla girdide kelimesi kelimesine aynıydı. Toplu yayınlama her zaman spam değil ama: bir yayıncı tek bir gateway üzerinden her biri kendi araçlarının yanında aynı 12 temel aracı paylaşan, her genel API için bir tane olmak üzere 1.710 canlı sunucu çalıştırıyor. Kayıt defteri ayrıca hızla büyüyor: Ekim'de 17.515, kasımın ilk 13 gününde yalnızca 16.819 girdi yayınlandı ve rapor, kayıt defterleri daha güçlü denetimler eklemedikçe spam oranının büyümesini bekliyor.

Neden önemli

Bu, agent geliştiricilerinin artık bağımlı olduğu bir ekosistemin ilk büyük ölçekli mekanik ölçümlerinden biri ve pratik çıkarımları somut: anahtar istemeden araçlarını gösteren sunucuları tercih edin, araç listelerini kısa ve net açıklamalı tutun ve yayınlanan URL'nin gerçek MCP uç noktasını işaret ettiğini ana sayfa değil doğrulayın. Uyarılar gerçek: veriler kendi MCP dizinini satan tek bir şirketten geliyor ve her şey tek bir Avrupa bakış açısından ölçüldü; ama dizin her sunucuyu günlük olarak yeniden test ettiği için ileriye dönük ilginç sinyal trend çizgisi olacak: kayıt defteri büyümeye devam ettikçe temizlenecek mi, yoksa gürültülenecek mi?