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 快充协议,物理接口一样,传输协议可以不同。

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

typescript
// 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 CallingMCP
工具发现手动在代码里注册Server 自动列出所有工具
传输方式不限制,你自己写标准化 stdio / HTTP+SSE
错误处理无标准,各写各的标准错误码和消息格式
复用性每个 AI 重写一遍一个 Server 服务所有 AI

“换句话说,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 的设备,终于找到了通用的接口。

MCP 架构解密:那些你看不见的 Client 和 Server
实战教程大纲