Model Context Protocol（MCP）：AI 应用连接工具的开放标准完整中文说明

官方信息

项目背景：什么是 MCP

Model Context Protocol（MCP）是一个用于把 AI 应用连接到外部系统的开源标准。通过 MCP，像 Claude、ChatGPT 这样的 AI 应用可以连接到数据源（例如本地文件、数据库）、工具（例如搜索引擎、计算器）和工作流（例如专门设计的提示词模板），从而让 AI 应用能够访问关键信息并替用户完成任务。

官方给出了一个非常形象的类比：MCP 之于 AI 应用，就像 USB-C 接口之于电子设备。USB-C 让不同厂家的充电器、显示器、硬盘可以用同一根线、同一个口相连；MCP 则让不同的 AI 应用和不同的工具服务器，用同一套协议相连，不再需要每个应用都为每个工具单独写一套对接代码。

这个仓库本身（modelcontextprotocol/modelcontextprotocol）是 MCP 的"核心仓库"，里面包含四样东西：MCP 规范（Specification）、MCP 协议模式（Schema）、以及官方 MCP 文档。协议模式先用 TypeScript 定义在 schema/2026-07-28/schema.ts，同时也提供等价的 JSON Schema 版本（schema/2026-07-28/schema.json），以方便各种语言的实现使用。官方文档站用 Mintlify 构建，发布在 modelcontextprotocol.io。MCP 只专注于"上下文如何交换"这件事，并不规定 AI 应用该怎么用 LLM、怎么管理收到的上下文，因此它可以和任何大模型、任何上层应用自由组合。

MCP 能做什么（What can MCP enable）

官方列举的典型场景包括：

• 智能体访问你的 Google 日历和 Notion，充当更个性化的 AI 助手；
• Claude Code 可以根据一张 Figma 设计图生成完整的 Web 应用；
• 企业聊天机器人可以连接组织内多个数据库，让用户用聊天的方式分析数据；
• AI 模型可以在 Blender 里创建 3D 设计，再用 3D 打印机打印出来。

为什么 MCP 重要（Why does MCP matter）

站在生态不同位置，MCP 的价值不同：

• 开发者：MCP 减少了构建 AI 应用或与 AI 应用集成时的开发时间和复杂度，不用再为每个工具写一次性对接；
• AI 应用或智能体：MCP 让它们接入一个由数据源、工具和应用组成的生态，能力边界被大大拓宽，终端用户体验也随之提升；
• 终端用户：MCP 让 AI 应用更能干，能访问用户的数据，并在必要时代用户执行操作。

广泛的生态支持

MCP 是一个开放协议，已经被大量客户端和服务器支持。AI 助手方面，Claude 和 ChatGPT 都支持 MCP；开发工具方面，Visual Studio Code、Cursor、MCPJam 等也都支持 MCP。这意味着你"写一次服务器，可以接入所有这些客户端"。

架构：参与者与分层

三个核心参与者

MCP 采用客户端-服务器架构，但实际是三个角色：

• MCP Host（宿主）：发起并管理一个或多个 MCP 客户端的 AI 应用本身，例如 Claude Code、Claude Desktop、Visual Studio Code；
• MCP Client（客户端）：宿主内部为每个 MCP 服务器建立的一个连接对象，负责和对应服务器保持专用连接；
• MCP Server（服务器）：向客户端提供上下文的程序，例如文件系统服务器、数据库服务器、GitHub 服务器。

举例来说：Visual Studio Code 作为 MCP 宿主，当它连接到 Sentry MCP 服务器 时，运行时会实例化一个 MCP 客户端对象来维护这条连接；当它再连接到本地文件系统服务器时，会再实例化另一个客户端对象。本地 MCP 服务器（用 STDIO 传输）通常只服务一个客户端；远程 MCP 服务器（用 Streamable HTTP 传输）通常要服务很多客户端。

两层结构

MCP 分为两层：

