MCP 是什么？它和 Function Calling 是什么关系、解决了 FC 的什么问题？

它俩不在一层，不是替代关系。

• Function Calling 是模型侧的表达方式：模型输出"我要调 X 工具、参数是 Y"这样一段结构化意图，执行永远在你的代码里（见 Q3-03）。
• MCP（Model Context Protocol）是工具侧的接入协议：规定一个工具服务怎么把自己的能力暴露出来、怎么被发现、怎么鉴权、怎么传输。

两者是串联的：MCP Server 提供的工具，客户端拿到后仍然要转成模型的 tools schema 发给模型，模型仍然用 FC 的方式返回调用意图。接了 MCP，模型侧一个字都没变。

MCP 解决的是集成爆炸：M 个应用 × N 个工具原本要写 M×N 套对接，有了统一协议变成 M+N。附带好处是工具可以在运行时被发现、鉴权和传输方式统一、社区生态可复用。

补三层。

1. 三段式看 MCP。

• 解决什么：集成的组合爆炸、工具的运行时发现、鉴权与传输的统一、生态复用（别人写好的 server 直接接）。
• 代价是什么：多一跳网络延迟；工具清单不完全受你控制（对方一更新，你的上下文和选择准确率就变）；供应链与安全面扩大（第三方 server 的描述本身就是进入你上下文的文本，见 Q3-10）；调试链路变长（出问题要分清是模型选错、client 转换错、还是 server 返回错）；版本与兼容负担。
• 什么时候不该用：只有自家几个内部工具且不打算对外开放时，直接写 FC 工具更简单也更快；对延迟极敏感的链路；强审计场景下需要工具集完全冻结的系统——那种情况即使用 MCP 也要在网关侧固化白名单。

2. 2026-07-28 规范的改版要讲到，这是分水岭。 截至 2026-08，MCP 最重要的变化是协议核心转向无状态：取消了 initialize 握手和会话 id（Mcp-Session-Id）。工程影响很直接——不再需要粘性会话，服务可以水平扩容、可以跑在 Serverless 上、断线重连不用恢复会话状态。配套的几项：

• **MRTR（多轮往返）**用来处理原本要靠会话承载的多步交互；
• 新增 Mcp-Method / Mcp-Name 请求头做头部路由，网关不用解包 body 就能路由、限流、鉴权；
• list 类结果带上 ttlMs / cacheScope，工具清单可以被客户端缓存并按需刷新；
• 动态客户端注册（DCR）弃用，转向 CIMD；
• Roots / Sampling / Logging 与 HTTP+SSE 传输进入 12 个月弃用窗口；
• Tasks、MCP Apps、企业级授权等从核心规范挪到扩展（extensions）。

最需要记住的一条：协议无状态之后，业务状态的新范式是工具返回显式 handle——状态不再挂在协议会话上，而是由工具返回一个句柄，后续调用凭句柄继续。这和长结果处理的做法正好统一（见 Q3-05）。

3. 和 Skills、A2A 的分工，一句话各自归位。 MCP 是手（能力接入）；Agent Skills 是操作手册（怎么把事做对，四级渐进式披露：约 100 token 的广告 → 加载 5000 token 以内的 SKILL.md → 读 references → 跑 scripts）；A2A 是对外协作协议（Agent 之间互相委托任务，见 Q3-11）。三者不冲突，一个生产系统里可能同时存在。