MCP 服务器怎么选：一份从 6,000+ 个 server 里长出来的决策清单
TL;DR
- 目录里现在有 6,775 个 MCP server，但只有 28.7% 能在 README 里找到一条可执行的安装命令；21.8% 没有明确许可证；20.4% 的仓库已经沉睡 1–2 年。
- 选型不是"挑 star 最多的"，而是三步：五分钟初筛仓库 → 把工具定义当 API 读 → 用只读权限跑 30 分钟实测。
- 安全审查可以浓缩成一句话：假设这个 server 会看到它不该看到的数据，然后去验证它没有。
一、为什么"选型"比"有没有"更难
MCP 生态已经不缺 server 了。缺的是"能装、能用、能长期用"的那一小部分。
我们分析了目录里 5,945 个 MCP server 的公开数据（完整报告），有三个数字值得每个选型的人记住：
| 指标 | 数值 | 含义 |
|---|---|---|
| README 里能抽出一条可执行安装命令 | 28.7% | 超过七成的安装路径是断的 |
| 许可证为 MIT / Apache-2.0 等明确宽松协议 | 73.2% | 商用基本不会撞墙 |
| 未标注许可证或 NOASSERTION | 21.8% | 你得自己判断能不能用 |
| 最近 6 个月有提交 | 64.2% | 三分之一已经不再活跃 |
| 沉睡 1–2 年 | 20.4% | 每五个里有一个 |
再叠加一个更反直觉的事实：star 数几乎不能作为质量信号。 62.8% 的 server 不足 100 星，中位数只有 64；而前 1% 的仓库拿走了 47.5% 的 star。一个几十星的 server 可能是某个团队的生产依赖，一个上万星的仓库也可能只是被 HN 推过一次。
所以默认策略应该是：不信任任何单一指标，按流程验证。
二、先回答三个问题
在打开任何仓库之前，先写下这三行。写不出来，就不要开始选型。
- 它要替你做哪一件具体的事？
不是"接一个数据库"，而是"让 agent 能以只读方式查询
orders和refunds两张表，并按天聚合"。任务越具体，后面越容易判断"够用"。 - 它能看到、改到什么数据？ 只读还是可写？单库还是整实例？能不能碰到文件系统、环境变量、内网地址？这条边界决定了安全审查的严格程度。
- 出问题谁负责？ 个人试验可以宽松；一旦进团队工作流，就必须有人负责升级、审计和回滚。
三、五分钟初筛：看仓库，不看 star
打开仓库，按顺序看六件事，任何一项不过就直接淘汰——五分钟足够。
| 检查项 | 合格线 | 为什么 |
|---|---|---|
| 最近提交 | 6 个月内有 | 生态变化快，一年不动基本等于弃坑 |
| Release / Tag | 有版本号 | 能锁定版本，才谈得上回滚 |
| License | MIT / Apache-2.0 等明确协议 | 没有许可证 = 默认不能商用 |
| README 安装段 | 一条可复制命令 + mcpServers JSON |
70% 的仓库卡在这里 |
| Issue 区 | 近三个月有人回复 | 判断维护者是否还在 |
| 依赖与构建 | 依赖少、有 CI | 依赖越多，供应链风险越大 |
# 用 GitHub CLI 快速看四项
gh repo view owner/repo --json pushedAt,licenseInfo,latestRelease,stargazerCount
gh api repos/owner/repo/issues?state=open\&per_page=5 --jq '.[].updated_at'
一个经验法则：如果一个 server 的 README 需要你读十分钟才知道怎么启动，它大概率也不适合放进生产。 这不是作者能力问题，而是"可安装性"没有被当成功能来做。
四、把工具定义当 API 读
MCP server 的真正接口是它暴露的 tools。README 是给人看的，工具定义是给模型看的，后者决定它好不好用。
打开 server 的 tools/list 返回（或者源码里的 schema），重点看五件事：
1. 工具数量 超过 20 个工具就要警惕：工具定义会占用上下文，模型在几十个相似工具里选错的概率显著上升。好的实现会分组、提供"先搜索再调用"的两段式入口，或者允许按需开启子集。
2. 描述是否说清了边界
差的描述：Query the database.
好的描述：Run a read-only SQL query against the analytics replica. Rejects writes, DDL and statements without a LIMIT. Returns at most 500 rows.
后者告诉模型：能做什么、不能做什么、超限怎么办。
3. 参数 schema 是否严格 有类型、有必填、有枚举、有默认值。自由字符串参数越多，模型越容易编造。
4. 破坏性操作有没有标注
MCP 规范支持 readOnlyHint、destructiveHint、idempotentHint 等注解。一个删除类工具如果没有 destructiveHint: true，客户端就没法在调用前要求确认——这是设计缺陷。
5. 失败时的行为 调用失败返回的是结构化错误（错误码 + 可读信息 + 修复建议），还是一坨堆栈？是否可安全重试？大结果集有没有分页？
// 值得信任的工具定义长这样
{
"name": "search_orders",
"description": "Search orders by customer email or order id. Read-only. Returns at most 50 rows per page; use cursor for the next page.",
"annotations": { "readOnlyHint": true, "openWorldHint": false },
"inputSchema": {
"type": "object",
"properties": {
"email": { "type": "string", "format": "email" },
"cursor": { "type": "string" }
},
"additionalProperties": false
}
}
五、安全审查：按"它能造成多大破坏"排序
MCP 把外部系统接进了模型，风险也随之进来。按破坏力从大到小检查：
- 权限是否最小化 只读 token、限定库表、独立账号。能用只读副本就不要连主库；能限定 schema 就不要给整实例。
- 密钥怎么存 环境变量是底线，不是上限。是否支持 secret manager？会不会把 key 打进日志或错误信息？
- 是否执行任意代码
eval、exec、动态安装依赖、从网络下载并运行脚本——每一条都需要额外理由。 - 网络出口是否可控 能访问任意 URL 的 server，等于给了模型一个 SSRF 和数据外泄通道。理想情况下应限制白名单域名。
- 工具输出会不会被当成指令 这是 prompt injection 的主要入口：网页、issue、邮件内容里的一句话，可能让 agent 去调用另一个工具。选型时要看它是否对返回内容做隔离/标注，是否默认不把外部文本当指令。
- 供应链
npm 包是谁发的、多久没更新、有没有
postinstall脚本、依赖树里有没有奇怪的包。 - 审计与开关 能否记录每一次工具调用？能否单独关闭危险工具？没有审计的 server 不适合进生产。
远程 server 还要多问三句：OAuth 的 scope 是什么、token 存在哪、数据落在哪个区域。
六、30 分钟实测：三个任务就够了
看代码只能判断"作者是否认真"，判断"能不能用"必须跑起来。
准备一个测试账号 + 只读凭据，在隔离环境里做三件事：
| 任务 | 目的 |
|---|---|
| 一个正常任务 | 确认主路径可用，记录延迟与 token 消耗 |
| 一个边界任务（空结果、超长文本、特殊字符） | 看它是否优雅失败 |
| 一个故意越权的任务（写操作、越界查询） | 确认它真的会拒绝 |
记录四个数：成功率、P95 延迟、单次调用的 token 成本、错误信息是否可读。再补一条：回滚要多久——改配置、重启客户端、恢复凭据，整套流程跑一遍。
一个完整的例子：6 个候选，最后只留 1 个
目标：让 agent 以只读方式查询 analytics 库，回答"上周新增用户按渠道分布"。
| 候选 | 初筛 | 30 分钟实测 | 结论 |
|---|---|---|---|
| A（4.2k star） | 最近提交在 14 个月前 | 未测试 | 淘汰：已停更 |
| B（12k star） | README 要求用超级用户连接 | 未测试 | 淘汰：权限过大，无法最小化 |
| C（600 star） | 有 release、MIT；工具描述只写 Execute SQL |
能执行 DELETE，没有拦截 |
淘汰：无法保证只读 |
| D（90 star） | 活跃、显式只读、强制 LIMIT | 正常任务通过；空结果返回清晰错误；越权写入被拒 | 入选 |
| E（30 star） | 3 个工具、有 CI，但无分页 | 大结果集被静默截断，没有提示 | 备选：可接受，但需在提示里说明 |
最后选 D——它 star 不到 100，但在"权限边界"和"错误处理"两项上都通过了实测。这正好印证了前面的结论：star 是曝光度，不是可用性。
七、十条红旗
看到任何一条，先停下来：
- README 里没有可复制的安装命令；
- 没有 LICENSE，或 license 字段是 NOASSERTION；
- 要求"管理员权限 / 全库读写"但没有说明为什么；
- 安装脚本里
curl | bash，或依赖postinstall下载二进制； - 工具描述含糊，参数全是自由字符串；
- 删除、转账、发消息这类操作没有
destructiveHint； - 一年没有提交，issue 区无人回复；
- 把 API key 写进 URL 或日志；
- 返回内容直接拼进系统提示，没有隔离；
- 没有版本号，只能跟随
main分支。
八、按场景的选型偏好
| 场景 | 优先看什么 | 常见坑 |
|---|---|---|
| 数据库 | 只读账号、SQL 白名单、行数上限、分页 | 直连主库、无 LIMIT、把整个 schema 塞进上下文 |
| 浏览器自动化 | 沙箱、域名白名单、截图/下载的体积控制 | 复用登录态、可访问内网、无限滚动 |
| 搜索 / 抓取 | 结果截断、引用来源、速率限制 | 返回整页 HTML、无超时、被反爬封禁 |
| 代码仓库 | 只读 token、限定仓库、diff 而非全量 | 授予 repo 全权限、把整个仓库读进上下文 |
| 办公协作 | OAuth scope、最小可见范围、审计 | 一个 token 打通全部文档、无法撤销 |
九、自建还是采用
优先采用，除非满足以下任意一条：
- 目标系统是内部系统，没有现成 server；
- 权限模型特殊（行级、字段级），现成实现做不到最小权限；
- 只需要 2–3 个工具，引入一个大而全的 server 反而增加攻击面；
- 需要审计、限流、灰度这些生产特性，而开源实现没有。
自建的成本不在协议——MCP SDK 已经把传输和握手封装得很好——而在测试、错误处理、权限和长期维护。一个 200 行的 server，通常需要 400 行的测试和文档才敢上线。
折中方案是 fork + 最小改动：保留上游的工具定义，只改权限和出口限制，并把改动控制在可 rebase 的范围内。
十、团队落地：从"能用"到"敢用"
个人选型靠判断，团队落地靠制度。四件事最有效：
- allowlist：只允许经过审查的 server 进入共享配置；
- 版本锁定：固定到具体版本，升级走变更流程；
- 审计日志：记录谁、在什么会话里、调用了哪个工具、参数是什么；
- 责任人：每个 server 有一个 owner，负责升级、响应安全事件、决定下线。
十一、五个常见误区
- star 多 = 好用？ 不。star 受曝光驱动，62.8% 的 server 不足 100 星，中位数 64。
- 工具越多越强？ 不。工具定义占上下文，选择成本随数量上升。
- 官方的一定安全？ 不。官方仓库也可能没有许可证、没有测试、权限过大。
- 远程一定比本地省事？ 不。远程省了部署，但多出鉴权、数据驻留和可用性依赖。
- 装完就不用管？ 不。20.4% 的 server 已经沉睡 1–2 年，升级和替换是常态。
结语：一条最小可执行流程
如果只记一件事，记这个顺序：
- 五分钟看仓库：最近提交、release、license、安装命令；
- 十分钟读工具定义：数量、描述、schema、破坏性注解；
- 三十分钟用只读权限实测三个任务；
- 通过之后，再谈接入生产。
MCP 生态还在快速变化，今天的最佳选择半年后可能已经停更。所以比"选对某一个"更重要的，是建立一套可以重复使用的判断流程——这样下一次你只需要花四十五分钟。
*本文数据来自 MCPMarkets 对 5,945 个 MCP server 的公开数据分析，完整方法和局限见 2026 年 10 月生态报告。浏览全部条目：MCP 服务器目录；按场景筛选：开发者工具。