MCP server 怎么挑：三条判断标准
数据截至 2026-07，规范与各项目能力以官方文档当前版本为准。
挑 MCP server 时，“这个工具听起来有用”是最没有参考价值的一条依据。真正决定它会不会在你手上出事的，是三件跟功能无关的事：来源查不查得到、它跟你的客户端说不说同一版协议、它的部署和授权形态经不经得起你的用法。功能对不对味，是把这三关过完之后才轮到考虑的。
常见的误解是把选 MCP server 当成挑浏览器插件——看个介绍、看个 star 数、装上试试，不行就卸。这个心智在协议早期基本够用，但现在不太成立了。一方面公开可用的 server 数量按官方与行业公开资料口径已经超过一万个，靠人工”眼缘”筛不动；另一方面 2026-07-28 发布的新规范被官方称为协议发布以来最大的一次修订，新旧版本之间可能直接互不相通，装上跑不起来的原因往往不在 server 本身，而在你没看它站在哪一版。下面三条标准，按我建议的检查顺序排。
标准一：来源能不能查证，而不是”看起来很正规”
第一关最简单，也最容易被跳过：这个 server 是谁发布的，你能不能在一个中立的地方查到它。
MCP 现在有官方注册表 registry.modelcontextprotocol.io，提供 server 的发现、文档与 API 参考，由 modelcontextprotocol 这个 GitHub 组织维护，社区驱动。它的价值不在于”上榜就是好的”——注册表本身不做质量背书——而在于给你一个统一的核对入口：这个 server 的标识、发布方、文档链接是不是对得上，而不是靠某篇教程里贴的一行安装命令。
与之配套的还有路线图上的 MCP Server Cards，思路是通过 .well-known URL 暴露 server 的元数据，让注册表和爬虫不必真的连上去握手，就能知道它宣称有哪些能力。对使用者的实际意义是：以后判断一个 server 能干什么，不必先把它接进自己的客户端跑一遍。这条能力的落地程度和字段细节以官方文档当前版本为准，别按某篇旧文章里的描述去实现。
具体到动作上，我的做法是：
- 先在官方注册表里搜一遍，搜不到不等于不能用，但要在心里降一档，并且必须找到它的公开仓库。
- 看仓库有没有把源码、发布记录、issue 都摊开。只给一个安装命令、代码不公开的，装进能读你本地文件或调你线上接口的客户端里，风险自己掂量。
- 看它有没有明确写自己实现到哪一版协议。写了的，进第二关；一个字没提的，基本可以判定作者没跟这轮变更，第二关也过不去。
想细看注册表怎么用，可以配合读 官方 MCP Registry 怎么用 和 MCP Server Cards。
标准二：协议版本站在哪一边
这是当下权重最高的一条，也是很多人栽跟头的地方。
2026-07-28 发布的新规范一次动了六块内容：协议内核改成无状态、新增 Extensions 框架、Tasks、MCP Apps、授权加固，以及一套正式的弃用策略。其中 MCP Apps 这块，官方博客没有展开细节，具体形态以官方规范文档当前版本为准，这里不替它编内容。
改动的实际后果说得很直白：2026-07-28 版本的 server 可能无法与旧 client 协同，反之亦然。维护者 David Soria Parra 称这是自加入授权以来最实质的变更，原话是 “A lot of things that made MCP are gone.”。官方同时给了缓冲——弃用机制为旧版本留出 12 个月窗口。
对选型的含义是三句话：
- 你手上的客户端实现到哪一版，是先决条件。客户端没跟上，你挑再新的 server 也接不上。
- 一个长期不更新的 server，在这轮变更里从”功能少一点”变成了”可能根本连不上”，性质不一样了。
- 12 个月窗口是排期用的，不是拖延用的。选型时优先挑那些已经公开说明升级计划的项目，而不是等到窗口末尾集中踩坑。
顺带说一句 Tasks。用于长时间运行操作的 Tasks 已经从核心协议移到了 extension，用户也可以自建 extension，与官方认可的 extension 并存。所以如果你要的 server 涉及长任务，光看它支持不支持还不够，得确认你的客户端认不认它用的那个 extension。展开可看 Tasks 被移出核心协议 和 新旧 MCP 版本不兼容怎么办。
标准三：部署与授权形态撑不撑得住你的用法
前两关过了，第三关看的是它会不会在你的真实环境里出问题。这一关分本地和远程两种情况，差别很大。
本地跑的 server（进程起在你自己机器上）压力小得多，主要关注它要哪些权限：能不能读整个文件系统、能不能发外网请求、密钥怎么传。原则是按最小权限给，别图省事把家目录整个挂进去。
远程 server 的变化才是这轮的重点。协议层现在是无状态的，由 6 个 SEP 共同实现，兑现了 “The Future of MCP Transports” 里的计划。落到部署上：以前需要粘性会话、共享 session 存储、网关做深度包检测才能扛住的远程 server，现在可以直接跑在普通的轮询负载均衡后面，按 Mcp-Method 头路由。协议层不再要求会话追踪。
这里有个容易读歪的地方要说清楚：无状态说的是协议层不再要求会话追踪，不是”MCP 不能有状态”。应用层自己的状态是另一回事，该存还是得存。选型时问的问题是：这个远程 server 的部署说明还在要求粘性会话吗？如果是，它大概率还停在旧版实现上，回到标准二。
授权同样被加固了，同样是 6 个 SEP，方向是让授权规范更贴近真实的 OAuth 2.0 / OpenID Connect 部署，其中包括要求客户端按 RFC 9207 校验 iss 参数（SEP-2468）。这条主要约束客户端实现，但对使用者有个直接推论：接需要授权的远程 server 时，客户端和 server 两边都得跟上新规范，缺一边就可能卡在鉴权环节。细节见 MCP 授权加固：客户端为什么必须校验 iss。
这三条管不到的地方
得诚实说清楚局限，免得把这三条当成万能筛子。
它们全是”能不能安全接进来”的判断，不解决”值不值得接”。一个来源清白、版本最新、部署规范的 server，完全可能对你的活儿毫无用处。功能匹配度、返回内容的质量、工具描述写得清不清楚（直接影响模型会不会正确调用），这些只能靠实际试。
第二个管不到的是成本。每接一个 server，它的工具定义都要占上下文，装得越多，每轮对话的固定开销越大，响应也越慢。这跟安全性无关，纯粹是量的问题，取舍思路可参考 开发者必装的几个 MCP 推荐。
第三，生态本身还在动。MCP 于 2024-11 发布，到现在约一年零八个月；2025-12 由 Anthropic 捐给 Linux 基金会下的 Agentic AI Foundation，成为厂商中立、社区治理的标准，到现在约七个月。OpenAI、Google、Microsoft、AWS 这几家主流厂商都已把它接进自家 agent 栈。这个演进速度意味着任何一篇选型文章都有保质期，包括这一篇——判断框架可以沿用，具体条款请回官方文档核对当前版本。
最后提醒一句信源问题：网上仍有站点把更早的版本列为当前稳定版、把下一版发布时间写成过期的预告。看到这类描述直接跳过，以官方 blog 和规范文档为准。
小结
选 MCP server 的顺序是先查来源、再对版本、然后看部署与授权形态，最后才谈功能合不合用。三条里权重最高的是版本这一条，2026-07-28 的修订让新旧可能互不相通，官方留了 12 个月弃用窗口给你排期。无状态化让远程部署简单了不少，但读的时候别把它误解成应用层不能有状态。这三条都是准入判断，功能好不好用还得自己试，而且装得越多上下文开销越大，克制一点更划算。整套结论请以官方 blog 与规范文档的当前版本为准。