MCP 协议详解——AI 应用的标准化连接层

发表于 更新于 分类于

本文为「AI Agent 技术系列」第 3 篇。Function Calling（第 2 篇）解决了”模型如何决定调用工具”，MCP 解决”工具如何被标准化接入”。

一、主题定义与背景

MCP 的正式定义

MCP 官方规范的定义 [1]：

“Model Context Protocol (MCP) 是一个开放协议，能够在 LLM 应用程序和外部数据源及工具之间实现无缝集成。无论您是构建 AI 驱动的 IDE、增强聊天界面，还是创建自定义 AI 工具，MCP 都提供了标准化的连接方式。”

USB-C 类比：从 N×M 到 N+M

1
2
3
4
5
6
7
传统模式（N×M 集成）：
  N 个 AI 应用 × M 个工具 = N×M 个集成接口
  每个工具为每个 AI 应用单独开发连接

MCP 模式（N+M 集成）：
  N 个 AI 应用 → MCP 协议 ← M 个工具
  一次对接，处处可用

就像 USB-C 让充电这件事变得简单统一——一个标准协议，让 AI 连接所有数据源和工具。

提出背景

MCP 由 Anthropic 于 2024 年 11 月发布，旨在解决 AI 工具集成的碎片化问题。MCP 规范当前最新版本为 2025-11-25 [1]，已被 Claude、ChatGPT、VS Code、Cursor 等主流 AI 应用和开发工具采用。

二、核心技术原理与架构设计

2.1 三角色架构

graph TB
    subgraph Host主机
        H[AI 应用<br/>如 Claude / VS Code]
        C1[Client 1<br/>连接器]
        C2[Client 2<br/>连接器]
    end

    S1[MCP Server 1<br/>本地文件系统]
    S2[MCP Server 2<br/>远程数据分析]

    H --> C1
    H --> C2
    C1 <-->|MCP协议| S1
    C2 <-->|MCP协议| S2
角色 职责 示例
Host（主机） AI 应用本身，用户直接面对的程序，负责统筹多个连接 Claude Desktop、VS Code、Cursor
Client（客户端） 主机内部的”连接器”，每个客户端与一个服务器保持专用连接 主机内嵌入的 MCP Client 实例
Server（服务器） 提供数据或工具的程序，可运行在本地或云端 文件系统 Server、GitHub Server、数据库 Server

关键设计：一个 Host 可同时连接多个 Server——例如 VS Code 可以同时连接本地文件系统 Server 和远程数据分析 Server。

2.2 四步工作流程

sequenceDiagram
    participant H as Host (AI应用)
    participant C as Client
    participant S as Server

    H->>C: ① 发起连接
    C->>S: 建立 MCP 连接
    S-->>C: ② 发现：通知可用工具和数据
    C-->>H: 返回工具清单
    H->>C: ③ 调用：请求执行某工具
    C->>S: 转发调用请求
    S-->>C: 返回执行结果
    C-->>H: ④ 更新：数据变化通知
步骤 说明
① 连接 Host 通过 Client 连接到提供数据或工具的 Server
② 发现 Server 告诉 AI：”我有这些工具和数据，你可以使用它们”
③ 调用 AI 根据需要调用 Server 提供的功能，获取数据或执行操作
④ 更新 数据变化时，Server 实时通知 AI，保持信息同步

整个流程在后台自动完成，用户只需像平时一样使用 AI 助手。

2.3 三类核心原语

Server 通过三类原语为 LLM 提供上下文 [2]：

原语 控制方 描述 示例
Prompts（提示） 用户控制 预定义的提示模板，用户主动选择 “代码审查”提示模板
Resources（资源） 用户控制 可读取的数据源，类似 GET 端点 文件内容、数据库记录
Tools（工具） 模型控制 可执行的函数，类似 POST 端点 发送邮件、创建文件

关键区别：Prompts 和 Resources 由用户控制（用户决定何时使用），Tools 由模型控制（AI 自主决定何时调用）。

2.4 传输方式

