凭什么信这个榜？
因为评分规则、数据来源、判定逻辑全部写在这一页，且每个 server 页都标注了数据来源与抓取时间。 不藏黑箱——你可以拿着同样的公开数据复核任何一个分数。
👤主理人
MCP Radar 由一个长期追踪 AI 工具生态的独立开发者维护。做这个站的原因很简单： 现有的 MCP 导航只告诉你"有这个工具"，没人告诉你"它是不是还活着"—— 装了一个弃坑的 server，调试半天才发现问题不在自己。这个判断完全可以自动化，于是我们做了，并且完全公开。
—— MCP Radar 主理人 （品牌署名位，后续可换真名）
评分方法论（完全公开）
TrustScore 满分 100，由五个维度加权得出，全部信号来自公开 API：
| 维度 | 权重 | 信号字段 |
|---|---|---|
| 维护活跃度 | 30% | 最近提交距今、90 天提交数、issue 平均响应、是否 archived |
| 采用度 | 25% | GitHub stars 及趋势（权重高于 npm 下载）、npm 周下载趋势、发版频率 |
| 可用性 | 20% | 是否在官方 registry、server.json 规范、能否解析可运行入口 |
| 健康度 | 15% | open issue/PR 积压比、license 是否明确 |
| 社区信号 | 10% | 贡献者数、fork 活跃度、awesome-list 收录数 |
生命周期判定规则
🟢 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 小时内更新： corrections@mcpradars.com