为什么「装上能跑」不等于「能用」
MCP server 的安装门槛极低——一行 npx 命令就能跑起来。但企业场景的真正问题是：这个 server 三个月后还有人维护吗？它处理凭证的方式安全吗？它的维护者响应安全漏洞要多久？
我们追踪了 1,247 个 MCP server 的维护数据，其中 137 个已弃坑、168 个超过半年无更新——也就是说，随便从「MCP 大全」类列表里挑一个，有接近四分之一的概率踩到僵尸项目。
这份清单把尽调过程固化成 12 条可逐项打勾的检查项，全部可以通过公开数据在 15 分钟内完成。
第一部分：活性检查（必查 5 条）
1. 最近一次 commit 距今是否 < 30 天。超过 90 天的项目，issue 响应率断崖式下降到 20% 以下。
2. 90 天内 commit 数是否 > 10。低于此数的项目通常只剩「续命式提交」（改 README、升版本号）。
3. open issue 的中位响应时间是否 < 7 天。可以在仓库 Issues 页按「最近评论」排序快速判断。
4. 仓库是否被 archived。 archived 仓库的 API 依赖会随时间腐坏，平均 6 个月后开始出现不可用。
5. 是否有明确 license。无 license 的代码在企业法务上等于「保留所有权利」，不可用于商业场景。