MCP：AI 的“USB-C 接口”这个类比能说明什么

MCP 经常被说成 AI 的“USB-C 接口”。这个类比能快速说明一件事：AI 应用接外部工具时，需要一套统一的连接方式。

但从工程角度看，MCP 的重点并不只是“接上工具”。它更像一套给 Agent 使用外部能力的协议层，负责把工具、资源和提示能力以统一格式暴露给 AI 应用。

先给结论：

问题	MCP 的作用
工具太多，每个 AI 应用都要重复适配	用统一协议描述和调用工具
模型只会生成文本，缺少外部行动能力	通过 Host、Client、Server 把外部能力接进上下文
Function Calling 只解决模型侧调用格式	MCP 补上工具发现、工具描述、连接和资源访问
工具接入变简单后，安全风险会上升	权限、审计、参数校验和工具治理需要单独设计

一句话概括：MCP 解决的是 Agent 工具接入标准化。它适合做连接层，后面的权限、安全、失败处理和工具质量还要继续工程化。

MCP 解决的核心摩擦

Agent 要完成任务，常常需要调用外部系统。

比如让 Agent 分析一个项目，它可能需要：

• 读文件系统。
• 搜索代码。
• 查 GitHub Issue。
• 访问数据库。
• 调浏览器。
• 调内部 API。

如果没有统一协议，每个工具都要为不同 AI 应用单独适配。

Claude Desktop -> GitHub 适配器
Claude Desktop -> 文件系统适配器
Cursor -> GitHub 适配器
Cursor -> 文件系统适配器
内部 Agent -> GitHub 适配器
内部 Agent -> 文件系统适配器

工具和应用数量一多，就会变成典型的 N×M 适配问题。

MCP 想把这件事拆开：

AI Host
  -> MCP Client
    -> MCP Server
      -> 真实工具 / 数据源 / 外部系统

工具提供方只需要按 MCP Server 的方式暴露能力。AI 应用只要支持 MCP Client，就可以连接这些 Server。

这就是 USB-C 类比里最有价值的部分：减少重复适配，让工具有统一入口。

MCP 的三层角色

理解 MCP，先看三个角色。

角色	位置	作用
Host	AI 应用侧	承载用户交互、模型调用、上下文管理
Client	Host 内部	和某个 MCP Server 建立一条连接
Server	工具侧	暴露 Tools、Resources、Prompts

一个 Host 可以连接多个 Server。通常每个 Server 会对应一个 Client 连接。

Host
├─ Client A -> Filesystem Server
├─ Client B -> GitHub Server
└─ Client C -> Database Server

这样设计有一个好处：工具能力被拆到 Server 侧，Host 不需要把所有工具逻辑都写进主程序。新增一个工具，本质上是新增一个 MCP Server 或连接一个已有 Server。

Server 暴露的三类能力

MCP Server 不只暴露“函数”。它主要有三类能力：Tools、Resources、Prompts。

能力	作用	例子
Tools	可执行动作	读文件、查数据库、创建 Issue
Resources	可读取上下文	文件内容、数据库记录、项目文档
Prompts	可复用提示模板	代码审查模板、SQL 分析模板

其中最常被讨论的是 Tools。

一个 Tool 通常需要包含：

• 名称。
• 描述。
• 输入参数 Schema。
• 返回结果格式。

模型看到工具描述后，才能判断当前任务是否需要调用这个工具，以及参数应该怎么填。

一个简化的工具描述可以理解成这样：

{
  "name": "search_issues",
  "description": "Search GitHub issues by keyword",
  "inputSchema": {
    "type": "object",
    "properties": {
      "repo": { "type": "string" },
      "query": { "type": "string" }
    },
    "required": ["repo", "query"]
  }
}

这里的重点是 description 和 inputSchema。前者影响模型是否选这个工具，后者约束模型生成的参数。

一次 MCP 工具调用怎么走

把一次工具调用拆开，大概是这个流程：

1. Host 启动或用户触发任务
2. Client 连接 MCP Server
3. Host 获取 Server 暴露的工具列表
4. Host 把工具描述放进模型可见上下文
5. 模型决定调用哪个工具，并生成参数
6. Host 通过 Client 把调用请求发给 Server
7. Server 执行真实动作
8. Server 返回结果
9. Host 把结果放回上下文
10. 模型继续生成后续回答或下一步动作

这里有两个关键点。

第一，模型本身通常不直接访问外部系统。它生成的是“调用意图”和参数，真正执行动作的是 Host / Client / Server 这一层。

第二，工具返回结果会重新进入上下文。也就是说，工具输出会影响模型下一轮判断。这里也是后续安全问题的入口。

MCP 和 Function Calling 的关系

MCP 很容易和 Function Calling 混在一起。可以用一句话区分：

概念	更靠近哪一侧	解决什么问题
Function Calling	模型接口侧	模型如何表达工具调用
MCP	工具协议侧	工具如何被发现、描述、连接和执行

Function Calling 关注的是模型输出格式。比如模型生成一个结构化 JSON，表示要调用 search_issues，参数是 repo 和 query。

MCP 关注的是这个 search_issues 从哪里来、怎么被 Host 发现、参数 Schema 怎么提供、调用请求怎么发给真实工具、结果怎么返回。

可以这样理解：

MCP Server 暴露工具
-> Host 读取工具描述
-> Host 转成模型可用的工具定义
-> 模型通过 Function Calling 表达调用意图
-> Host 再通过 MCP Client 调用 Server

