MCP Server Cards：让别人不连你就知道你能干什么
数据截至 2026-07，价格与限额以各官网为准。
MCP Server Cards 要解决的问题只有一句话：今天想知道一个 MCP server 到底提供了哪些工具，你必须先把它连起来、握一次手、调一次列表接口；Server Cards 的思路是把这份能力清单挪到一个 .well-known 风格的 URL 上，让注册表、爬虫、客户端在不建立连接的前提下就能读到——这看起来只是个小改动，但它直接决定了 MCP 生态能不能被”搜索”，而不只是被”逐个试用”。
一个常见的误解是：既然已经有官方注册表了，能力发现这事不就解决了吗？确实，registry.modelcontextprotocol.io 已经在做 server 的发现、文档与 API 参考，由 modelcontextprotocol 这个 GitHub 组织维护、社区驱动。但注册表本身也面临同一个困境——它收录一个 server 时，那份”这个 server 有哪些工具、需要什么权限”的描述从哪来？靠人工填表就会过期，靠实际连接去抓就要求注册表有能力去连每一个 server（很多还是要鉴权的）。Server Cards 是给这条链路补一个标准出口：由 server 自己在一个约定位置发布元数据，谁需要谁去读。
先说清楚它到底解决什么问题
把场景换成人话。你现在要给团队选一个操作数据库的 MCP server，市面上有若干候选。要判断哪个合适，你得关心这几件事：它暴露了哪些 tool、参数长什么样、要不要 OAuth、支持哪个协议版本、是不是只读。
今天获得这些信息的路径大致是三条，都不太舒服：
- 读文档。快，但文档和代码脱节是常态，写文档的那天有 8 个工具，现在可能有 12 个。
- 实际连一次。准，但成本高：要装依赖、要配环境变量、要过鉴权，光为了”看一眼”就得走完整个接入流程。想批量比较十个 server，这条路基本不可行。
- 看别人的评测。省事，但二手、滞后，而且往往只覆盖最热门的那几个。
Server Cards 想补的就是中间这一层：一份由 server 自己维护、机器可读、不需要建立 MCP 会话就能拿到的能力描述。类比一下，它之于 MCP，有点像 robots.txt 或 openapi.json 之于普通 Web 服务——不是给人读的营销页，是给程序读的自述文件。
需要说明的是，这项工作在官方是列在路线图里的能力标准，具体的字段定义、文件名、路径约定，以官方规范文档当前版本为准。这篇不替它编造字段表——凡是你在别处看到的具体 JSON 结构，都值得回官方仓库对一遍再用。
它和官方注册表是什么关系
不少人第一反应是”这两个是不是重复了”。更准确的理解是分工：
- Server Card 是数据源：住在 server 自己的域名下，跟着 server 一起部署、一起更新，天然不会落后于实现。
- 注册表是索引层：
registry.modelcontextprotocol.io负责聚合、检索、展示，还提供 API 参考。
这是典型的”自述 + 索引”结构。有了标准化的自述文件，注册表可以定期去拉、去校验；不进注册表的私有 server 也能被自家平台的内部目录扫到。反过来说，如果没有这一层，注册表就只能靠提交者手填，生态一大就必然失真。
对于企业内部场景，这个分工尤其有用。很多团队会在内网跑十几个自研 MCP server，它们不会、也不应该进公开注册表，但同样需要一个”团队内部的 server 目录”。Server Cards 让这件事不用自己发明格式——扫描内网域名的约定路径就行。
为什么是现在：2026-07-28 那次改动腾出了位置
2026-07-28 发布的新版规范，官方称是自协议发布以来最大的一次修订，兑现了 2026 路线图，此前已经发过 release candidate。这次改动包含六块：无状态协议内核、Extensions 框架、Tasks、MCP Apps、授权加固，以及一套正式的弃用策略。
其中和”能力发现”关系最直接的是无状态化。MCP 现在在协议层是无状态的，由 6 个 SEP（Specification Enhancement Proposal，规范增强提案）共同实现，完成了此前 “The Future of MCP Transports” 里的计划。实际影响很具体：以前需要粘性会话、共享 session 存储、网关做深度包检测才能跑的远程 server，现在可以直接放在普通的轮询负载均衡后面，按 Mcp-Method 头路由；协议层不再要求会话追踪。
这里要小心一个容易传歪的说法：无状态指的是协议层不再要求会话追踪，不是”MCP 不能有状态了”。你的业务当然可以有状态，那是应用层自己的事。
无状态化和 Server Cards 是配套的。当一个 server 可以被水平扩展、放在任意负载均衡后面、任何一个实例都能独立应答时，“这个部署提供什么能力”就变成了一份可以静态托管的元数据，而不是必须通过一次带状态的握手才能问出来的东西。同一次改动里还有另外两条值得留意：Tasks 这个用于长时间运行操作的特性已经从核心协议移到 extension，用户可以自建 extension，与官方认可的 extension 并存；授权侧另有 6 个 SEP，让授权规范更贴近真实的 OAuth 2.0 / OpenID Connect 部署，其中包括要求客户端按 RFC 9207 校验 iss 参数（SEP-2468）。
这两条意味着，未来”一个 server 能干什么”不再只是工具列表，还包括它启用了哪些 extension、走的是哪套授权。这些恰恰是最适合写进一份元数据文件、而不是靠文档口头描述的东西。
破坏性变更是真的，别当成小版本升级
这次修订不是平滑演进。维护者 David Soria Parra 称这是自加入授权以来最实质的变更，原话是 “A lot of things that made MCP are gone.”（很多曾经定义 MCP 的东西没有了。）具体到工程影响：2026-07-28 版本的 server 可能无法与旧 client 协同，反之亦然；官方为此配了正式的弃用机制，给旧版本 12 个月窗口。
12 个月听着宽裕，但对同时维护 server 和一堆客户端接入的团队来说，真正的成本是版本矩阵——你的 server 升到新规范，接你的那些客户端未必同步升。所以在这个阶段，“我这个 server 说的是哪个版本的协议”本身就是一条必须对外声明的关键信息。这也是 Server Cards 这类元数据在当下比一年前更有价值的原因：版本协商如果只能靠连接时握手才知道，兼容性排查就只能靠一个个试。
Server 作者现在能做的三件事
规范细节还在推进，但有几件事不依赖最终字段定义，现在做就不会白做。
第一，先把能力清单变成代码里的单一事实来源。 很多 server 的工具描述散在三个地方：README、注册表提交表单、代码里的 tool 定义。把后两者对齐——让 README 从代码生成，而不是手写——将来无论 Server Card 的字段怎么定，你只需要多加一个导出格式。反过来，如果现在三处不一致，将来生成出来的卡片也是错的，只是错得更自动化。
第二，明确声明你的协议版本与授权方式。 哪怕暂时只是写在 README 顶部：支持哪个规范版本、是否需要 OAuth、是否有只读模式。这三条是别人决定”要不要试你”的最短路径信息，也几乎肯定会出现在最终的卡片字段里。
第三，把 server 的部署形态往无状态方向理。 如果你的远程 server 现在还依赖粘性会话或者进程内的会话字典，趁这次协议层放开的机会重构掉。这件事的收益不止于对齐规范：能横向扩容、能放普通负载均衡后面，本身就是运维上的减负。
对客户端和平台侧，思路是对称的：不要把”发现能力”和”建立连接”绑死在一起写。把”读取某个 server 的元数据”抽成独立的一步，将来接上标准卡片就是换一个数据源，而不是重写整个接入流程。
诚实说说局限
有几点必须讲清楚，免得期待错位。
自述文件不等于可信。 server 自己发布的元数据，说自己有什么就是什么，没有第三方校验。恶意或者单纯写错的卡片同样会被抓走。所以卡片能回答”它声称能做什么”，回答不了”它是否安全、是否真的这么做”。真要接进生产，权限审查、最小授权、沙箱这些功课一样不能省——可以先读 MCP 是什么？为什么说它是 AI 的 USB 接口 建立基本概念，再看 Claude Code / Cursor 通用 MCP 配置教程 里关于环境变量和权限的部分。
元数据会过期。 卡片跟着部署走，理论上比文档新，但如果作者忘了在 CI 里更新它，一样会漂。判断新鲜度的办法只能是看它是不是从代码自动生成的。
它不解决质量评估。 知道一个 server 有 12 个工具，不代表这 12 个工具好用。工具描述写得含糊、参数设计反直觉、错误信息没法排查——这些只有真正连上去用才知道。挑选阶段可以参考 MCP 服务器推荐与安装指南 这类实际用过的清单，连不上时的排查思路见 Claude Code 的 MCP 连不上、配置不生效怎么排查。
中文资料几乎没有。 这套东西时效性极强，规范文档、SEP、发布公告都在英文一手渠道，而且还在变动中。凡是具体的路径、字段、版本号，一律以官方博客与规范文档当前版本为准，别信任何二手转述里的精确结构——包括这篇。
顺带说一句生态背景，帮你判断这件事值不值得跟。2025 年 12 月，Anthropic 把 MCP 捐给了 Linux 基金会下的 Agentic AI Foundation，成为厂商中立、社区治理的标准；OpenAI、Google、Microsoft、AWS 都已经把它接进了自家 agent 栈。按官方与行业公开资料的口径，目前有超过 10,000 个公开 MCP server 在生产中运行，SDK 月下载量超过 9,700 万——这两个数字是公开资料汇总，不是精确统计，看量级即可。规模到这个程度，“不连上就能知道你能干什么”就从锦上添花变成了刚需，因为已经没人有精力逐个连着试了。
小结
Server Cards 的价值不在技术复杂度，而在于它把 MCP 生态从”逐个试用”推向”可被检索”。它和官方注册表是数据源与索引层的分工，不是替代关系。它之所以在这个时间点变得必要，是因为 2026-07-28 的规范修订把协议层做成了无状态、把 Tasks 挪进了 extension、还带来了会影响新旧互通的破坏性变更，能力与版本声明的重要性随之上升。作为 server 作者，现在最该做的不是等字段定稿，而是让能力清单从代码生成、把协议版本和授权方式讲明白、把部署理成无状态。最后记住卡片的边界：它是自述，不是背书，安全与质量的判断还得自己做。