MCP 2025-11-25 版本定义了两种标准传输方式 [3]：

传输方式 说明 适用场景
stdio 通过标准输入/输出通信 本地 Server（如文件系统访问）
Streamable HTTP 基于 HTTP 的流式传输，替代旧的 HTTP+SSE 远程 Server（如云端 API）

注意：在 MCP 协议 2025-11-25 版本中，Streamable HTTP 替代了之前版本（2024-11-05）中的 HTTP+SSE 传输方式 [3]。

三、实际应用场景与最佳实践

场景一：VS Code 连接本地文件系统 MCP Server

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// npm install @modelcontextprotocol/sdk

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { CallToolRequestSchema } from "@modelcontextprotocol/sdk/types.js";
import { readFile, writeFile } from "fs/promises";

const server = new Server(
  { name: "filesystem-server", version: "1.0.0" },
  { capabilities: { tools: {}, resources: {} } }
);

// 注册工具
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;

  switch (name) {
    case "read_file": {
      const content = await readFile(args.path, "utf-8");
      return { content: [{ type: "text", text: content }] };
    }
    case "write_file": {
      await writeFile(args.path, args.content);
      return { content: [{ type: "text", text: `已写入 ${args.path}` }] };
    }
  }
});

// 使用 stdio 传输
const transport = new StdioServerTransport();
await server.connect(transport);

场景二：企业 CRM 集成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// MCP Server：企业 CRM 查询
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { CallToolRequestSchema, ListToolsRequestSchema } from "@modelcontextprotocol/sdk/types.js";

const server = new Server(
  { name: "crm-server", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

// 注册工具列表
server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [{
    name: "query_customer",
    description: "查询客户信息",
    inputSchema: {
      type: "object",
      properties: {
        customer_id: { type: "string" },
      },
      required: ["customer_id"],
    },
  }],
}));

// 注册工具调用
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;

  if (name === "query_customer") {
    const customer = await crmDb.getCustomer(args.customer_id);
    return { content: [{ type: "text", text: JSON.stringify(customer) }] };
  }
});

安全最佳实践四原则

原则 说明 实践要点
信任但要验证 收到的令牌必须检查是否过期、是否确实发给你的 Server 每次请求验证 Token 有效性
最小权限 一开始只申请最少权限，需要更多时再临时申请 定期审查并撤销不必要的权限
安全通信 生产环境务必使用 HTTPS，绝不记录密码和令牌 拦截发往内网的请求（防 SSRF）
本地防护 安装 MCP Server 前确认来源可信 在沙箱中运行，执行操作前向用户展示具体命令

四、常见挑战与解决方案

六大安全威胁详解

威胁 说明 防御方案
冒充攻击 攻击者冒充已授权用户，利用系统记住的权限 Token 绑定到特定 session/context
令牌泄露 Server 把数字钥匙直接转手给别人，不检查合法性 每个新 session 要求 Token 更新 [4]
SSRF 攻击 恶意 Server 诱导 AI 访问不该访问的内部系统 拦截内网请求，限制出站目标
会话劫持 攻击者偷走对话 ID，冒充你与系统交互 Session ID 绑定 IP/设备指纹
本地入侵 安装了恶意 MCP Server，在电脑上搞破坏 沙箱运行 + 来源确认
权限过大 一次性申请太多权限，一旦泄露后果严重 最小权限原则 + 定期审查

工具投毒攻击（Tool Poisoning Attack）

2025 年 3 月，Invariant Labs 披露了一种新型攻击 [5]：

1
2
3
4
5
6
7
8
9
攻击原理：
1. 恶意 MCP Server 在工具描述中注入隐藏指令
2. AI 读取工具描述时，恶意指令被注入到上下文
3. AI 被诱导执行非预期操作（如泄露敏感数据）

防御方案：
- 工具描述签名验证
- 限制工具描述长度
- 对工具描述进行内容安全审查

OWASP 已发布 MCP Top 10 安全风险清单，其中 MCP01:2025 就是”令牌管理不当与密钥暴露” [4]。

