MCP 协议发布

用客户端—服务器协议复用工具、资源与提示

Anthropic 发布 Model Context Protocol,定义 AI 应用发现和调用外部工具、资源及提示模板的客户端—服务器接口。

时间2024 年 11 月 25 日 级别B · 领域级 组织Anthropic 状态已核验 · 2 个来源
多个几何形状组成的一组系统,通过一条连线连接到外部节点
Anthropic 为 Model Context Protocol 发布文章制作的官方连接主题插图。 Anthropic

到 2024 年,模型已经会用结构化参数请求一个函数。真正让开发者疲惫的,是函数之外的接线工作:同一个数据库要为桌面助手写一种插件,为编辑器写另一种,再为新的 Agent 框架写第三种。工具没有变,发现方式、连接方式和权限界面却跟着宿主反复重做。

11 月 25 日,Anthropic 发布 Model Context Protocol。MCP 用 JSON-RPC 建立客户端—服务器接口,并把角色分开:Server 暴露工具、只读资源或提示模板;Client 负责连接与能力协商;Host 掌握模型交互和用户权限。这个拆分的目标很具体——让提供能力的一方不必为每一个 AI 应用重新发明插件格式。它与模型的一次工具调用并不相同。tool_use 或函数调用描述的是模型在会话里如何说“我要调用这个工具,并使用这些参数”;MCP 处理的是宿主怎样发现工具、建立连接并交换能力信息。前者像一句符合语法的请求,后者更像把电话线和插座做成兼容规格。只有语法,没有连接,调用到不了工具;只有连接,没有模型的调用格式,应用仍要自己翻译意图。

协议也没有把信任问题一起标准化。一个 Server 可以声明能力,不代表它值得信任;一个 Host 能够连接,不代表应该默认授予写权限。恶意服务器、过度授权和提示注入仍需宿主通过权限提示、隔离、审计与停止机制处理。MCP 让接入更容易,也可能让攻击面扩展得更快,因此“Host 保留控制”不是实现细节,而是安全边界。

发布时的预制服务器和早期参与者说明有人愿意尝试,不足以证明标准已经胜出。真正的协议地位要由独立实现、兼容性和长期演进共同形成。规范增加能力时是否破坏旧客户端,不同宿主是否对权限做出一致而可理解的呈现,都比发布名单更能决定生态会不会分叉。

MCP 的价值正在于它没有必要宣称解决一切。它先把重复接线的问题画出共同接口,让工具提供者和宿主可以围绕同一张图讨论。插头统一以后,墙后接的是什么、开关由谁掌握,反而必须看得更清楚。

By 2024, models could already request functions with structured arguments. The tiring work lived outside the function. The same database might need one plugin for a desktop assistant, another for an editor, and a third for a new agent framework. The underlying tool had not changed, but discovery, connection, and permission interfaces were rebuilt around every host.

On 25 November, Anthropic released the Model Context Protocol. MCP used JSON-RPC to establish a client-server interface and divided the roles. A Server exposed tools, read-only resources, or prompt templates. A Client managed a connection and negotiated capabilities. A Host retained control over model interaction and user permission. The division pursued a practical goal: a capability provider should not have to invent a new plugin format for every AI application. This was not the same thing as a model making one tool call. A tool_use block or function call describes how the model says, inside a conversation, “I want this tool with these arguments.” MCP addresses how a host discovers a tool, connects to it, and exchanges capability information. One resembles a grammatical request; the other standardizes the socket and line carrying it. Grammar without connection cannot reach the tool. Connection without a model-call format still leaves the application translating intent.

The protocol did not standardize trust along with transport. A Server could declare a capability without deserving trust. A Host could connect without granting write access by default. Malicious servers, excessive authorization, and prompt injection still required permission prompts, isolation, audit, and stop mechanisms at the host boundary. MCP made integration easier and could make an attack surface grow faster, which is why host control was not an implementation footnote but a security boundary.

Prefabricated servers and early participants at release showed willingness to experiment, not that the standard had already won. Protocol standing emerges from independent implementations, compatibility, and long-term evolution. Whether new capabilities break old clients, and whether different hosts present permissions consistently and intelligibly, matters more to ecosystem cohesion than a launch list.

MCP's value did not depend on claiming to solve everything. It first drew a common interface around repetitive wiring so tool providers and hosts could argue over the same diagram. Once the plug becomes standard, what sits behind the wall—and who controls the switch—has to become more visible, not less.

展开完整事件档案人物、主题、模型与产品
人物
模型
产品
来源

原始资料

  1. 01Model Context Protocol specificationMCP · official
  2. 02Introducing the Model Context ProtocolAnthropic · official

试试搜索