约 11 分钟4 张卡

MCP

MCP（Model Context Protocol）是连接 AI 应用与外部工具、数据源的开放协议。工具提供方实现 MCP Server 后，多个兼容的应用就能使用同一套接入方式，减少重复编写集成代码。

本文按 2025-11-25 规范，先介绍各角色的职责和能力，再沿一次工具调用解释交互与传输。随后说明错误和断线怎样处理，以及 MCP 与模型接口、业务 API 的分工和安全风险。

1. 面试核心

先记住这几条，再读正文

Host、Client 与 Server。 Host 是 AI 应用，为每个 Server 创建独立的 Client，Client 与 Server 一对一连接。卡 · 角色与能力
消息与传输。 MCP 2025-11-25 用 JSON-RPC 2.0 交换消息，标准传输包括 stdio 与 Streamable HTTP。
服务端能力。 Server 提供 Tools 执行操作、Resources 供应用读取数据、Prompts 供用户选择提示模板。
协议分工。 MCP 负责能力发现和调用，Function Calling 表达模型请求。卡 · Function Calling 与 API 分工
授权边界。 Roots 只声明工作目录，文件访问由进程权限和沙箱限制，工具与数据访问仍需逐次授权。卡 · 安全风险

2. 角色与能力

必会卡 · MCP 是什么？Agent 通过 MCP 调用工具的流程是什么？

MCP 把应用、连接和能力提供方分开，方便一个应用同时接入多个服务。理解消息流程之前，先区分三个角色：

Host 是用户使用的 AI 应用，例如 IDE 或桌面客户端。它组织模型请求，管理连接和授权。
Client 是 Host 内部的协议客户端。每个 Client 对应一个 Server，负责建立连接和收发消息。
Server 是提供工具、数据或提示模板的程序。它可以是本地子进程，也可以是独立部署的服务。

Host（AI 应用）
  ├─ Client A ↔ Server A（本地 stdio）
  └─ Client B ↔ Server B（Streamable HTTP）

Server 提供的能力与 Client 支持的特性各有用途，下表列出它们的分工。

提供方	能力	用途
Server	Tools	模型可选择的操作
Server	Resources	应用读取的 URI 资源
Server	Prompts	用户选择的提示模板
Client	Sampling	接受 Server 的模型采样请求
Client	Roots	向 Server 声明工作目录
Client	Elicitation	接受 Server 的用户信息收集请求

Tools、Resources、Prompts 分别强调模型、应用和用户控制，具体含义如下：

Tools 是带参数规则的可执行操作，例如创建 Issue。参数规则使用 JSON Schema，说明字段类型和必填项，模型据此生成调用请求。
Resources 是用 URI 标识的数据，例如文件内容或数据库表结构。URI 是资源的地址或标识，应用通过它读取内容，再决定是否交给模型。
Prompts 是预定义的提示模板，由用户选择使用。例如，Host 可以把模板显示为斜杠命令，用户选择后再填入参数。

这些控制方式说明谁主导使用，具体界面和授权流程仍由 Host 设计。Client 还可以声明支持 Sampling、Roots 和 Elicitation。Sampling 允许 Server 请求 Host 代为调用模型；Elicitation 允许 Server 请求向用户收集补充信息。双方在初始化时声明能力，之后按协商结果使用。

Roots 用来告诉 Server 当前工作的目录范围。它只是目录声明，无法独立强制文件隔离。真正能读写哪些文件，取决于 Server 进程的权限和沙箱限制。

3. 交互流程

必会卡 · MCP 是什么？Agent 通过 MCP 调用工具的流程是什么？卡 · MCP 协议错误、工具执行错误和 HTTP 断线应如何区分？

MCP 使用 JSON-RPC 2.0 组织请求、响应和通知。JSON-RPC 是用 JSON 表达远程调用的消息协议，请求通过方法名指定操作，用 ID 对应响应。

一次工具调用从连接建立到结果返回，经过以下七个环节：

Client 发送 initialize，携带协议版本与客户端能力。
Server 返回支持的版本和服务端能力。
Client 确认版本兼容后，发送 notifications/initialized，表示初始化完成。版本无法兼容时，应结束连接。
Client 调用 tools/list，获取工具名称、描述和 inputSchema，后者定义输入参数的结构。
Host 把选定工具转换成模型 API 的工具定义，加入模型请求。
模型提出工具调用后，Host 找到对应 Client，由它发送 tools/call，携带工具名和参数。
Server 执行并返回结果，Host 再转换成模型接口要求的工具结果。返回内容可以是文本、图片或资源引用，模型据此继续处理任务。

tools/list 支持分页，Client 需要按游标继续读取，游标用于标记下一页的位置。Server 声明 listChanged 后，可以发送 notifications/tools/list_changed。Client 收到通知后重新拉取列表，才能发现新增、修改或移除的工具。

下面的请求查询订单 SO100，展示 tools/call 的消息结构：

{"jsonrpc":"2.0","id":7,"method":"tools/call",
 "params":{"name":"get_order","arguments":{"order_id":"SO100"}}}

响应中的 id=7 表示它对应这次 JSON-RPC 请求。这个 ID 用于 Client 与 Server 的通信，模型接口还有自己的调用 ID。因此，Host 要维护两者的对应关系，才能把结果交回正确的模型调用。

3.1 传输方式

传输方式决定协议消息怎样到达另一端。MCP 2025-11-25 提供 stdio 和 Streamable HTTP，分别适合本地进程通信和通过 HTTP 连接服务。

