已停维护的 MCP 服务仍被大量下载

MCP server 停止维护后，下载量还在涨。作者追踪了 GitHub、Postgres、Slack、Puppeteer 和 Brave Search 五个参考服务器：它们归档后的月下载量增长超过四倍，其中 Postgres 的安全修复已合并，却一直没有发布到 npm。

这篇调查真正提醒我们的是：批准安装，只完成了第一次检查。客户端能启动工具，不代表软件仍有人维护，也不代表装到的是已经修复的版本。

已经归档，为什么还在被安装

2025 年 5 月 29 日，Model Context Protocol 项目以「Archive unmaintained servers」为提交标题，归档了 14 个参考服务器。作者追踪的五个包，仍位列 npm 下载量最高的 30 个 MCP server 包之中。

它们没有从 npm 消失，只是被标记为 deprecated，即已弃用、不再受支持。README 里仍保留着通过 npx -y 安装的命令。

下载数据更能说明这种惯性：

• 2025 年 6 月，五个包合计下载 407,645 次；2026 年 7 月，达到 1,794,602 次。
• 从 2025 年 6 月起，累计下载约 1770 万次。
• 2026 年 10 月最后一个统计周，加上 CircleCI 的 npm 包，六个包下载了 632,516 次。CircleCI 已在当年 8 月弃用该包，转向托管服务器。

下载量不能直接当作用户数，CI 和镜像也会产生下载。因此，这些数字无法回答到底有多少人在新装、多少人在重复运行，但足以说明旧包仍在被持续获取。

作者也给了一个重要对照：仍在维护的 server-filesystem，同期月下载量从 174,541 增至 2,499,106。归档包搭上了 MCP 增长的顺风车，增长速度却低于这个仍维护的包。不能据此推断用户特别偏爱旧版本。

Postgres 的修复进了仓库，却没进安装包

2025 年 8 月，Datadog Security Labs 披露了 Postgres server 的 SQL 注入问题。服务器会把查询包在只读事务里，看起来限制了写入。

但查询可以先结束这个事务，再执行后面的语句。原文给出的例子是：

COMMIT; DROP SCHEMA public CASCADE;

要盯住开头的 COMMIT;：它结束只读事务，后续操作就取决于数据库账号本身拥有什么权限。如果账号有删库表结构的权限，服务器这一层的只读包装就挡不住。

更关键的是发布断层。修复在 2025 年 5 月 29 日合并，也就是服务器归档当天，但从未发布。作者调查时，npm 提供的仍是 2024 年 12 月发布的 0.6.2，不包含修复。

Datadog 披露时，这个包每周约下载 21,000 次；到 2026 年 10 月最后一个统计周，达到 164,787 次。

仓库里有修复，不等于用户安装的包已经修复。

弃用警告为什么没出现在聊天窗口

手动安装时，npm 会给出警告：

npm warn deprecated @modelcontextprotocol/server-postgres@0.6.2: Package no longer supported.

这里需要关注的是明确的包名和版本号，而不只是安装有没有成功。

作者实际测试了另一条常见路径：把配置块贴进 MCP 客户端，让客户端在后台运行 npx。首次启动时，警告输出到标准错误流 stderr，随后进入客户端日志，没有出现在聊天中。此后启动使用 npx 缓存，连警告也不再打印。

这是作者在所测客户端路径上的观察，原文没有证明所有客户端都这样处理。

不过，问题很清楚：服务器启动了，工具出现了，Agent 就能继续调用。用户最初的一次批准，没有自动变成后续的维护状态复查。这里甚至不需要软件发生变化，停止更新就足以让风险留下来。

我的判断

我认同作者把检查重点放到「实际安装的包」上。对使用 MCP 的程序员来说，README 能复制、进程能启动、工具能调用，都不足以证明当前版本适合继续使用。

Postgres 案例尤其说明，数据库权限应当在数据库层落实。服务器声明只读，可以作为一道限制；账号本身只有读取权限，才能在这道限制失效时继续约束操作。

但统计结论需要收住。作者没有提供独立用户数、新安装占比或客户端覆盖率，不能把 1770 万次下载解释成同等数量的用户暴露。下载数据来自 npm API，版本和弃用信息来自 npm registry，归档与合并日期来自 GitHub API。由于 10 月的每日数据存在报零缺口，作者采用了 10 月 26 日至 11 月 1 日这一完整周，累计量也只按下限报告。

固定版本同样有取舍：它能避免替代包更新后直接改变本地行为，却不能证明固定下来的版本安全。维护状态检查和升级复核仍然要做。

能拿来做什么

• 搜索本机及项目 MCP 配置中的 @modelcontextprotocol/server-，逐个执行 npm view <package> deprecated。有弃用消息的包应进入替换检查；没有消息，也不能单凭这一点认定维护活跃。
• 优先检查 GitHub server。原包 README 已指向 github/github-mcp-server，迁移时一并核对现有工具调用和权限配置。
• 如果仍在使用 Postgres server，让数据库账号只拥有所需的 SELECT 权限，不要依赖服务器的只读模式。原文提到 Datadog 推荐了包含修复的维护分支，但没有给出名称，不能据此直接指定替代包。
• 对保留和替换后的包固定版本，并在调整 MCP 配置时复查弃用状态、发布版本和修复记录。尤其要确认修复已经进入发行包，而非仅仅合并进仓库。