版本号就是日期
MCP 的规范不按 1.0、2.0 走，而是按发布日期命名。仓库里当前的 schema 目录是 schema/2026-07-28/，也就是说这一版规范定稿于 2026 年 7 月 28 日。协议本身是 JSON-RPC 2.0，传输层主要是 stdio 和 Streamable HTTP 两种。
项目仓库 9,513 star，最近一次提交就在昨天。这个数字放在 AI 圈不算亮眼，但它是少数「被多家客户端同时实现」的协议，价值不在 star 上。
一年之后，真正落地的是什么
回头看，协议里最成功的部分是工具（tools）：模型发现一组能力、按 schema 调用、拿到结构化结果。这条链路简单到几乎不需要解释，所以接得最快。
资源（resources）和提示（prompts）的采用率明显低一些。原因不复杂：大多数应用并不缺「把文件暴露给模型」的机制，缺的是可靠的工具调用与错误处理。
授权（基于 OAuth 2.1 的资源服务器模型）则是另一回事——个人玩用不上，一旦进入企业、要访问别人的 SaaS，它就是绕不开的门槛。
工程上最容易忽略的三件事
- 工具描述就是提示词。名字、描述、参数说明写得好不好，直接决定模型选不选得对。见过太多「工具名是 do_stuff、描述是空的」的服务器，然后怪模型笨。
- 错误要可恢复。返回一句「failed」等于让模型瞎猜；返回「参数 X 超范围，应在 1–100」它才有机会自我修正。
- 幂等和超时。模型重试是常态。写操作没有幂等键，就会出现重复下单、重复发信。
别把 MCP 当成内部 RPC
它设计的核心是「能力协商」：客户端连上来，问服务器会什么，服务器回答，双方再决定怎么用。采样（sampling）、根目录（roots）这些机制，也都是围绕「模型与宿主如何分工」展开的。
如果你的两个微服务只是要互相调用，用 gRPC 或 HTTP 更直接。MCP 的复杂度是为「不确定的调用方、动态的能力集」付的费，没有这个前提，它就是负担。
我的判断
MCP 这一年证明的不是「协议能统一 AI 工具」，而是「统一的工具描述格式确实降低了集成成本」。真正难的部分——权限、审计、幂等、失败恢复——协议只能给你位置，填不填得好看实现者。
下一步值得观察的不是规范又加了什么字段，而是有多少服务器愿意把「错误语义」和「权限边界」写进实现里。那才是生态成熟的标志。
暂无评论内容