安装量为什么不可信，以及应该按什么排序

结论

安装量可以说明「被拷贝过」，不能说明「值得用」。目录如果只按安装量排序，就是在用一个发布者能够直接抬高、读者又无法复核的输入，充当质量信号。

这不是公关话术问题。公式不公开、输入又可刷时，面对刷榜指控没有任何自证路径。

公开记录里，数量本身就不可靠

2026 年 5 月，Glama 目录列出大约 22,775 个 MCP 服务器。同期评论指出，其中大量是分支、变体或已停止维护的周末项目。另一个安全分析样本大约覆盖 7,000 个公开服务器，发现约 36.7% 存在 SSRF 风险，约 41% 不要求认证，真正使用 OAuth 的比例很低。服务器「个数」和「还能安全交给 agent 的个数」不是同一个数。

技能侧也一样。Snyk 在 2026 年 2 月发布的 ToxicSkills 审计，扫描了来自 ClawHub 与 skills.sh 的 3,984 个技能：约 36.82%（1,467 个）至少有一处安全缺陷，约 13.4% 含关键级别问题；人工复核确认 76 个技能携带恶意载荷，公布时仍有一部分留在公开目录里。随后的 ClawHavoc 事件里，协调投毒的技能规模达到四位数。目录首页如果只展示「已发布超过一百万」这类累计口径，读者看不到这层过滤。

安装量还会被分发方式放大。2026 年对 skills.sh 榜单的追踪指出：捆绑包里的技能会跟着集合一起上涨，榜单无法区分「被人单独选中」和「被人连带安装」。一个技能四周内名次大涨，可能只是因为它进了某个合集。

所以旧稿里「全站超过一百万、全部时间视图只有 9,573、精选接口 342、Glama 自报 81,811、官方维护只有几百」这组对照，这次修订不再沿用。前半无法在当前页面复核，后半和 2026 年 5 月的目录规模对不上。能站住的是：原始条数、可维护条数、可安全安装条数，三者差一个数量级并不稀奇。

排序如果要抗刷，输入必须可被第三方重算

建议一个目录把排序拆成读者能点开的分项，而不是一个总分：

采用度建议封顶，例如不超过总分的 20%，并用对数而不是线性，因为这是发布者唯一能直接购买或捆绑的输入。20% 是编辑建议，不是本表已经上线的算法。权重如果对外承诺，就放在仓库里，每个技能页展示分项，不要只展示名次。

不要用的信号：未去重的累计安装、未说明窗口的「本周热门」、无法区分捆绑安装的榜首、只有徽章没有扫描记录的「已验证」。

读者可以自己做的三步

1. 点开技能页，找最近一次提交或发布的日期，而不是安装数。
2. 看权限声明是否写了 shell、网络、凭据。没写，就当未知，而不是当安全。
3. 若名次异常靠前，检查它是不是某个合集的成员。是的话，把合集的安装从「这个技能被选中」里减出去。

材料边界

Glama 约 22,775 与安全比例，综合 MCP Bundles 2026 年 5 月的目录综述。技能缺陷比例来自 Snyk ToxicSkills（2026 年 2 月）的公开摘要。捆绑安装扭曲榜单，来自 2026 年对 skills.sh 追踪榜的评论。这些数字会过期，引用时带上月份。