• 数据层（Data layer）：定义基于 JSON-RPC 的客户端-服务器通信协议，包括能力发现、版本协商，以及工具、资源、提示词、通知等核心原语；
• 传输层（Transport layer）：定义客户端和服务器之间的通信机制和通道，包括连接建立、消息帧、鉴权。

数据层在内、传输层在外。数据层实现的是 JSON-RPC 2.0 交换协议，定义消息结构和语义，包含：发现（客户端通过 server/discover 查询服务器支持的协议版本、能力和身份）、服务器功能（工具、资源、提示词）、客户端功能（elicitation 向用户索取输入；sampling 在 2026-07-28 版本起已弃用）、以及通知和进度跟踪等辅助能力。

传输层支持两种机制：

• Stdio 传输：用标准输入输出流在本机进程间直接通信，零网络开销，性能最佳，适合本地服务器；
• Streamable HTTP 传输：用 HTTP POST 发送客户端到服务器的消息，可选 Server-Sent Events 做流式返回，支持远程服务器通信，并支持 bearer token、API key、自定义 header 等标准 HTTP 鉴权方式，MCP 推荐用 OAuth 获取鉴权令牌。

传输层把通信细节抽象掉，使得所有传输方式下都用同一种 JSON-RPC 2.0 消息格式。

无状态与发现

MCP 是一个无状态协议。每个请求都在自己的 _meta 字段里携带协议版本和与本次请求相关的能力，服务器因此可以独立处理每个请求。客户端也应在同一字段里标识自己。服务器通过强制实现的 server/discover 请求来宣告自己支持的版本和能力——客户端在发任何其他请求之前可以先调用它。发现响应通常是可缓存的，不需要每个请求都重新握手。

核心原语（Primitives）

原语是 MCP 里最重要的概念，定义了客户端和服务器之间可以互相提供什么。服务器可以暴露三种核心原语：

• Tools（工具）：可执行函数，AI 应用可以调用它来执行动作，例如文件操作、API 调用、数据库查询；
• Resources（资源）：提供上下文信息的数据源，例如文件内容、数据库记录、API 响应；
• Prompts（提示词）：可复用的模板，帮助结构化与语言模型的交互，例如系统提示、few-shot 示例。

每种原语都有对应的发现方法（*/list）、获取方法（*/get），部分还有执行方法（tools/call）。客户端会先用 */list 发现可用原语，再决定调用哪个；这种设计让列表可以动态变化。以一个数据库服务器为例：它可以暴露"查询数据库"的工具、一个包含数据库 schema 的资源、以及一个包含 few-shot 示例的提示词。

客户端也可以暴露原语，让服务器作者构建更丰富的交互：

• Elicitation（ elicitation）：允许服务器向用户请求额外信息或请求确认，通过 elicitation/create 方法发起，走 Multi Round-Trip Requests 模式；
• Sampling（采样）：允许服务器请求客户端的 AI 应用做语言模型补全——注意此能力在 2026-07-28 版本起已弃用，新实现应直接对接 LLM 厂商 API；
• Logging（日志）：允许服务器向客户端发送日志，也已弃用，新实现应写到 stderr 或用 OpenTelemetry。

此外，协议还支持可选的扩展，例如 Tasks 扩展允许服务器为长时间运行的请求返回一个持久句柄，客户端可以轮询状态、稍后取回结果。

发现与通知示例

一个典型的 MCP 交互流程是这样的：客户端在发其他请求之前，先发送 server/discover 请求。请求体里通过 _meta 带上协议版本（例如 2026-07-28）、客户端名字和版本、客户端能力（例如支持 elicitation）。服务器返回它支持的协议版本列表、自己的能力（例如 tools 是否支持列表变化通知、resources 是否可用）、服务器名字和版本，以及一个 ttlMs 字段表示这份发现结果可以缓存多久。这一步做完，后面的业务请求就不必每次都重复握手。