所以 MCP 和 Function Calling 不在同一层。Function Calling 是模型和 Host 之间的调用表达，MCP 是 Host 和外部工具之间的连接协议。

一个最小 MCP Server 长什么样

不同语言的 SDK 写法不一样，但最小 MCP Server 的思路基本一致：

1. 创建 Server
2. 注册工具
3. 写工具处理函数
4. 启动传输层

用伪代码表示：

const server = createMcpServer({
  name: "demo-server",
  version: "1.0.0"
});

server.tool(
  "read_file",
  {
    path: string()
  },
  async ({ path }) => {
    const content = await fs.readFile(path, "utf-8");
    return {
      content: [{ type: "text", text: content }]
    };
  }
);

server.listen(stdioTransport());

这里的 read_file 就是一个 Tool。Host 连接这个 Server 后，就能看到这个工具的名称、描述和参数要求。模型需要读文件时，Host 可以把调用请求交给这个 Server 执行。

真实项目里还会多出几层：

• 参数校验。
• 路径权限限制。
• 日志记录。
• 错误处理。
• 超时控制。
• 用户确认。

这些比“把工具注册出来”更重要。

传输方式：本地和远程是两种场景

MCP 可以用于本地工具，也可以用于远程服务。常见传输方式可以简单分两类：

类型	适合场景	特点
stdio	本地工具、本地脚本、桌面应用	简单，适合本地进程通信
HTTP / SSE	远程服务、团队共享服务	方便跨机器访问，需要鉴权和网络安全设计

本地 MCP Server 比较适合文件系统、命令行工具、开发环境插件。

远程 MCP Server 更适合团队共享工具，比如内部知识库、统一数据库查询服务、工单系统、监控系统。

传输方式会影响安全边界。本地 stdio 更像 Host 启动一个受控子进程；远程 Server 要考虑认证、授权、网络暴露、租户隔离和审计。

MCP 的好处在哪里

MCP 的好处可以拆成四点。

1. 工具接入标准化。

工具用统一方式描述能力，Host 用统一方式发现和调用工具，重复适配成本会下降。

2. 工具体系更容易扩展。

新增工具时，可以新增 MCP Server，或者给已有 Server 增加 Tool。Host 主程序不需要塞满业务工具代码。

3. 工具生态更容易复用。

一个成熟的 GitHub Server、Filesystem Server、Database Server，可以被多个支持 MCP 的应用使用。

4. Agent 能力边界更清楚。

工具变成外部能力后，哪些能力来自模型，哪些能力来自工具，会更容易区分。

这一点很重要。很多时候 Agent 看起来“更聪明”，其实是它拿到了更好的工具、更稳定的上下文和更清楚的执行反馈。

MCP 的风险在哪里

MCP 把工具接入变简单后，风险也会变集中。

风险	表现	工程处理
权限过大	工具能读写敏感文件或数据库	最小权限、白名单、用户确认
工具描述污染	描述中夹带影响模型行为的内容	工具审核、描述规范、隔离来源
返回内容污染	外部网页或文档影响模型下一步判断	上下文过滤、结果摘要、来源标记
参数不可信	模型生成危险参数	Schema 校验、业务校验、二次确认
缺少审计	调用链路无法追踪	记录调用者、参数、结果、时间
失败不可控	工具超时、报错、部分成功	超时、重试、失败状态标准化

最容易被低估的是工具描述和返回内容。

模型会读取工具描述，工具返回结果也会进入上下文。只要内容进入上下文，它就有机会影响模型后续判断。所以 MCP Server 接入后，还需要一套工具治理规则。

什么时候适合用 MCP

MCP 适合放在工具数量多、复用需求强、接入方多的地方。

适合的场景：

• 一个 Agent 平台要接很多内部工具。
• 多个 AI 应用要共用同一批工具。
• 工具来自文件系统、数据库、浏览器、代码仓库等不同来源。
• 团队希望把工具接入做成统一标准。
• 后续工具会持续增长。

轻量场景可以先用更简单的方式：

• 单个脚本能解决的本地任务。
• 只有一两个固定 API 的小功能。
• 只在一个应用内部使用的能力。
• 风险很高、每次都需要人工确认的写操作。

这种场景里，CLI、普通 API 封装、内部 Tool Call 可能更直接。

我会把 MCP 放在“连接层”判断。它适合解决工具标准化接入，适合做生态入口。它不负责替代权限系统、任务流程、业务校验和人工确认。

我的判断

MCP 的价值很清楚：它把 Agent 接外部工具这件事标准化了。

对开发者来说，这意味着工具可以按 MCP Server 的形式沉淀下来，AI 应用通过统一 Client 接入。工具数量上来以后，这个价值会越来越明显。

但 MCP 的含金量不在“支持 MCP”四个字上，而在 Server 质量。

一个好的 MCP Server 至少要处理这些事：

• 工具描述清楚。
• 参数 Schema 明确。
• 权限边界收紧。
• 错误返回稳定。
• 调用过程可审计。
• 高风险动作有确认机制。

接口标准化只是第一步。真正决定可用性的，是工具治理。

所以我会这样看 MCP：

层面	判断
概念层	它是 Agent 接外部工具的标准协议
工程层	它适合做 Host 和工具之间的连接层
生态层	它有机会成为 AI 应用共享工具的入口
风险层	它会放大权限、安全、审计和工具质量问题

USB-C 这个类比可以帮助理解 MCP 的入口价值。继续往下看，MCP 更像 Agent 工程里的工具总线。工具能被统一接入，接入之后的权限、校验、审计、失败处理，才是生产环境里真正要补上的部分。