20 条 MCP 安装命令实测，仅半数启动成功

从 MCP 目录复制一条安装命令，究竟有多可靠？Anclum 团队在 2026 年 11 月 7 日抽取自家目录里的 20 个服务器，把提取出的命令原样放到干净的 Linux 主机上执行：10 个启动，6 个失败，4 个无法判断。

更有用的发现藏在失败原因里：6 次失败中，作者认定有 5 次是目录自己的处理流水线造成的。对经常给 AI 编程工具接 MCP 的程序员来说，这次测试提醒我们：项目能不能用，与目录里的命令能不能信，是两件需要分别验证的事。

10 个启动，不等于 10 个已经可用

他们没有挑最熟悉的项目，而是按安装方式分层取样：5 个 Claude 风格命令、5 个 npx、3 个 pip、3 个 uvx、2 个 docker，以及 2 个 Go/Cargo。

测试机有 Node、Python 和 Rust 工具链，没有 Docker 和 Go。规则要求原样执行命令，不提前修拼写，也不补上「显然应该有」的参数。

但不同安装方式的通过标准并不相同：

• 对 npx、uvx，以及 claude ... -- <launcher>，进程启动并持续存活就算通过，因为使用标准输入输出通信的 stdio 服务器通常会等待输入。
• 对 pip，只检查能否装进干净的 virtualenv，以及入口能否解析。作者明确承认，这只能证明安装成功。
• Docker、Go 等宿主机前置条件缺失，以及无法判断的运行结果，单独记录，不算失败。

因此，标题里的「10 个启动」不能直接读成「10 个功能正常」。原文甚至发现了一次假通过：提取器把 MCP inspector 的调试示例当成安装命令，启动的是 inspector，进程也确实活着，却不是目标服务器。

进程存活只能证明启动检查过关，不能证明接入了正确的 MCP 服务。

为什么目录复制一次，命令就坏了

最典型的问题来自文本清洗。目录把 _ 当成 Markdown 强调符号删掉，SCAVIO_API_KEY 变成了 SCAVIOAPIKEY。包装好了，服务器却读不到预期的环境变量，随即退出。VERIFYAX_API_KEY 也遇到了同类问题。

另一个服务需要 ICTBROADCAST_BASE_URL、ICTBROADCAST_USERNAME 和 ICTBROADCAST_PASSWORD，但目录提取出的安装行没有这些变量。这里出错的是运行配置，重新安装包未必有帮助。

命令边界识别也会出问题。下面这段原样保留的错误提取结果，把 README 后面的解释文字吞了进去：

claude mcp add tmux -- mcp-tmux defaults to local (project) scope, which is

要看的是 defaults to local (project) scope, which is：这些是说明文字，混进 shell 后会触发语法错误。原文给出的正确行只有 npx -y mcp-tmux。

还有一种错误更不起眼：npx umbra-scan. 的包名末尾多了句点，npm 返回 404。删除这个字符后，服务器能够启动，并输出有效的信任评分。

目录把 README 转成「可复制命令」时，实际上已经做了一次程序转换。删字符、拼文本、选错代码块，都可能改变执行结果。

作者随后修复了下划线清洗，增加了句子式文本和包名末尾标点检查，并明确标注需要 Docker 的服务器。这些都是具体改动，但原文没有提供修复后的完整复测结果，不能据此推算新的成功率。

哪些失败应该继续排查，哪些只能暂时挂起

并非所有问题都能靠修提取器解决。

一个项目依赖的托管服务命名空间已经返回 404，底层包不再可用。这与命令多一个句点造成的 npm 404 不同，修改本地命令未必能解决。

另一个 Rust 服务器在 120 秒截止时仍在编译。团队没有把它判成失败，因为这个窗口内无法分辨它只是慢，还是已经卡住。换一台性能更好的机器，结果可能不同。

Docker 和 Go 也暴露了测试条件的边界。方法说明写着 docker/go/cargo 应先安装工具链，再运行文档命令；实际环境却没有 Docker 和 Go，并把缺少前置条件的情况单列。原文没有交代这两段规则如何衔接，读结果时应保留这个问号。

测试结论适合回答「这些命令在这台机器上发生了什么」，不适合回答「MCP 生态有一半不能用」。20 个样本、单台机器、单日测试，以及不同安装方式采用不同通过标准，都限制了外推范围。

我的判断

我认同作者把目录自身的责任公开出来。开发者遇到启动失败，很容易先怀疑包版本、运行时或者模型配置。这次测试给出了更靠前的排查位置：命令在转载过程中有没有被改坏。

不过，作者提出「变量带下划线时，可以试试不带下划线的名字」，这个建议不能照单全收。按他们自己的故障描述，程序读取的是带下划线的变量，损坏的是目录里的变量名。更稳妥的处理是对照上游 README 或启动错误，恢复程序实际要求的名称，而不是盲猜变体。

这次实测证明了启动检查能抓住文本处理错误，也暴露了它会放过 inspector 这样的错误目标。若要证明服务可接入，还应继续验证 MCP 握手、工具发现及一次实际调用；这些验证没有出现在原文里。

作者没有提供其他目录、修复前后或不同机器之间的对照数据。因此，这是一份有价值的故障样本，不能当成目录可靠性排名，也不能拿「10/20」作为自己的选型成功率。

能拿来做什么

• 给 AI 编程工具接入 MCP 前，先对照上游 README 检查目录命令，重点看环境变量下划线、包名末尾标点，以及命令后是否混入解释文字。
• 遇到 Node 包安装成功、进程立即退出的情况，先核对启动参数和必需环境变量，再决定是否重装依赖，避免把配置错误当成安装错误。
• 如果团队维护 MCP 清单或自动提取脚本，应保留原始命令与提取结果，并把「安装成功」「持续存活」「实际调用成功」分开记录。
• 对源码编译设置明确的等待窗口，同时记录机器条件和编译状态。到时仍在编译可以标成「未判断」，不要直接给项目贴上不可用标签。