MCP 是什么?AI 应用的＂USB-C 接口＂

周五下午三点，老李把三份打印出来的 SDK 文档摔在桌上，保温杯震得咔咔响。

“我真是受够了，”他指着文档，“这家 AI 的插件系统用 JSON Schema，那家用 Python 函数装饰器，第三家更离谱，让我继承一个叫 BaseTool 的抽象类。同一个数据库查询工具，我给三家 AI 写了三套不同的代码。这跟十年前每家手机都有自己充电口有什么区别？”

小王从工位探过头来，扫了一眼那三份文档，嘴角浮起一丝“终于等到你问”的微笑：“老李，你还记得你那条抽屉里吃灰的诺基亚充电线吗？”

“记得啊，圆头的，只能充诺基亚。后来换三星又是一根，换 iPhone 又是 lightning。出差带一堆线，烦得要死。”

“后来呢？”

“后来全换成 USB-C 了嘛，一根线充手机、电脑、耳机。”

“MCP 就是这个意思。它想让所有 AI 应用和工具之间，都用同一根线。”

老李眉头一皱：“MCP？又是什么新缩写？不会是又一个要让我加班搞集成的玩意儿吧？”

“恰恰相反。它就是来解决你刚才抱怨的那个问题的。”

MCP 之前：AI 的“接口战国时代”

小王走到白板前，画了一堆乱七八糟的线。

“现在的 AI 生态，就像一个战国时代。OpenAI 有 Function Calling，Google 有 Vertex AI Extensions，开源的 LangChain 和 LlamaIndex 各有一套 Tool 定义规范。你想让 Claude 调用你的数据库，你得写一套代码。你想让 GPT 也调用同样的数据库，对不起，再写一套。哪怕底层逻辑一模一样，只是接口层不同。”

“这就是你刚才在干的事。”小王指了指那三份文档。

老李一脸无奈：“那 MCP 想干嘛？做统一标准？”

“对。Model Context Protocol，模型上下文协议。Anthropic 在 2024 年底开源出来的。它的核心承诺就一句——用同一种方式，连接任何 AI 应用和任何外部工具。”

图：MCP 之前，每家 AI 都需要单独对接；MCP 之后，一套 Server 服务所有 AI

三大核心概念：Client、Server、Transport

“MCP 的架构就三个东西，就像你用的 USB-C 生态一样。”小王在白板上写下三个词。

MCP Client：AI 应用这一侧。Claude Desktop、Zed 编辑器、Sourcegraph，这些是你“插线”的设备。它们都内置了 MCP Client，负责发起连接请求、发送查询、接收结果。就像你的手机、电脑，都带 USB-C 口。

MCP Server：工具和数据源这一侧。你的数据库、文件系统、API 服务，只要包一层 MCP Server，就变成了一个标准化的“外设”。就像 U 盘、显示器、充电器——它们都是 USB-C 设备，接到任何带 USB-C 口的电脑都能用。

Transport：Client 和 Server 之间的通信方式。目前支持两种——stdio（标准输入输出，适合本地进程间通信）和HTTP + SSE（适合远程连接）。就像 USB-C 线里跑的可以是 USB 3.2、雷电 4 或者 PD 快充协议，物理接口一样，传输协议可以不同。

“你看这个结构——”小王在屏幕上打开一段类型定义代码：

// MCP Server 的核心接口（简化示意）
interface MCPServer {
  // 列出这个 Server 提供的所有工具
  listTools(): Promise<Tool[]>;
  
  // 调用指定工具，传入参数，返回结果
  callTool(name: string, args: Record<string, unknown>): Promise<ToolResult>;
  
  // 列出可访问的资源（文件、数据库表等）
  listResources(): Promise<Resource[]>;
  
  // 读取指定资源的内容
  readResource(uri: string): Promise<ResourceContent>;
}

