| 版本 | 内容 | 时间 | | ---- | ---- | ------------------- | | V1 | 新建 | 2026-08-12 11:00:02 | > 本文参考 MCP 协议版本 2026-07-28 ## MCP 是什么？ MCP 是 Anthropic 开源的一套标准协议，用于连接 AI 应用与外部系统 —— 包括本地文件、数据库、API 服务、搜索引擎、甚至是 3D 打印机。它的定位非常清晰：**MCP 只管上下文交换的协议层，不管 AI 应用如何使用 LLM 或如何消费拿到的上下文。** 打个比方：USB‑C 不关心你插的是显示器还是硬盘，它只管定义电力传输和数据通信的标准。MCP 也一样 —— 它不关心 Claude 拿到的上下文是用来写代码还是查日历，它只管定义「AI 应用如何发现、请求、接收外部上下文」的标准。这解决了什么问题？核心是两个： **1. 上下文隔离问题。** LLM 本身是一个封闭系统——它只知道训练数据里的东西，对「你的文件系统里有什么」「你的数据库里最新的订单数据是什么」「你的日历下周三有没有空」一无所知。要让 LLM 获取外部上下文，以前的做法是在每个应用的 Prompt 层手动拼接，缺乏标准。 **2. M×N 集成问题。** 假设你有 5 个 AI 工具（Claude Desktop、Cursor、VS Code Copilot、自定义 Agent、ChatGPT）和 5 个外部系统（文件系统、数据库、Google Calendar、Jira、Slack），传统的点对点集成方式是 5×5=25 套对接。每套对接都有独立的认证方式、数据格式、错误处理——维护成本随工具和系统的增长而指数级膨胀。 ``` 传统模式：M×N 组合爆炸 ┌───────┐ ┌──────┐ │ Claude │───▶│ Filesys │ │ │───▶│ Database │ │ │───▶│ Calendar │ │ │───▶│ Jira │ │ │───▶│ Slack │ ├───────┤ └──────┘ │ Cursor │───▶ ... 又一套 │ ChatGPT │───▶ ... 再来一套 │ ... │───▶ ... 无穷无尽 └───────┘ MCP 模式：M+N 线性对接 ┌──────────┐ │ Claude ────┤ │ Cursor ────┤ ┌──────┐ │ ChatGPT ───┤── MCP Client ──▶│ FileSvr │ │ Agent ────┤ (统一协议) │ DBServer │ │ ... │ │ CalSvr │ └──────────┘ │ JiraSvr │ │ SlackSvr │ └──────┘ ``` MCP 把复杂度从「乘法」降到「加法」：每个外部系统实现一个 **MCP Server**；每个 AI 应用实现 **MCP Client**。任意 AI 与任意外部系统即可互通。工程价值：新增一个 AI 工具，不用为每一个外部系统重写对接；新增一个数据源，也不用适配每一个 AI 应用。 ## MCP 架构全景 MCP 的架构由三个核心角色和两个协议层组成，职责划分非常清晰。 ```mermaid %%{init: { 'flowchart':{'nodeSpacing': 0, 'rankSpacing':90}}}%% flowchart TD subgraph MCP_Host["MCP Host (AI 应用)
(如 Claude Desktop)"] MC1["MCP Client
(连接 Server A)"] MC2["MCP Client
(连接 Server B)"] MC3["MCP Client
(连接 Server C)"] end T1["Transport
(stdio)"] T2["Transport
(Streamable HTTP)"] T3["Transport
(Streamable HTTP)"] S_A["MCP Server A
(本地文件)"] S_B["MCP Server B
(Sentry 远程服务)"] S_C["MCP Server C
(DB)"] MC1 --> T1 --> S_A MC2 --> T2 --> S_B MC3 --> T3 --> S_C ``` 三个核心角色： - **MCP Host**：AI 应用本身，如 Claude Desktop、VS Code、Cursor。它负责管理多个 MCP Client 的生命周期，并将获取到的上下文注入 LLM。 - **MCP Client**：由 Host 创建，每个 Client 与一个 MCP Server 维持一对一的专用连接。如果一个 Host 连接了三个 Server，就会有三个 Client 实例。它从 MCP Server 获取所需的信息，供 MCP Host使用。 - **MCP Server**：上下文提供者，暴露 Tools（可执行函数）、Resources（数据源）和 Prompts（交互模板）。Server 可以本地运行（如文件系统 Server），也可以远程部署（如 Sentry 的官方 MCP Server）。 **为什么这种分层很重要？** Host 不需要知道每个 Server 的内部实现；Server 不需要知道它被哪个 AI 应用消费。Client 作为中间的翻译层，把 Server 的原语（Tools / Resources / Prompts）转译成 Host 能直接消费的上下文。这是典型的 **关注点分离** 设计——每一层只管自己的事，变更被隔离在边界内。 ## 双层协议设计：Data Layer 与 Transport Layer MCP 在垂直方向上也做了清晰的分层： - **数据层**：基于 JSON‑RPC 2.0 作为报文载体，定义 MCP 全部业务语义：协议版本协商、能力探测、工具调用、资源读取、提示模板、事件通知等。 - **传输层**：负责客户端与服务端之间的连接生命周期、字节流收发、消息帧编解码。MCP 定义两套标准传输实现：本地`stdio`、远程`Streamable HTTP`。 ### Data Layer 数据层基于 JSON‑RPC 2.0，定义了 MCP 的消息结构和业务语义。它包含四个核心部分： - **发现功能**：通过 `server/discover` 请求，Client 查询 Server 支持的协议版本、大类能力开关以及服务身份信息。这个请求是可选握手：JSON‑RPC 消息的`_meta`字段携带协议版本，Client 可以直接发起业务请求；收到版本不兼容错误之后，再执行版本协商与`server/discover`。 - **Server 功能**：Tools（可执行函数，允许产生副作用）、Resources（只读上下文数据源）、Prompts（交互提示模板），这是 Server 向 Client 输出能力与上下文的核心通道。 - **Client 功能**：Elicitation（征询），允许 Server 请求 Client 向终端用户收集补充输入。 > 历史说明：旧协议中的 Sampling（Server 请求 Host 侧 LLM 推理）与旧版 Logging，在协议版本 **2026‑07‑28 已正式废弃移除**。 - **附加功能**：支持各种附加功能，比如实时更新通知，以及针对耗时较长的操作提供进度跟踪功能。 ### Transport Layer 传输层负责管理客户端与服务器之间通信渠道、连接生命周期、消息帧编解码。安全认证由具体传输实现处理：`stdio`依靠本机操作系统权限；`Streamable HTTP`复用 HTTP 体系能力做鉴权，**MCP 传输层规范本身没有定义统一认证原语**。 MCP 定义了两个标准传输机制： | 特性 | stdio | Streamable HTTP | | -------------- | ------------------------------------------- | --------------------------------------------- | | 通信方式 | 标准输入输出管道 | HTTP POST + 可选 SSE 流式通知 | | 网络模式 | 仅本地进程间通信 | 支持远程跨机器通信 | | 消息帧 | `\n`换行分隔 JSON‑RPC 报文（仅 stdout） | HTTP 请求 / 响应 Body；SSE 用于服务端推送事件 | | 认证 | 本机 OS 权限信任，无协议鉴权 | Bearer Token / API‑Key / OAuth（HTTP 层） | | 适用场景 | 本地文件、本机 Shell 本地工具 | 云端远程服务、多租户企业场景 | | 多 Client 支持 | 单 Client 一对一，一个进程仅对接一个 Client | 一对多，单服务实例可服务大量 Client | > 注意：stdio 中，`stderr`仅输出人类可读日志，**不传递 MCP 协议消息**。 `stdio`优势是零网络开销、零网络配置：Host 直接 fork 拉起 Server 子进程，通过管道完成交互。适合文件系统操作、本地 Shell 命令等本机场景；该模式是本机全信任模型，不要拉起不受信任的第三方 MCP 子进程。 `Streamable HTTP`面向企业云端场景：例如 Sentry MCP Server 部署在公网，开发者通过 HTTPS + OAuth 接入，无需在本地安装程序。 > Streamable‑HTTP 中 SSE 只负责**Server 向 Client 单向推送通知、进度事件**；Client 发起的全部业务请求依旧使用 HTTP POST。关键设计：**协议语义与传输层解耦**。无论是`stdio`还是`Streamable HTTP`，上层 JSON‑RPC 消息结构完全一致。同一套 MCP Server 业务代码，可以选择以 stdio 子进程模式启动，或者以 Streamable‑HTTP HTTP 服务模式启动；Client 侧业务逻辑不需要修改即可切换传输方式。 > ⚠️注意：同一个运行进程实例不能同时开启两种传输；只是代码复用，启动模式二选一。 ## MCP Server 功能 MCP 定义了三种核心原语，它们是 Server 向 AI 应用暴露能力的标准方式。 ### Tools（工具）：让 AI 执行操作 Tools 是 MCP 中最强大的原语 —— 它让 AI 不仅能「知道」外部世界，还能「操作」外部世界。AI 应用程序可以调用的各种可执行功能，用于执行各种操作（例如文件操作、API 调用、数据库增删改等）。 Tools 本质上是把 AI 的「理解能力」和程序的「执行能力」连接在一起。AI 理解用户的自然语言意图，选择合适的工具并填入参数；工具执行实际的操作并返回结构化结果。这是 AI Agent 从「聊天机器人」进化到「行动代理」的关键基础设施。 > ⚠️重要边界：MCP Server 负责描述工具定义、接收调用请求、执行业务逻辑；**参数校验、权限控制、高危确认、调用审计属于 MCP‑Client 职责，不由 Server 保证**。 ### Resources（资源）：让 AI 读取上下文 Resources 是应用数据向模型的「暴露层」—— 它让 AI 应用读取文件内容、数据库记录、API 响应等上下文数据。与 Tools 不同，Resources 在语义上是**只读的**—— 它们提供上下文数据供 AI 理解，但不执行副作用操作。一个典型的资源可能是一个数据库连接的 Schema 描述，或者是当前 Git 仓库的文件树。 > 注意：协议语法层面并不强制拦截写入，这是开发者需要遵守的业务契约；所有产生修改的操作，都应当封装到 Tools。 > > Client 通过资源 URI 定位资源，使用 `resources/list` 列举、`resources/read` 获取内容。 ### Prompts（提示词模板）：预制的交互范式 Prompts 定义可复用的交互模板 —— 相当于给 AI 应用提供「话术脚本」。模板支持定义变量，Client 调用`prompts/get`传入变量，**由 Server 完成模板渲染，直接返回完整的 messages 消息数组，可直接交给 LLM 使用**。举个实际例子：一个数据库 MCP Server 可以提供 `analyze‑query‑performance` 的 Prompt 模板，包含分析 SQL 查询性能的 few‑shot 示例。AI 应用调用 `prompts/get`，传入待分析 SQL，Server 渲染完成后返回完整交互消息。 ## MCP Client 功能 ### Elicitation（信息索取） **Elicitation 反向流程：MCP Server 在执行任务途中，主动向 MCP Client 发送请求，委托客户端向终端人类用户获取补充信息或者操作确认；Client 拿到用户应答之后回传给 Server，Server 继续完成任务。** 典型场景：工具执行过程中缺少动态参数、高危操作需要用户确认。 > ⚠️前置约束： > > Elicitation 属于**Client 侧能力**。必须先执行`server/discover`探测 Client 是否支持该能力；如果 Client 不支持，Server 不能发起征询请求，只能直接报错终止任务。 > > Server 本身没有 UI 弹窗能力，所有和用户交互的界面逻辑完全由 MCP Client（AI 应用）实现。 > > 结果分支：用户既可以填写信息确认，也可以拒绝 / 取消；Server 收到取消应答应当终止当前执行流程。 > 历史说明：旧协议版本中的 **Sampling（Server 请求 Host 调用 LLM 推理）** 和旧版 **Logging**，在 `2026‑07‑28` 版本已经正式废弃移除。 > 💡最佳实践： > > 能够通过工具`inputSchema`提前声明的必填参数，尽量放在 Schema 在 Client 侧校验拦截；Elicitation 优先用于**运行时动态才确定需要采集**的信息。 ## Notifications 通知/提醒协议支持实时单向通知，实现服务端向客户端推送动态更新。例如服务端工具集合发生新增、修改，或者资源列表变动、长任务执行进度更新，Server 可以发送通知告知 Client。通知遵循 JSON‑RPC 2.0 通知格式：**消息没有 `id` 字段，属于单向消息，不需要客户端回复应答**。通知默认不会主动推送，采用**显式订阅 opt‑in** 模型：客户端调用 `subscriptions/create`，声明希望接收的事件类型，完成订阅。 - 在 **Streamable‑HTTP** 传输模式下，该调用返回一条 SSE 长连接流，后续通知全部在这条流上推送； - 在 **stdio** 本地传输模式，不会新建独立流，通知复用已有的 stdin/stdout 消息管道下发。典型标准通知事件： - `tools/list_changed`：工具集合发生变更； - `resources/list_changed`：资源集合发生变更； - `progress`：耗时工具任务的执行进度更新。 > ⚠️注意：每个 Client 订阅相互隔离；Client 没有执行`subscriptions/create`订阅对应事件，则不会收到任何推送。收到变更通知后，Client 需要主动调用对应的`list`接口拉取最新数据更新本地缓存。 ## 消息交互流程：从握手到执行 MCP 是无状态的——每个请求的 `_meta` 字段都携带了协议版本和 Client 能力，Server 不需要维护会话状态。这意味着**每个请求都是自包含的**，Server 可以水平扩展，请求可以被任意实例处理。让我们走一遍完整的交互流程： ### 1. Discovery（发现） Client 首先发送 `server/discover` 请求（可选，但推荐），带上自己的协议版本和能力声明： ```json { "jsonrpc": "2.0", "id": 1, "method": "server/discover", "params": { "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28", "io.modelcontextprotocol/clientInfo": { "name": "claude-desktop", "version": "1.0.0" }, "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} } } } } ``` Server 返回其能力清单： ```json { "jsonrpc": "2.0", "id": 1, "result": { "resultType": "complete", "supportedVersions": ["2026-07-28"], "capabilities": { "tools": {"listChanged": true}, "resources": {} }, "_meta": { "io.modelcontextprotocol/serverInfo": { "name": "postgres-mcp-server", "version": "2.1.0" } } } } ``` **关键信息：** `"tools": {"listChanged": true}` 告诉 Client「我的工具列表是动态的，我可以通知你变化」；`"resources": {}` 告诉 Client「我支持资源原语，但资源列表不会动态变化」。这种能力协商机制让 Client 不需要猜测 Server 的行为边界。 ### 2. Tool Discovery & Execution（工具发现与执行） Client 调用 `tools/list` 获取工具列表（含 JSON Schema 定义的参数规范）。AI 应用根据用户意图选择工具并填入参数后，Client 调用 `tools/call`： ```json { "method": "tools/call", "params": { "name": "read_file", "arguments": {"path": "/project/src/main.py"} } } ``` Server 执行后返回结果。如果执行时间较长，Server 可以通过 Progress Token 发送进度更新。 ### 3. Resource Access（资源访问） ```json // 发现资源 {"method": "resources/list"} // 读取资源 {"method": "resources/read", "params": {"uri": "db://schema/users"}} ``` Resource URI 采用类似 `scheme://path` 的格式，由 Server 自行定义命名空间。 ### 4. Notification（变更通知）当 Server 的工具集发生变化时（比如新增了工具），它会通过 `subscriptions/listen` 通道主动推送 `notifications/tools/list_changed` 通知。Client 收到后重新调用 `tools/list` 更新本地缓存。 ```json { "jsonrpc": "2.0", "method": "notifications/tools/list_changed", "params": {} } ``` **为什么通知是 opt-in 的？** 这是一个深思熟虑的设计决策。如果 Server 可以随意向 Client 推送通知，当 Client 短暂离线或忙于处理其他请求时，通知就会丢失或造成干扰。通过要求 Client 先建立 `subscriptions/listen` 通道并声明感兴趣的 notification 类型，Server 只在 Client 准备好的时候才推送，避免了「消息轰炸」的问题。 ## MCP 的设计智慧：为何不是 gRPC 或 GraphQL？ MCP 的技术选型有几个地方值得仔细琢磨，每一个都有明确的工程理由。 **为什么选择 JSON-RPC 2.0？** 早在 gRPC + Protobuf 几乎成为微服务标配的今天，MCP 却选择了一个 2010 年的协议。原因很直接：JSON‑RPC 使用人类可读的 JSON，可以用 curl 调试，可以在浏览器 DevTools 观察流量，可以直接 cat 查看 stdio 管道中的消息 —— 这对 Server 开发者调试工具调用、排查参数错误至关重要。对比 Protobuf 二进制格式，在排查 “AI 为什么调用错误工具、参数异常” 时，二进制报文排查难度会大幅上升。 > 选型不是 gRPC/GraphQL 技术能力不足： > > - gRPC：强类型 Protobuf，但在本地 stdio 子进程场景调试体验很差； > - GraphQL：擅长数据查询，而 MCP 大量是动作调用（工具调用、征询、订阅），RPC 模型更贴合 Agent 插件场景。 > > MCP 同时需要兼容**本地 stdio 子进程**与**远程 HTTP**两套运行环境，JSON‑RPC 文本格式是综合权衡后的结果 **为什么握手层改为无状态？** 2026‑07‑28 之前版本（2024‑11‑05、2025‑11‑25）使用`initialize`握手，建立持久会话状态；从 2026‑07‑28 版本起移除强制 initialize 握手，转向握手层无状态：每个请求通过`_meta`自携带协议版本信息。带来收益： - Server 可以水平扩展，不需要 sticky sticky session 粘会话； - 故障隔离：单次请求失败，不干扰后续请求； - 版本协商更灵活。 **为什么 `server/discover` 是可选的？** 你可以跳过发现步骤直接调用`tools/list`。如果 Client 预先通过配置得知 Server 能力，跳过`server/discover`可以节省一次网络往返，对延迟敏感的本地 stdio 场景带来累积收益。同时`server/discover`承担旧协议探测兼容：旧版 MCP Server 没有该接口，Client 发起`server/discover`会收到`method not found`，Client 识别为旧版本，自动回退使用 legacy `initialize`握手流程。版本号不匹配时才返回版本不兼容错误。 ## 与 LLM 应用集成的实际场景来看几个 MCP 在实际 AI 应用中如何工作的例子： **场景一：Claude Desktop + 本地文件系统。** Claude Desktop 作为 MCP Host，启动本地文件系统 MCP Server（stdio 传输）。用户在 Claude 中说「帮我分析项目的代码结构」，Claude 通过 `tools/list` 发现 `read_file`、`list_directory` 等工具，通过 `resources/read` 读取目录树，然后将这些上下文注入 LLM，生成代码结构分析。 **场景二：VS Code + Sentry MCP Server。** VS Code 作为 MCP Host，通过 Streamable HTTP + OAuth 连接到 Sentry 的远程 MCP Server。开发者在编辑器中选中一段报错日志，VS Code 调用 `tools/call` 将日志发送给 Sentry Server 查询对应的错误详情、影响范围和处理建议，结果直接显示在编辑器内联提示中——全程不需要离开编辑环境。 **场景三：多 Server 协同。** 一个自定义 AI Agent 同时连接了数据库 MCP Server、Slack MCP Server 和 Jira MCP Server。用户说「查一下昨天数据库的慢查询，把结果发到 #backend 频道，并创建一个 Jira ticket」。Agent 依次调用 `tools/call` 在不同 Server 上执行：查数据库 → 发 Slack → 创建 Jira issue。三个操作，同一套协议。 ## 构建 MCP Server 的实践要点了解了架构之后，作为服务端工程师，你可能最关心的是：**怎么实现一个 MCP Server？** 以下是几个关键设计点。 **1. 工具的参数 Schema 是 Server 开发者最重要的设计决策。** 工具的参数通过 JSON Schema 定义——这让 AI 应用能够自动理解工具的用法并填入正确的参数。一个好的参数 Schema 应该包含清晰的 `description` 字段和合理的类型约束： ```json { "name": "search_issues", "description": "Search Jira issues by keywords and status filter", "inputSchema": { "type": "object", "properties": { "query": { "type": "string", "description": "Search keywords to match against issue summary and description" }, "status": { "type": "string", "enum": ["open", "in_progress", "done"], "description": "Filter by issue status" } }, "required": ["query"] } } ``` 描述文字的质量直接决定了 AI 能否正确使用你的工具。一个常见的坑是：`description` 写得过于技术化，比如 "Accepts a JQL query string"——AI 不知道什么是 JQL。更好的写法是 "Search keywords to match against issue titles and descriptions（支持自然语言关键词）"。 **2. stdio vs Streamable HTTP 的选择。** 如果你的 Server 只服务于本机用户（如文件系统操作、本地数据库查询），stdio 是最简单的方案——零配置、零网络延迟、零安全风险。如果你的 Server 要服务于多个远程客户端（如公司内部的 API 查询服务），选择 Streamable HTTP，并配置好 OAuth 认证和速率限制。 **3. 错误处理要遵循 JSON-RPC 规范。** 不要在工具执行出错时只返回一个纯文本报错——应该返回结构化的 JSON-RPC Error 对象，包含 `code`、`message` 和可选的 `data` 字段。这样 AI 应用才能自动解析错误类型并做出合理反应（比如参数错误时重新调整参数，权限错误时提示用户授权）。 **4. 利用 `listChanged` 通知支持动态工具集。** 如果你的 Server 的工具集会根据用户权限或上下文动态变化（比如不同项目有不同的问题类型），在 `server/discover` 的 capabilities 中声明 `"tools": {"listChanged": true}`，并在工具集变化时主动推送通知。这比让 Client 定期轮询 `tools/list` 更高效。 ## 结语 MCP 正在成为 AI Agent 生态的标准基础设施。它的设计哲学值得注意：**不是重新发明一套复杂的 RPC 框架，而是在最简协议（JSON-RPC 2.0）之上定义了一套上下文交换的语义规范。** 这降低了实现门槛——一个基础 MCP Server 只需要几百行代码，任何支持 JSON-RPC 的语言都能实现。更重要的是，MCP 把「AI 如何获取外部上下文」从应用层的定制逻辑提升到了基础设施层的标准协议。就像 HTTP 统一了 Web 的通信方式，MCP 正在统一 AI 应用的上下文获取方式。对开发者来说，这意味着：写一次 MCP Server，所有支持 MCP 的 AI 工具都能用。未来，随着 MCP Registry（Server 注册中心）和 SEP（Specification Enhancement Proposals）的成熟，我们可能会看到一个类似 npm 或 Docker Hub 的 MCP Server 生态——想给你的 AI 应用接入数据库？`mcp install postgres`，一行命令搞定。 --- *参考来源：[modelcontextprotocol.io](https://modelcontextprotocol.io) — Introduction、Architecture、Transports 文档，协议版本 2026-07-28*

01-MCP-MCP是什么？.

Dylan Kwok

01-MCP-MCP是什么？