为什么「装上能跑」不等于「能用」
MCP server 的安装门槛极低——一行 npx 命令就能跑起来。但企业场景的真正问题是：这个 server 三个月后还有人维护吗？它处理凭证的方式安全吗？它的维护者响应安全漏洞要多久？
目录总量和生命周期数量会随每次数据快照变化，应以当前榜单为准，而不是引用固定的生态总数。
这份清单把尽调过程整理成可重复检查的项目；完成公开数据核验后，仍应在隔离环境中测试。
第一部分：活性检查（必查 5 条）
1. 查看最近一次 commit 的日期和实际改动内容；仅仅“很新”不能证明质量。
2. 检查 90 天提交记录里是否有真实修复、发布和依赖维护，不要只依赖单一阈值。
3. 抽查近期 issue 是否获得回复并最终关闭。MCP Radar 展示的是获回复比例，不是中位响应时间。
4. 检查仓库是否 archived；除非明确给出仍在维护的继任项目，否则应视为不再支持。
5. 是否有明确 license。无 license 的代码在企业法务上等于「保留所有权利」，不可用于商业场景。
第二部分：安全与合规
6. 凭证如何传递？优先选择通过环境变量注入的 server，警惕要求把 token 写进配置文件的实现——后者在多客户端环境下极易泄漏。
7. 是否有第三方托管依赖？托管型 server（如 Firecrawl、Exa）意味着你的数据会经过第三方服务器，需要评估其隐私政策……
第三部分：采用度交叉验证
把 stars、下载量和 forks 当作背景信号，而不是质量证明。核对 package 是否属于对应仓库、近期是否发布，以及独立用户是否报告成功接入。
附录：尽调清单
建议记录仓库与 package 身份、最后复核日期、license、所需权限、凭证处理、网络目的地、维护证据、回滚方案和复核负责人。