减少“应用×服务”的重复接入
MCP 全称为 Model Context Protocol，即模型上下文协议，用于规定 AI 应用与外部工具、数据之间的通信方式。素材给出的例子是：3 个 AI 应用要接入 GitHub、数据库、Notion 三项服务，如果逐个适配，需要写 9 套代码；引入 MCP 后，服务方提供 MCP Server，应用方实现 MCP Client，3 个应用加 3 个服务只需要 6 份实现。
规范将 MCP 类比为 LSP：LSP 让语言插件能在 VS Code、Vim、JetBrains 中通用，MCP 则希望工具服务能在不同 AI 应用中通用。该协议最早由 Anthropic 在 2024 年 11 月开源，目前由 Linux 基金会下的 Agentic AI Foundation 托管。
Host、Client、Server 的边界更清晰
新版规范中，三个角色的分工更加明确：
- Host：面向用户的应用环境，负责权限确认、上下文拼装，并决定工具是否执行。
- Client：位于 Host 内部，负责按 MCP 协议与 Server 通信。
- Server：提供 Tools、Resources 和提示模板等能力。
模型本身不会直接连接 MCP Server。它只在回复中提出“要调用某个工具、参数是什么”，真正发请求的是 Host 里的 Client。因此，调用前是否弹出确认框，由 Host 控制。规范的安全章节也写明，Host 在调用任何工具前应该取得用户明确同意。
反向能力方面，新版核心保留 Elicitation：Server 执行到一半时，可以请 Host 向用户索要补充信息。旧版中的 Roots、Sampling、Logging 被标记为弃用。按照官方政策，弃用功能至少还能使用 12 个月，但新实现不应继续依赖。
无状态化调用：从会话连接到显式句柄
2026-07-28 版规范的关键调整，是从有状态设计转向无状态设计。素材提到，新版移除了握手和会话机制。官方解释是，有状态设计在负载均衡、Kubernetes、多地域部署中较麻烦，同一会话请求必须落到同一台机器；无状态化后，Server 前面可以使用普通轮询负载均衡，便于横向扩容。
具体调用仍基于 JSON-RPC 2.0。Client 先通过 tools/list 获取工具列表，Server 返回工具名称、描述和参数 JSON Schema；Host 将这些定义放入模型上下文。模型根据描述和参数结构决定是否调用，随后 Client 通过 tools/call 发送请求，Server 执行后返回结果。新版还要求每个请求在 _meta 中携带协议版本、客户端信息和客户端能力。
对于购物车、打开中的浏览器等需要状态的场景，规范建议使用显式句柄：创建状态的工具返回一个 ID，例如 basket_id，模型后续调用时把它作为普通参数传回。授权部分也有更新：Client 需要校验授权服务器返回的 iss，即 RFC 9207，以防混淆攻击；动态客户端注册被弃用，改推 Client ID Metadata Documents。
对开发者意味着什么
对普通用户来说，这次升级的影响较小。Claude Code、Codex 的配置写法基本不变，远程服务使用 HTTP，本地服务使用 stdio。旧的 HTTP+SSE 传输被弃用，官方给出约一年过渡期。需要迁移的主要是 SDK 和 Server 作者，尤其是依赖会话 ID、Sampling 或旧传输方式的实现。官方称，TypeScript、Python、Go、C# 四个一级 SDK 在发布时已支持新版。
MCP 与 Function Calling 的关系也在这次梳理中变得更清楚：Function Calling 是模型层能力，MCP 是应用和工具之间的协议，两者不冲突。Host 从 MCP Server 获取工具列表，转换成模型可识别的工具定义；模型通过 Function Calling 表达调用意图，Host 再通过 MCP 完成实际请求。社区也在研究“Skills over MCP”，但相关工作组仍处于早期阶段。
从规范内容看，2026-07-28 版 MCP 的方向，是让 AI 应用接入外部工具的过程更接近标准服务调用，而不是依赖本地进程或长期连接。对 AI 编程生态来说，这会使远程工具部署、权限控制和团队协作更容易形成统一做法。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/mcp-xin-ban-gui-fan-luo-di-ai-bian-cheng-gong-ju-jie-ru-wai
