引言 — MCP 是什么,解决什么问题
Model Context Protocol(MCP),用官方文档的话说,是“用于将 AI 应用连接到外部系统的开源标准”。它统一了 Claude、ChatGPT 这类应用接入数据源(如本地文件、数据库)、工具(如搜索、计算器)、工作流(如特化的提示)的方式。文档把它比作“AI 应用的 USB-C 端口”——就像线缆规格被统一成一种,连接方式也被统一成一种。
为什么需要标准?这常被称为 M×N 问题。当有 M 个 AI 应用、想接入 N 个工具与数据源时,如果没有标准,就得手工编写 M×N 个各不相同的集成。一旦有了一个通用协议,这笔成本就降到 M+N——服务器只做一次,所有会说该协议的客户端都能用;客户端只要实现协议,就能接上所有服务器。用文档的话说,就是“一次构建,处处集成(build once, integrate everywhere)”。MCP 表示这个思路借鉴自 Language Server Protocol(LSP)。正如 LSP 把“编辑器 × 语言”的组合整理成一个标准,MCP 整理的是“AI 应用 × 工具”的组合。
MCP 由 Anthropic 于 2024 年 11 月公开并开源,最初连同 Python、TypeScript SDK 以及面向 Google Drive、Slack、GitHub、Git、Postgres、Puppeteer 的服务器一起发布。此后 OpenAI 和 Google DeepMind 也相继采用,使它事实上成为行业标准。
架构 — 主机、客户端、服务器,以及传输
MCP 是客户端-服务器结构,参与者被定义为三方:
- 主机(Host)。 协调、管理一个或多个 MCP 客户端的 AI 应用(例如 Claude Code、VS Code)。
- 客户端(Client)。 与单个服务器保持连接、并从中获取上下文的组件。
- 服务器(Server)。 向客户端提供上下文的程序。无论在本地运行还是远程运行,都是“服务器”。
核心规则是“一个服务器对应一个客户端”。主机为每个接入的服务器创建一个专用客户端,各自维持独立的连接。VS Code 同时接入文件系统服务器和 Sentry 服务器时,内部就会生成两个客户端对象。
协议分为两层。数据层(data layer)是基于 JSON-RPC 2.0 的交换协议,定义生命周期管理和原语(工具、资源、提示、通知);传输层(transport layer)处理实际的通信通道与认证。连接是有状态的(stateful),由客户端用 initialize 请求协商 protocolVersion 和彼此的能力(capabilities),准备就绪后再用 notifications/initialized 通知对方,连接由此开始。
传输有两种:
- stdio。 通过标准输入输出,让同一台机器上的进程之间直接通信——没有网络开销,适合本地服务器,通常只面对一个客户端。
- Streamable HTTP。 客户端→服务器走 HTTP POST,需要流式传输时再叠加 Server-Sent Events(SSE)。用于远程服务器,支持 Bearer 令牌、API 密钥和自定义请求头,文档推荐用 OAuth 获取令牌。
为了让同一条 JSON-RPC 消息在任何传输上都能原样通行,传输层把通信细节从协议中剥离开来。
三种原语 — 工具、资源、提示
原语是 MCP 中最重要的概念,而其核心就是服务器公开的这三种。它们的区别在于“由谁主导”:
- 工具(Tools)—— 模型主导。 AI 实际调用以执行动作的函数(写文件、调用 API、查询数据库)。输入用 JSON Schema 校验。发现用
tools/list,执行用tools/call。由于模型自行决定何时使用,因此执行前的用户批准等控制手段被着重强调。 - 资源(Resources)—— 应用主导。 只读的上下文数据(文件内容、数据库 schema、文档)。每个资源都有唯一的 URI 和 MIME 类型。既有固定 URI 的直接资源,也有接收参数的资源模板。方法有
resources/list、resources/templates/list、resources/read,订阅变更用resources/subscribe。 - 提示(Prompts)—— 用户主导。 可复用的模板,指导如何把工具与资源组合起来使用。像斜杠命令一样,由用户显式调用。方法有
prompts/list、prompts/get。
资源 URI 分为固定型(直接资源)和参数型(模板)两类(仅作说明):
file:///Users/me/notes.md # 直接资源 (固定 URI)
calendar://events/2026 # 直接资源
weather://forecast/{city}/{date} # 资源模板 (参数)
它遵循规整的模式:发现用 */list、获取用 */get、执行用 tools/call。列表是动态的,因此当服务器的工具发生变化时,可以用 notifications/tools/list_changed 之类的通知告知客户端。
反过来,也有客户端向服务器公开的原语:
- 采样。 服务器请求客户端的 LLM 生成补全的
sampling/createMessage——让服务器不必自带模型 SDK 也能使用模型。 - 征询。 服务器请求用户提供额外输入或确认的
elicitation/create。 - roots 与日志。 用 roots 告知服务器可处理的文件、URI 边界,以及用于调试的日志发送。
如何构建服务器
构建服务器的本质,是决定“把什么公开为工具、什么公开为资源、什么公开为提示”。动作归为工具,要读取的上下文归为资源,定型的工作流归为提示。官方 SDK 有 TypeScript、Python、C#、Go(Tier 1),Java、Rust(Tier 2),Swift、Ruby、PHP、Kotlin(Tier 3),它们都按各自语言的惯用法提供相同的功能。具体 API 因 SDK 而异,所以要查阅各语言的文档。
工具定义由名称、说明、输入 schema 组成。以下是官方文档中示例的形态(仅作说明):
{
"name": "searchFlights",
"description": "Search for available flights",
"inputSchema": {
"type": "object",
"properties": {
"origin": { "type": "string", "description": "Departure city" },
"destination": { "type": "string", "description": "Arrival city" }
},
"required": ["origin", "destination"]
}
}
客户端先用 tools/list 接收这些定义并注册到 LLM,当模型选中某个工具时,再用 tools/call 执行。实际来回传递的 JSON-RPC 是这样的形态(仅作说明):
{ "jsonrpc": "2.0", "id": 3, "method": "tools/call",
"params": { "name": "weather_current",
"arguments": { "location": "San Francisco", "units": "imperial" } } }
响应以 content 数组返回,可以容纳文本、图像、资源等多种格式。开发和调试时,官方的 MCP Inspector 和 参考服务器合集 是很好的起点。
取舍与成熟度 — 诚实的梳理
MCP 的吸引力很清晰。集成只需做一次,而且像 LSP 那样,整个生态共享同一套规格。不过也有需要冷静看待的地方。
- 安全并未内置于协议之中。 规范自身明确指出“工具即任意代码执行”,并强调不应相信不可信服务器给出的工具说明(annotation)。用户同意、工具执行批准、采样批准都是主机实现的职责——也就是说,安全不是由协议、而是由客户端来守护。
- 远程服务器的认证依然很重。 Streamable HTTP 与 OAuth 的组合很强大,但与本地 stdio 的简单相去甚远。
- 规范仍在变动。 版本基于日期(当前最新为
2025-11-25),Tasks 之类的功能还处于实验(Experimental)阶段。SDK 也分了层级,成熟度因语言而异。 - 治理正在迁移。 据报道,2025 年 12 月 MCP 被移交给 Linux Foundation 旗下的 Agentic AI Foundation——这是从一家公司的项目走向中立标准的信号。
结语
MCP 的核心不是炫目的新技术,而是“枯燥的标准化”,而价值恰恰就在这里。只要理解工具、资源、提示这三种原语,以及 JSON-RPC 这层薄薄的规格,任何客户端与任何服务器都能以同样的方式对接。如果你是想把智能体接入真实系统的工程师,那么在挑选框架之前,先把这一层协议理解透,往往能受用更久。