OAuth 2.1 授权机制六步详解

flowchart LR
    A[① 询问身份<br/>Client尝试连接] --> B[② 获取清单<br/>Server告知授权位置]
    B --> C[③ 用户授权<br/>浏览器弹窗确认]
    C --> D[④ 登记注册<br/>Client注册身份标识]
    D --> E[⑤ 获取凭证<br/>颁发Token通行证]
    E --> F[⑥ 验证通行<br/>每次请求出示Token]

MCP 遵循 OAuth 2.1 标准——经过验证的行业安全方案，不是自己发明的”土办法” [1]。

步骤 说明
① 询问身份 客户端尝试连接，服务器要求”请先证明你是谁”
② 获取清单 服务器告诉客户端需要到哪里获取授权
③ 用户授权 浏览器弹出页面，用户确认”是的，我允许这个操作”
④ 登记注册 客户端在授权服务器上注册自己，获得身份标识
⑤ 获取凭证 授权服务器颁发”数字通行证”（Token）
⑥ 验证通行 每次请求都出示通行证，服务器验证是否有效

五、行业趋势与前沿进展

MCP 生态最新进展

截至 2026 年 6 月，MCP 生态快速扩张：

类别 支持的工具/平台
AI 应用 Claude Desktop、ChatGPT、其他智能助手
开发工具 VS Code、Cursor、Zed、Warp、JetBrains
企业系统 CRM、ERP、各类业务系统
开发框架 LangChain、AutoGen 等已集成 MCP 支持

“一次构建，处处集成”——开发者只需按 MCP 标准开发一次，就能在所有支持的平台上使用。

MCP 安全研究前沿

2025-2026 年，MCP 安全研究成为热点 [6][7]：

  • CVE 追踪：GitHub 上已有专门的 MCP CVE 项目，追踪已披露的 MCP 相关漏洞 [6]
  • 工具投毒攻击：Invariant Labs 2025 年 3 月披露，引发社区广泛关注 [5]
  • 传输层安全：stdio、SSE、Streamable HTTP 三种传输方式的安全差异被深入研究 [3]

最新安全建议 [7]：

  • 传输层选择：本地用 stdio（最安全），远程用 Streamable HTTP + HTTPS
  • Token 管理：每个 session 绑定独立 Token，不跨 session 复用
  • 工具描述审查：对第三方 Server 的工具描述进行安全扫描

MCP vs OpenAI Plugins vs Custom Tools

方案 定位 优势 劣势
MCP 开放标准协议 跨平台、跨应用通用 规范仍在演进中
OpenAI Plugins OpenAI 生态专用 与 ChatGPT 深度集成 仅限 OpenAI 生态
Custom Tools 自定义集成 完全可控 无法复用，开发成本高

趋势：MCP 正在成为 AI 领域的”通用语言”——它让不同的 AI 应用和不同的数据源能够互相理解、顺畅协作。

结论

MCP 的核心价值在于标准化——用一个协议替代无数个定制集成。对于技术决策者：

  1. 评估采用：如果你的 AI 应用需要连接 3 个以上外部系统，MCP 的标准化收益将超过学习成本
  2. 安全优先：MCP 的安全威胁是真实的——工具投毒、SSRF、令牌泄露都需要防御
  3. 关注演进：MCP 规范仍在快速迭代（2025-11-25 是当前最新版本），传输方式和安全机制都在演进

从 Function Calling（第 2 篇）到 MCP，工具集成正在从”各自为政”走向”标准统一”。

参考资料

[1] Model Context Protocol Specification (2025-11-25). 2025-11-25

[2] MCP Protocol Specification - Primitives

[3] MCP Transports 规范. 2025-11-25

[4] OWASP MCP Top 10 - MCP01:2025 Token Mismanagement. 2026-05-11

[5] MCP 工具投毒攻击（Tool Poisoning Attack）. 2025-09-13

[6] MCP CVE Project

[7] MCP Transport Security: STDIO, SSE, Streamable HTTP Risks. 2026-06-19