2024 年 11 月，Anthropic 发布 Model Context Protocol（MCP）。在此之前，每个 AI 应用连接数据库、文件系统、GitHub 或内部服务，通常都要编写一套专用适配。模型换了、客户端换了，集成很可能重新来一遍。
MCP 想解决的是一个经典的平台问题：当模型和工具两端都快速增长时，需要一个共同协议把 N×M 的连接成本降下来。
MCP 标准化了什么
可以把 MCP 理解为 AI 应用与外部能力之间的接口层。服务器可以暴露资源、工具和提示模板，客户端负责发现并调用它们，协议约定消息与能力如何描述。
资源更像可读取的上下文，例如文件或数据库记录；工具代表可能产生动作的函数，例如创建工单或执行查询；提示模板则为常用交互提供结构。统一描述后，支持 MCP 的客户端有机会复用同一个服务，而不必为每个模型 SDK 单独开发。
它类似语言服务器协议给编辑器生态带来的变化：过去每种编辑器都要适配每种语言，统一协议后，两端可以相对独立演进。
协议并不会自动带来安全
“模型能调用工具”听起来很强，也意味着自然语言可能触发真实副作用。读取文件和删除文件不是同一风险级别，查询订单与退款也不应该共享权限。
一个可靠的 MCP 服务需要最小权限、清楚的参数校验和审计记录。客户端应区分只读与写入操作，对外部发送、删除、付费等高影响动作要求用户确认。工具返回的内容也属于不可信输入，不能因为来自某个服务器就允许它改变系统规则。
协议解决互操作，不替应用决定信任。HTTP 很通用，但我们仍需要认证、授权和业务校验；MCP 也是一样。
为什么工具描述本身很重要
模型选择工具主要依赖名称、说明和参数结构。描述含糊时，它可能选错工具或填写错误参数。设计 MCP 工具与设计公共 API 类似：动作要单一，命名要明确，输入尽量结构化，错误要可理解。
不要提供一个万能的 execute，让模型把任意字符串交给后端。更安全的方式是把能力收窄成 get_order、create_draft 这类可审计操作，并让服务端再次验证权限和状态。
工具越原子，模型越容易组合；边界越清晰，人越容易判断下一步会发生什么。
我的理解：AI 原生应用也需要“驱动层”
早期 AI 应用把大量价值押在 Prompt 上，后来很快发现，模型要完成真实任务，必须接触不断变化的数据和确定性工具。MCP 的出现说明行业正在从聊天演示走向系统集成。
我认为它最有价值的地方不是某种具体传输格式，而是明确了模型不应该把所有信息背在参数里。知识可以通过资源提供，动作由工具执行，模型负责理解意图和编排。这样的分工更容易替换模型，也更容易控制风险。
统一插座不会让所有电器自动安全，却能让生态围绕一致边界积累能力。MCP 是否长期成功，要看实现能否保持简单、权限模型能否跟上，以及服务端是否真正做到可发现、可组合、可审计。
参考资料
本文是 2026 年整理断更期时写下的回顾，发布日期按事件所处阶段归档。