MCP 发布文章：把模型连接问题提升为开放协议
原始来源
Anthropic，2024-11-25：Introducing the Model Context Protocol。本页阅读的是发布时的历史文章；当前协议细节以 MCP 最新规范为准。
本页是原创学习导读，不含原文复刻；文章版权与完整内容以原始来源为准。
当前协议核验范围
本页的“当前协议补充”已核验 MCP 2026-07-28 规范及官方发布说明 The 2026-07-28 Specification，核验日期为 2026-08-09。历史发布主张与当前线级协议不会混写。
学完后你应该能做到什么
读完本篇，你应该能够：
- 画出模型、Host、Client、Server 和底层业务系统之间的边界，并说明谁承担什么责任。
- 区分 Resources、Prompts 与 Tools 的数据形态、典型控制者和副作用。
- 追踪一次当前 MCP 请求从能力发现、上下文读取到工具调用和结果返回的完整路径。
- 解释 MCP 与模型 Tool Calling 的层级差异，而不是把两者当成竞争语法。
- 明确协议兼容不等于授权、安全、正确性或可信数据，并识别仍由实现方负责的门禁。
- 说明 2024 发布文章的历史贡献，以及 2026-07-28 规范为何不能再用旧的
initialize会话生命周期讲解。
发布时的问题：连接数量为什么会失控
假设有三个 AI 应用：聊天助手、IDE 和数据分析 Agent；它们都要连接 GitHub、Postgres、Google Drive 和一个内部业务系统。如果每个应用都为每个系统单独写集成，就会产生近似 应用数 × 系统数 的连接工作：
- 每套集成都要重新定义能力描述、参数和返回格式。
- 身份认证、权限和错误处理容易出现不同实现。
- 服务一改字段，多个客户端都要跟着改。
- 模型上下文、只读数据和有副作用动作常被塞进同一套不清晰接口。
2024 年发布文章把这个问题重新定义为开放协议问题：数据或能力提供者实现 MCP Server，AI 应用实现 MCP Client，双方通过共同协议连接。发布时同时给出了规范和 SDK、本地 Claude Desktop 支持，以及一组开源 Server 示例。
它的历史意义不只是“Anthropic 又提供了一种工具调用方式”，而是尝试把外部连接从单个产品的专有适配器，提升为可由不同客户端和服务端共同实现的生态边界。
先把五个角色分开
| 角色 | 负责什么 | 不应该偷走谁的责任 |
|---|---|---|
| 用户 | 提出目标、选择上下文、批准敏感操作、验收结果 | 不应被默认视为已同意所有数据发送和工具执行 |
| 模型 | 根据提供的上下文生成回答或提出工具调用 | 不直接拥有网络、文件或生产系统权限 |
| Host | 承载用户体验、模型调用、MCP Client、权限 UI 与总体策略 | 不能把 Server 声明当成可信事实而跳过门禁 |
| Client | Host 内连接一个 Server 的协议适配器，发送请求并接收结果 | 不决定业务系统最终是否授权 |
| Server | 把外部系统包装成 Resources、Prompts、Tools 等协议能力 | 不自动成为底层数据和动作的安全所有者 |
一台 Host 可以创建多个 Client，每个 Client 连接相应 Server；Server 背后可能是本地文件、Git 仓库、数据库或远程 SaaS。模型通常只看到 Host 选择放入上下文的能力描述与返回值，并不直接“说 MCP”。
flowchart LR U["用户：目标、选择与批准"] --> H["Host：UI、模型、策略与权限"] H --> M["LLM：理解上下文并提出调用"] H --> C1["MCP Client A"] H --> C2["MCP Client B"] C1 <--> S1["MCP Server：代码仓库"] C2 <--> S2["MCP Server：业务系统"] S1 <--> D1["Git / Files"] S2 <--> D2["Database / API"]
这里最关键的边界是：模型提出动作，Host 决定是否允许并经 Client 发送，Server 再根据调用者身份和业务规则执行或拒绝。
Server 暴露的三类核心能力
截至 2026-07-28 规范，Server 可以向 Client 暴露 Resources、Prompts 和 Tools。三者不是同一个 JSON 盒子的不同名字。
Resources：可读取的上下文与数据
Resource 用 URI 唯一标识，可承载文本或二进制内容，例如文件、数据库 schema、项目说明或应用特定信息。Client 可以先 resources/list，再用 resources/read 读取具体 URI，也可以使用带参数的 Resource Template。
规范把 Resource 描述为应用驱动（application-driven）：Host 决定怎样展示、搜索、筛选或自动加入上下文。模型可以参与选择，但协议不要求 UI 必须采用某种交互形式。
Resource 主要回答：“有哪些数据可以作为上下文，以及怎样读取？”读取也可能暴露敏感信息，因此“只读”不等于“无风险”。
Prompts：由 Server 提供的可复用消息模板
Prompt 是带名称、描述和可选参数的结构化消息模板。Client 可通过 prompts/list 发现，再用 prompts/get 带参数取得具体消息。
规范把 Prompt 描述为用户控制（user-controlled）：设计意图是让用户显式选择何时使用，例如界面命令。这里说的是“谁决定使用”，不是“谁编写内容”；模板仍由 Server 定义，所以 Host 仍应把它当外部输入进行审查。
Prompt 主要回答：“有没有一套可复用的交互入口或工作流模板？”它本身不等于执行动作。
Tools：可被模型提出调用的函数
Tool 用名称标识，并带有说明、输入 schema，以及可选输出 schema。Client 通过 tools/list 得到目录，用 tools/call 发送名称和参数；Server 返回文本、结构化内容、资源链接或错误。
规范把 Tool 描述为模型控制（model-controlled），意思是模型可以根据上下文自动选择并提出调用。它不代表模型获得最终授权。规范同时要求实现方清楚展示可用工具、显示调用，并让人能够拒绝操作。
Tool 主要回答：“外部系统允许执行哪些计算或动作？”由于它可能修改文件、调用 API 或执行代码，风险通常高于读取 Resource。
| 能力 | 典型内容 | 典型决定者 | 是否可能有副作用 |
|---|---|---|---|
| Resource | 文件内容、schema、业务数据、URI 模板 | Host / 应用选择上下文 | 通常读取，但仍有数据泄露风险 |
| Prompt | 带参数的消息或工作流模板 | 用户显式选择 | 通常不直接执行，内容仍可能不可信 |
| Tool | 查询、计算、创建、修改或外部操作 | 模型可提出，Host/用户应授权 | 可能，必须按真实动作建模 |
一次能力使用的输入、输出与状态
| 部分 | 内容 | 责任边界 |
|---|---|---|
| 输入 | 协议版本、Client 身份与能力、方法名、能力名、参数、授权信息 | Client 构造；Host 在发送前执行策略 |
| 能力目录 | Server 提供的 Resources、Prompts、Tools 及 schema | Server 描述；Client 验证，Host 决定暴露给模型多少 |
| 请求状态 | 当前一次 JSON-RPC 请求、可选显式业务句柄 | 2026-07-28 核心没有隐式协议会话 |
| 输出 | 完成结果、需要额外输入的结果，或协议/工具错误 | Client 必须区分数据、错误与需要确认的状态 |
| 反馈 | 返回内容重新进入 Host，可能供模型继续决策 | Host 过滤、标记来源并控制上下文 |
| 停止条件 | Host 任务完成、用户拒绝、策略阻止、错误或预算耗尽 | MCP 只承载消息，不替应用定义业务完成 |
端到端案例：让代码助手读取仓库并运行测试
假设用户说：“阅读仓库的贡献指南，检查这个补丁是否通过相关测试。”Host 连接了一个仓库 MCP Server。按 2026-07-28 规范，可以形成如下路径：
- 选择协议版本：Client 准备使用
2026-07-28。它可以先调用可选的server/discover，取得 Server 支持的版本、身份和能力；也可以直接发送具体 RPC，在版本不支持时处理错误。 - 发现内容能力：Client 请求
resources/list，Server 返回贡献指南、仓库文件等 Resource 描述；Host 只选择与任务相关且用户允许的条目。 - 读取上下文：Client 调用
resources/read获取贡献指南。Host 标注它来自外部 Server，再放进模型上下文。 - 发现动作能力：Client 调用
tools/list，得到例如run_tests的名称、参数 schema 和说明。Host 决定是否向模型暴露该工具。 - 模型提出调用：模型结合补丁和贡献指南，生成结构化意图：调用
run_tests，参数为允许的测试路径。 - Host 门禁：Host 检查路径范围、资源预算和副作用，必要时让用户确认。通过后，Client 发送
tools/call。 - Server 执行：Server 再检查调用者授权与参数，运行受控测试，返回状态、日志摘要和结构化结果；失败应作为明确错误返回。
- 模型解释结果：Host 把结果标为工具输出后交给模型，模型据真实日志说明补丁是否通过。
- 应用验收：Host 根据测试状态和用户要求结束，而不是因为 MCP 请求成功返回就自动认定补丁正确。
sequenceDiagram participant U as User participant H as Host + LLM participant C as MCP Client participant S as Repository Server U->>H: 请求审查补丁 H->>C: 获取允许的资源与工具 C->>S: server/discover（可选）/ resources/list / tools/list S-->>C: 版本、能力与 schema H->>C: 读取贡献指南 C->>S: resources/read S-->>C: 文档内容 H->>U: 展示拟运行测试和影响，必要时确认 U-->>H: 批准 H->>C: 调用 run_tests C->>S: tools/call S-->>C: 结构化状态与日志 C-->>H: 带来源的工具结果 H-->>U: 按测试证据给出结论
为什么 MCP 不是 Tool Calling 的另一种拼法
| 问题 | 模型 Tool Calling | MCP |
|---|---|---|
| 主要边界 | 模型输出与 Host 工具执行器之间 | Host 内 Client 与外部 Server 之间 |
| 主要作用 | 让模型提出结构化函数名与参数 | 标准化能力发现、数据读取、提示获取、工具请求和结果格式 |
| 谁向模型提供工具定义 | Host 或模型 API | MCP Server 经 Client 提供，Host 决定是否暴露 |
| 是否定义模型推理方式 | 否 | 否 |
| 是否自动授权执行 | 否 | 否 |
二者可以串联：MCP Server 通过 tools/list 提供工具 schema，Host 把允许的定义放入模型上下文；模型产生 Tool Calling；Host 审批后用 MCP Client 发送 tools/call。因此 Tool Calling 是“模型怎样表达想调用什么”，MCP 是“应用怎样从外部提供方发现并承载这次调用”。
当前协议补充：2026-07-28 已不再使用旧握手生命周期
截至 2026-08-09 的最新版机制
2026-07-28将 MCP 核心改为无状态、逐请求的协议。不要再把旧版initialize → initialized → 带 Mcp-Session-Id 持续会话画成当前标准流程。
当前版本的关键变化是：
- 核心取消
initialize/initialized交换和Mcp-Session-Id协议会话。 - 每个请求都自描述，在
_meta中携带协议版本、Client 身份和 Client 能力；HTTP 还携带相应协议与路由头。 - Server 必须实现
server/discover，但 Client 是否先调用它是可选的；Client 可以直接调用 RPC 并处理不支持版本错误。 - 需要跨调用保持业务状态时，Server 应显式返回句柄，例如
basket_id，后续工具调用把它当普通参数传回。句柄不是协议会话，也不能跳过逐次授权。 - 工具中途需要用户补充信息或确认时，可返回
input_required，通过 Multi Round-Trip Requests 让 Client 携带输入再次提交原请求。
这一区分非常重要：协议核心无状态，不等于业务应用不能有状态。状态从隐藏的连接会话移到模型、Host 和 Server 都能明确看到并治理的业务句柄中。
协议没有替你解决的安全问题
MCP 定义通信形状，不替实现方建立信任。至少还要处理：
- 用户同意：用户必须知道哪些数据会发给哪个 Server、哪个动作即将执行。
- 身份与授权：Server 应在每次请求上验证调用者是否能访问对应资源或句柄；发现能力不等于获准使用。
- 最小权限：Host 只暴露当前任务需要的 Server、Resource 和 Tool，Server 也只授予必要作用域。
- 输入输出校验：Tool schema、路径、URL、返回内容和 Server 描述都可能不可信。
- 提示注入防护：Resource 与 Prompt 是外部数据，不能因其中写着“忽略规则”就提升为系统指令。
- 副作用确认与幂等性：删除、支付、发布等动作要有清晰确认、重试语义和审计记录。
- 结果真实性：协议成功只表示消息交换成功；工具可能出错、数据可能陈旧、Server 可能撒谎。
“Server 描述说它安全”不是安全证据
Tool 名称、描述和注解来自 Server。Host 必须结合 Server 信任级别、真实参数、授权范围和可观察副作用做决策，不能把描述直接当成经过验证的政策。
常见失败模式与调试顺序
| 失败现象 | 可能根因 | 先检查什么 |
|---|---|---|
| 模型看不到某个工具 | Server 未暴露、Client 未发现、Host 策略过滤或版本不兼容 | 逐层检查 Server → Client → Host → 模型的能力目录 |
| 同名工具调用了错误服务 | 多 Server 命名冲突或来源信息丢失 | 保留 Server 身份与命名空间，不只传裸名称 |
| 请求协议成功但业务失败 | 把 JSON-RPC 成功当成动作成功 | 检查 isError、结构化结果和业务验收状态 |
| 升级后还在等待初始化 | 实现仍假设旧版 stateful 生命周期 | 核对版本；对 2026-07-28 使用逐请求元数据和可选发现 |
| 显式句柄访问越权 | 把句柄当成授权凭据 | Server 每次调用都重新验证身份与资源权限 |
| Resource 引发提示注入 | 外部数据与系统指令混在一起 | 标注来源、隔离指令层、过滤并限制可用工具 |
历史贡献与今天的工程解释
2024 发布文章直接提出的历史主张是：用开放 Client–Server 标准替代碎片化的数据源集成，让提供方可以实现 Server，让 AI 应用实现 Client；首发包含规范、SDK、本地客户端支持和示例 Server。
今天的工程解释应以具体规范版本为准。Host/Client/Server、Resources/Prompts/Tools 仍是理解边界的核心，但传输、版本协商、授权和扩展会演进。尤其是 2026-07-28 的无状态核心已经改变旧版生命周期，教程必须标日期而不能把历史示例冒充最新版。
协议的长期价值在于减少连接接口的重复劳动、形成可替换实现和共同生态；它不保证某个 Server 值得信任，也不替产品决定哪些能力应该开放。
与相邻原典的关系
Toolformer 研究模型怎样从训练数据中获得工具使用行为；AutoGen 研究应用内部角色怎样通过消息协作；MCP 研究 Host 与外部能力提供方怎样通过共同协议交换资源、提示和工具调用。三者分别位于模型行为、应用编排和外部连接层。
自测：确认你真的掌握了机制
- 模型、Host、Client 与 Server 各自负责什么？为什么模型不应直接持有业务系统凭据？
- 给“数据库 schema”“代码审查模板”“创建工单”分别选择 Resource、Prompt 或 Tool，并解释原因。
- MCP 与 Tool Calling 怎样串联？哪一个负责模型输出，哪一个负责外部协议边界？
- 在
2026-07-28中，Client 是否必须先调用server/discover？为什么不能再画initialize会话流程？ - 一个
tools/call收到成功 JSON-RPC 响应，为什么任务仍可能失败？
参考答案与判断要点
- 模型提出内容和调用；Host 管理用户体验、模型、权限和策略；Client 承载与一个 Server 的协议请求；Server 包装外部能力并执行服务端授权。凭据应留在受控边界，不能进入可生成和泄露文本的模型上下文。
- Schema 是可读上下文，适合 Resource；代码审查模板是用户选择的结构化消息，适合 Prompt；创建工单改变外部状态，适合 Tool。
- Host 可把 MCP 发现的 Tool schema 提供给模型，模型用 Tool Calling 提出名称和参数，Host 批准后再通过 MCP Client 发出
tools/call。- 不必须；Server 必须支持发现，但 Client 可直接请求并处理版本错误。当前核心逐请求携带版本、身份和能力，已经取消旧握手与协议会话。
- 协议返回只证明请求得到响应；工具可能返回业务错误、错误数据或不完整结果，Host 仍需解析状态、执行断言并按用户目标验收。