协议还支持实时通知：当服务器的可用工具发生变化（例如新增功能或修改了已有工具）时，服务器可以主动向已连接的客户端推送工具更新通知。通知是 JSON-RPC 2.0 的 notification 消息，不需要回复。变化通知是"可选订阅"的：客户端先打开一条长连接 subscriptions/listen，声明自己想接收哪类通知，服务器再在这条流上推送对应的事件。这种设计让客户端能感知到工具列表的动态变化，而不是靠定期轮询。

服务器侧的三大构件

官方把服务器能力拆成三种构件，用一个"旅行规划"的假想场景说明：

工具用 JSON Schema 做输入输出校验，每个工具定义一个明确的操作，可能要求用户在执行前同意。协议操作包括 tools/list（发现可用工具，返回带 schema 的工具定义数组）和 tools/call（执行某个工具，返回执行结果）。一个典型的工具定义长这样：

{
  name: "searchFlights",
  description: "Search for available flights",
  inputSchema: {
    type: "object",
    properties: {
      origin: { type: "string", description: "Departure city" },
      destination: { type: "string", description: "Arrival city" },
      date: { type: "string", format: "date", description: "Travel date" }
    },
    required: ["origin", "destination", "date"]
  }
}

在旅行规划场景里，AI 应用可以依次调用多个工具：先 searchFlights(origin: "NYC", destination: "Barcelona", date: "2024-06-15") 查多个航司并返回结构化结果，再 createCalendarEvent(title: "Barcelona Trip", startDate: "2024-06-15", endDate: "2024-06-22") 在日历里占上时间。

资源（Resources）则是另一类：它是只读的上下文数据源，由应用决定何时读取，而不是模型自主调用。例如旅行规划场景里，服务器可以提供一个"当前用户偏好"资源，应用在对话开始时把它读出来塞进上下文，让模型知道用户喜欢靠窗座位、素食。资源通过 */list 和 */get 暴露，还支持参数补全（parameter completion），让客户端在填参数时给出候选建议。

提示词（Prompts）是预建模板，由用户主动触发，用来把"怎么做某类任务"固化下来。例如服务器可以提供一个"帮我规划假期"的提示词模板，用户在客户端里点一下，模板就会带上预设的指令和示例被加载进对话。这样普通用户不必自己写提示词，就能享受到专家级的提示工程。

MCP 还天然支持把多个服务器组合起来：一个宿主可以同时连航班服务器、日历服务器、酒店服务器，让模型在一次对话里跨多个服务器协调完成一次完整的旅行预订，而不是被限制在单个工具里。

常见问题（FAQ）

问：MCP 和直接写函数调用有什么区别？ 答：函数调用是单个 AI 应用内部的能力；MCP 是跨应用、跨语言的标准协议。你写一个 MCP 服务器，Claude、VS Code、Cursor、ChatGPT 都能直接连上来用，不必为每个应用单独适配。

问：MCP 服务器跑在哪里？ 答：可以本地也可以远程。本地服务器用 STDIO 传输，随 AI 应用一起启动，例如文件系统服务器；远程服务器用 Streamable HTTP 传输，部署在云端，例如 Sentry 官方服务器。

问：MCP 是无状态的吗？ 答：是。每个请求都自带协议版本和能力信息，服务器可以独立处理每个请求；发现响应可以缓存，不用每次握手。

问：服务器能不能反过来向用户要信息？ 答：可以，这就是 elicitation：服务器通过 elicitation/create 请求用户补充输入或确认动作，走 Multi Round-Trip Requests 模式。

问：MCP 官方提供哪些官方实现？ 答：规范本身、多语言 SDK、开发工具（包括 MCP Inspector）、以及参考服务器实现（文件系统、数据库、GitHub、Slack、日历等）。

跳转链接

• 核心仓库：modelcontextprotocol/modelcontextprotocol
• 官方文档：modelcontextprotocol.io
• 参考服务器：modelcontextprotocol/servers
• 调试工具：MCP Inspector
• 协议规范：modelcontextprotocol.io/specification/latest
• 社区：Discord