stdio 通过 Server 子进程的标准输入和标准输出交换消息。Host 启动子进程后，就可以在本机直接通信，这段传输无需经过网络。stdout 只能写协议消息，日志可写 stderr，否则 Client 会把日志误当成协议内容。子进程能访问哪些文件和服务，仍由启动配置与沙箱决定。

Streamable HTTP 使用单个 MCP 端点，也就是 Client 访问的服务地址。Client 用 POST 发送消息，响应可以是普通 JSON，也可以是 SSE。SSE 是服务端持续向客户端发送事件的数据流。Client 还可用 GET 建立服务端消息流；服务未提供该流时返回 405。

这种方式适合远程或多用户服务，也可以用于本机 HTTP 服务。2024-11-05 的 HTTP+SSE 则使用旧的双端点方案。新版传输仍能使用 SSE，因此看到 SSE 时，要进一步区分使用的是哪种传输方案。

3.2 错误类型与会话恢复

调用失败时，要先确定失败发生在协议、工具执行还是传输层。这样才能判断应该修正请求、调整业务参数，还是恢复连接。

这三类错误使用不同的处理方式：

协议错误：例如工具名未知或方法不可用，通过 JSON-RPC error 返回，表示请求在协议处理时出了问题。
工具执行错误：例如日期格式错误、业务条件不满足或下游 API 失败，在结果中用 isError: true 表达。它仍是 tools/call 的结果，Host 可以把原因交给模型修正。
传输中断：连接断开只说明消息传输中断。此时工具已经执行到哪一步，需要另外确认，尤其要核对写入是否已完成。

使用 HTTP 会话时，Server 可以在初始化响应中返回 MCP-Session-Id。Client 后续请求携带这个 ID，还要携带协商得到的 MCP-Protocol-Version。带会话 ID 的请求收到 404，表示该会话已失效，Client 应重新初始化。

如果 Server 支持 SSE 消息恢复，Client 重连时可用 Last-Event-ID 提供最后收到的事件 ID。Server 据此重放遗漏的消息。但消息恢复只解决漏收响应的问题，重复写入仍要靠业务幂等处理。

副作用的确认与恢复见Agent 状态与持久化执行。

4. Function Calling 与 API 分工

必会卡 · MCP 和普通 API 调用、Function Calling 有什么区别？为什么 Agent 生态广泛采用 MCP？

一次工具调用可以同时使用 Function Calling、MCP 和业务 API。它们处在不同位置，分别解决模型表达请求、应用接入能力和服务执行操作的问题。

层次	职责
Function Calling	模型表达工具选择与参数
MCP	应用发现并调用外部能力
业务 API	服务执行具体业务操作

Function Calling 位于模型 API 层，应用把可调用工具的定义交给模型。MCP 位于 Host 与 Server 之间，工具定义由 Server 在运行时提供。业务 API 则位于服务与调用方之间，通过接口文档或 OpenAPI 描述功能和参数。

比如，Host 先从 MCP Server 获取工具定义，再用 Function Calling 让模型选择工具并填写参数。Host 随后通过 MCP 发起调用，Server 内部调用已有业务 API 完成操作。也就是说，MCP 统一的是发现、描述和调用方式，具体业务逻辑仍由服务实现。

这种统一可以减少 M×N 集成：如果 M 个应用分别接入 N 个服务，就需要维护大量逐对适配。应用和服务各自接入 MCP 后，可以复用共同的协议实现，减少专用代码。工具目录还能在运行时发现和更新。

复用仍要求双方的协议版本、能力和内容类型兼容。接入 MCP 也会增加进程通信或网络往返的开销，并带来第三方 Server 的信任管理成本。因此，设计时要同时考虑复用收益与调用成本。

5. 安全风险

必会卡 · Agent 调用 MCP 有哪些风险？MCP Server 应该如何鉴权？

接入 MCP Server 后，应用既会读取它的描述，也会把参数交给它执行。因此，安全检查要覆盖进入上下文的内容，以及实际的数据访问。

审核接入时，重点检查以下四类风险：

工具描述投毒：恶意 Server 在描述或结果中夹带指令，诱导模型泄露数据或调用其他工具。这些内容会进入上下文，因此要按外部输入处理。
动态变更：审核通过后，Server 又修改了工具定义。可以固定服务版本、记录定义的哈希，也就是用于检测内容变化的摘要值。定义变化时，重新检查访问范围和副作用。
过度权限：本地进程能访问过多目录，或远程令牌允许过多操作，都会扩大错误调用的影响。因此，应按需要限制权限。
数据外泄：模型把一个 Server 返回的敏感数据，放进另一个 Server 的调用参数，就会把数据传给新的接收方。执行前需要检查数据流向。

注入指令怎样影响模型，见提示注入。

采用 HTTP 授权时，MCP 使用 OAuth 2.1 框架，让 Client 用访问令牌证明获得的访问权限。Server 作为资源服务器，校验令牌的目标资源、有效期和权限范围。访问下游服务时，要使用为下游正确签发的凭据；规范禁止把收到的访问令牌直接透传给下游。

本地 HTTP 服务还需校验 Origin 请求头，确认请求来源，并限制监听地址。stdio 进程则应按最小权限启动，通过沙箱限制文件和网络访问。认证解决身份识别，具体工具和数据仍需逐次授权。

Host 应只接入审核过的 Server，按工具配置自动允许、需要确认和禁止，并记录调用。敏感操作按策略要求用户确认。具体授权与隔离方法见工具授权与执行沙箱。