// 一个工具的定义
interface Tool {
  name: string;           // 工具名称，如 "query_database"
  description: string;    // 描述，让 AI 知道什么时候该用它
  inputSchema: object;    // 参数定义，JSON Schema 格式
}

“跟 Function Calling 的 JSON Schema 很像啊？”老李盯着 Tool 接口。

“语法像，但定位完全不同。”

MCP 和 Function Calling 的区别：不只是“调用函数”

“Function Calling 是 LLM 的一个能力——模型可以输出‘我想调用这个函数，参数是这些’。但谁来执行这个函数？函数的实现代码在哪？出错了怎么处理？这些 Function Calling 都不管。它只管‘表达意图’。”

小王接着说：“MCP 管的是全流程。Client 怎么发现 Server 上有哪些工具可用？Server 怎么声明自己的能力和限制？调用失败怎么返回标准化的错误信息？这些 Function Calling 不管的事，MCP 全定义了。”

他在白板上画了一个对比表：

“换句话说，Function Calling 定义的是 AI 和工具之间的‘对话格式’。MCP 定义的是整个‘通信系统’——包括发现、连接、传输、错误处理。就像 USB-C 不只定义了插头形状，还定义了供电协议、数据传输速率、甚至视频输出规范。”

老李沉默了几秒，忽然问：“那如果我有一个 MCP Server，是不是可以同时给 Claude 和 GPT 用？”

“理论上是的，只要它们都实现了 MCP Client。目前 Claude Desktop 原生支持，开源的 Zed 编辑器也接了，Sourcegraph 的 Cody 也在用。OpenAI 暂时还没官方支持，但社区已经有 GPT 的 MCP 桥接方案了。”

谁在用 MCP？

“这东西是 Anthropic 一家推的，会不会又是个‘Chromium 标准’——名义上开放，实际上只有一个人说了算？”老李的怀疑本能又上线了。

小王诚实地点头：“目前主要推手确实是 Anthropic，Claude Desktop 是最大的 MCP Client。但好处是协议本身是开源的，规范公开，社区可以自由实现。已经有不少第三方在做 MCP Server 了——”

他在屏幕上列了一串项目：“有数据库查询的 Server，连 MySQL、Postgres、SQLite 的；有文件系统操作的 Server，让 AI 安全地读写本地文件；有网页抓取的 Server，就是上次我们聊的浏览器 Agent 的标准化版本；甚至还有 Docker 管理的 Server，AI 可以直接启动和监控容器。”

“而且，”小王补充道，“最近一些云服务商开始直接提供 MCP 接口。你不需要自己部署 Server，直接连他们的云端 Server 就行。比如某数据库厂商最近刚发了 MCP 连接器，你一行代码不写，填个连接字符串就能让 Claude 直接查你的数据库。”

老李的眼神从怀疑变成了若有所思。他端起保温杯，枸杞在杯里打了几个转。

“嗯……还有点意思。”老李终于开口，“那我那三份 SDK 文档，能扔了吗？”

“短期内还扔不了。GPT 还没原生支持，开源模型那边也在推自己的标准。但你可以先把数据库查询这个最常用的工具，改成一个 MCP Server。Claude Desktop 立刻就能用，其他 AI 等它们支持了 MCP 也能接。”

老李站起来，把那三份文档理了理，塞进抽屉里。然后他转过身：“那什么，你说 stdio 和 HTTP 是两种 Transport，什么场景该用哪个？如果我的数据库在内网，AI 在云上，怎么安全地暴露 MCP Server？你给我讲讲那个鉴权机制。”

小王咧嘴笑了：“老李，你已经开始考虑生产部署了。行，我给你画 MCP 的安全架构——”

窗外的夕阳透过百叶窗打在屏幕上，那个画着 Client 和 Server 之间双向箭头的架构图，在余晖里闪闪发光。老李的保温杯搁在一旁，枸杞沉沉浮浮，像一个等待被插上 USB-C 的设备，终于找到了通用的接口。