MCP Registry, Glama gibi dizinlerin yalnızca bir kopyasını sunduğu gerçek kaynaktır

Bir MCP sunucusu yayımlamak iki ayrı adımı içerir ve bunlardan yalnızca birini tamamlayan geliştiriciler farkında olmadan güncel olmayan yazılım teslim eder. PhilipAD tarafından 5 Ekim 2026'da yayımlanan bir dev.to yazısının ana savı budur; yazı, yapay zekâ ajanlarının MCP sunucularını gerçekte nerede aradığını adım adım anlatıyor ve daha iyi bilinen dizin sitelerinin değil, resmî MCP Registry'nin sistem kaydı (system of record) olduğu sonucuna varıyor.

Bir değil, iki yayım

İlk adım, paket yayımlayan herkese tanıdık gelecektir: sunucu ikili dosyasını (binary) npm veya PyPI'ye göndermek. İkinci adım ise yazarın çoğu kişinin atladığını söylediği, meta veriyi resmî MCP Registry'ye yayımlamaktır. Glama, PulseMCP, mcp.so ve Smithery gibi dizin siteleri bağımsız registry'ler değildir. Yazıya göre bu siteler, resmî registry'nin sunduğu her şeyi yeniden tarayıp önbelleğe alır. Kayıt yetkiliRegistry'de bulunur; dizinler ise aşağı akış kopyalarıdır.

Registry kodu değil, meta veriyi saklar

Bu ayrım somut bir hata biçimi yaratır. Registry ikili dosyanın kendisini değil meta veriyi tuttuğundan, yalnızca npm'yi güncellemek registry'nin sunucunuz hakkındaki görünümünü hiç değiştirmez. Yazar, 1.5.0 sürümünü npm'ye yayımlayıp registry adımını atladığı durumu şöyle anlatıyor: registry'nin latest uç noktası (endpoint) önceki sürümü, hâlâ true olarak işaretlenmiş isLatest bayrağıyla dönmeye devam eder. Registry üzerinden çözümleme yapan istemciler bu durumda, yerini alması amaçlanan sürümü değil eski derlemeyi kurar. İki sistem ayrı komutlarla güncellendiğinden, ikisi eşit tutulmadıkça sürünme (drift) kaçınılmazdır.

Sürünme nasıl kontrol edilir

Registry'nin API'si herkese açık olduğundan bu uyuşmazlık doğrulanabilir. Yazı, registry.modelcontextprotocol.io üzerinde bir sunucunun en güncel kaydını çözümleyen sürümlü bir uç noktaya işaret ediyor ve ağırlığı taşıyan dört alanı vurguluyor: version, updatedAt, isLatest ve status. Önerilen kontrol şudur: en güncel sürümü registry üzerinden çözümleyin, dönen sürüm dizesini paket yöneticisinin bildirdiğiyle karşılaştırın ve yanıtın _meta bloğunu okuyun. Registry paket yöneticisinin gerisinde kalıyorsa, onun üzerine kurulu her liste de eskimiştir.

Dizinler daha da geride kalır

Dizin önbelleleri daha büyük bir gecikmeyle geride kalır. Yazara göre 5 Ekim 2026 itibarıyla Glama'daki sunucularının sayfası, uygulama MetricBridge olduktan haftalarca sonra bile yeniden adlandırmadan önceki markayı hâlâ gösteriyordu. Çıkarılacak ders şudur: önbellekler siz yayımladığınızda değil, bir şey onları yeniden taradığında güncellenir; dolayısıyla bir dizin sayfası aynı anda hem npm'nin hem registry'nin gerisinde kalabilir.

Açıklamalar keşfi şekillendirir

Hassas verilerle çalışan sunucular için registry açıklaması ekstra iş yapar. Bulut bağlayıcısını yerel bir bağlayıcının üstünde sıralayan dizin, bir gizlilik yargısı değil, zaman damgalarını okuyordur. Yazarın yerel, salt okunur sunucular için tavsiyesi, bunu registry açıklamasında açıkça belirtmektir; çünkü keşif sırasında hem dizin listelerinin hem LLM'lerin kullanıcılara aktardığı şey bu metindir.

Neden önemli

MCP, yapay zekâ ajanlarını genişletmenin standart mekanizması hâline geldi ve keşif giderek registry'nin ve onu yansıtan dizinlerin üzerinden akıyor. Bayat bir registry kaydı, bir liste sitesinde yalnızca kozmetik bir sorun değildir: ajanların ne kuracağına karar verdikleri mekanizma budur; dolayısıyla güncel olmayan meta veri, doğrudan kullanıcı makinelerinde çalışan güncel olmayan yazılıma dönüşür. MCP sunucusu yayımlayan ekipler registry yayımını, sonradan akla gelen bir adım olarak değil, sürüm sürecinin zorunlu bir parçası olarak görmeli ve bir sürüm yükseltmesi ajanların beklediği yerde görünmediğinde dört meta veri alanını denetlemelidir.