凭什么信这个榜？
因为评分规则、数据来源、判定逻辑全部写在这一页，且每个 server 页都标注了数据来源与抓取时间。不藏黑箱——你可以拿着同样的公开数据复核任何一个分数。
👤主理人
MCP Radar 由编辑与数据团队维护。我们汇总公开的仓库、软件包和 Registry 信号，帮助读者初步识别维护风险。TrustScore 只是筛选信号，不是安全认证，也不能替代在你自己的环境中测试。
—— MCP Radar 编辑团队 研究、数据复核与方法维护
评分方法论（完全公开）
TrustScore 满分 100，由五个维度加权得出，全部信号来自公开 API：
| 维度 | 权重 | 信号字段 |
|---|---|---|
| 维护活跃度 | 30% | 最近提交距今、90 天提交数、近期 issue 获回复比例、是否 archived |
| 采用度 | 25% | GitHub stars 及趋势（权重高于 npm 下载）、npm 周下载趋势、发版频率 |
| 可用性 | 20% | 是否经官方 Registry 验证、是否提供可安装 package 或远程端点、仓库可审计性 |
| 健康度 | 15% | open issue 数量、仓库是否声明 license |
| 社区信号 | 10% | 贡献者数与 fork 活跃度 |
生命周期判定规则
🟢 active
正常维护
🟡 dying
最近提交 > 180 天 且 无 issue 响应 且 无新 release
⚰️ dead
仓库 archived == true
⚪ unverifiable
纯 remotes 型（无开源仓库/无包），无法审计
「有仓库可审计」作为可用性加分项——纯远程服务无法验证其行为，本身就是风险信号。
数据来源与限制
| 来源 | 提供字段 | 已知局限 |
|---|---|---|
| MCP 官方 registry | 清单、repo url、包名、官方 status、发布/更新时间 | 不给 stars / 活跃度 / 下载量 |
| GitHub API | 最近提交、90 天提交数、近期 issue 获回复比例、archived、stars、forks、open issues、license、贡献者 | — |
| npm registry | 周下载量、版本发布时间线 | 低估 GitHub 直装的 server |
更新频率：健康数据每日增量扫描，每周全量 diff（雷达页数据来源）。
我们主动认边界：纯 remotes 型 server 拿不到仓库信号，一律标 unverifiable；npm 下载量会低估走 GitHub 直装的 server，所以 stars 权重更高；抓取有延迟，个别刚恢复维护的项目可能仍被短暂标为 dying——这正是我们开放更正通道的原因。
利益披露
本站接受详情页赞助展示位（页面明确标注「赞助」），但排名、评分、分类绝不接受任何形式的竞价。赞助只能买到展示位，买不到分数。一旦接受排名竞价，独家数据的可信度就会崩塌——那是这个站的地基，不卖。
查看赞助规则 →数据更正 / 死亡判定申诉
维护者认为某个 server 的评分或判定有误（例如已恢复维护、仓库迁移）？提供仓库地址与说明，我们人工复核后 48 小时内更新： wangknit@gmail.com