MCP 是什么？——AI 时代的"USB-C"统一接口协议

你有没有经历过这样的场景：你给 ChatGPT 写了一个插件，想在 Claude 上用——用不了。你在 LangChain 里封装了一个工具，换个框架——又得重写一遍。

每个 AI 平台都有自己的工具接入方式，互不兼容。这就像 2012 年之前的手机充电器——苹果用 Lightning，安卓用 Micro USB，三星还搞过自己的接口，出门得带一堆线。

2024 年 11 月 25 日，Anthropic 开源了 MCP（Model Context Protocol，模型上下文协议）——一个连接 AI 模型与外部工具的开放标准协议。

它的野心很明确：成为 AI 领域的 USB-C。

"MCP is an open standard for connecting AI assistants to the systems where data lives — including content repositories, business tools, and development environments."

（MCP 是一个开放标准，用于将 AI 助手连接到数据所在的系统——包括内容仓库、业务工具和开发环境。）

—— Anthropic 官方公告, 2024年11月25日

1. 为什么需要 MCP？

1.1 M×N 问题

假设市面上有 M 个 AI 模型（GPT、Claude、Gemini、Llama……）和 N 个工具/数据源（GitHub、Notion、Slack、数据库……）。

如果每个模型都要单独适配每个工具，总共需要 M × N 个集成方案。3 个模型 × 5 个工具 = 15 种适配。随着模型和工具数量增长，这个数字会爆炸式膨胀。

MCP 的解法是：在中间加一层标准协议。

每个工具只需要实现一次 MCP Server（N 个）
每个 AI 平台只需要实现一次 MCP Client（M 个）
总适配量从 M × N 降为 M + N

这就像 USB-C 统一了充电接口：手机厂商只需要做一个 USB-C 口，配件厂商只需要做一根 USB-C 线，而不是每家适配每家。

1.2 现状有多乱？

在 MCP 之前，各家的工具接入方式完全不同：

平台	工具接入方式	问题
OpenAI	Function Calling + GPTs	与 OpenAI API 深度绑定
Claude	Tool Use API	与 Anthropic API 绑定
LangChain	自定义 Tool 抽象	只在 LangChain 生态内通用
各种 Agent 框架	各自封装	互不兼容，重复造轮子

你写了一个"查询天气"的工具，在 OpenAI 的 Function Calling 里能用，但想给 Claude 用就得重写适配层。这不仅浪费开发者时间，也限制了 AI 工具生态的发展。

2. MCP 是怎么工作的？

2.1 三个核心角色

MCP 的架构非常简洁，就三个角色：

Host（宿主） 就是你正在使用的 AI 应用。比如 Claude Code、Claude Desktop、Cursor、甚至 ChatGPT Desktop。它是用户直接交互的界面。

Client（客户端） Host 内部维护的 MCP 连接器，负责跟 MCP Server 通信。一个 Host 可以同时连接多个 Server——就像你的电脑可以同时插多个 USB 设备。

Server（服务端） 提供具体能力的服务。比如一个图片生成服务、一个 GitHub 操作服务、一个数据库查询服务。每个 Server 可以提供三种能力：

Tools（工具）：AI 可以调用的函数。比如 generate_image(prompt)、search_files(query)
Resources（资源）：AI 可以读取的数据。比如文件内容、数据库记录、API 响应
Prompts（提示模板）：预定义的交互模板。比如"代码审查模板"、"翻译模板"

用一个日常比喻来说：

Host 就像你的手机，Client 就像手机上的 USB-C 接口，Server 就像各种 USB-C 配件（充电器、硬盘、显示器）。接口标准统一了，什么配件插上去都能用。

2.2 通信机制：JSON-RPC 2.0

MCP 使用 JSON-RPC 2.0 作为通信协议。如果你了解 Web 开发，可以把它理解为一种轻量级的远程过程调用——Client 发一个 JSON 请求，Server 返回一个 JSON 响应。

一个典型的工具调用流程：

text

1. Client → Server: "你有哪些工具？"（tools/list）
2. Server → Client: "我有 generate_image 和 list_models"
3. Client → Server: "调用 generate_image，参数是 {prompt: '一只猫'}"
4. Server → Client: "生成完毕，图片 URL 是 http://..."

2.3 两种传输方式

MCP 支持两种传输层：

stdio（标准输入输出） Server 作为一个本地进程运行，通过 stdin/stdout 和 Client 通信。适合本地工具，启动快、延迟低。比如 Claude Code 连接本地的文件系统工具。

Streamable HTTP Server 作为一个 HTTP 服务运行，Client 通过 HTTP 请求通信。适合远程服务，可以部署在服务器上供多个 Client 共享。比如一个部署在云端的图片生成服务。

3. MCP vs Function Calling：有什么区别？

很多人会问：OpenAI 不是已经有 Function Calling 了吗？为什么还需要 MCP？

这两者解决的问题不在一个层面上：

维度	Function Calling	MCP
定位	单次 API 调用中的工具定义	跨平台的标准协议
绑定	绑定特定 AI 平台（如 OpenAI）	平台无关，任何 AI 都能用
复用	换平台需要重写	写一次，到处用
发现	需要手动定义工具列表	Server 自动暴露能力，Client 动态发现
状态管理	无状态，每次调用独立	支持会话状态，工具间可以共享上下文
适用场景	简单应用、快速原型	复杂 Agent、多工具协作、生产环境

简单说：Function Calling 是"告诉模型可以调什么函数"，MCP 是"定义模型和工具之间怎么沟通"。

Function Calling 就像你在餐厅点菜时跟服务员说"我要宫保鸡丁"——这是一次性的交互。MCP 则像是定义了整个餐厅的服务规范——菜单怎么展示、怎么下单、怎么上菜、怎么结账，而且这套规范任何餐厅都能用。

4. MCP 生态现状

MCP 发布仅一年多，生态增长速度远超预期。

4.1 数字说话

5800+ 个 MCP Server 已注册
300+ 个 MCP Client 已支持
MCP Registry 自 2025 年 9 月上线以来，增长了 407%

4.2 巨头入场

MCP 最值得关注的一点是：它不只是 Anthropic 自己在玩。

2025 年 3 月：OpenAI 宣布在 Agents SDK、Responses API 和 ChatGPT Desktop 中全面支持 MCP
2025 年：Google DeepMind、Hugging Face、LangChain 等纷纷接入
2025 年 12 月：Anthropic 将 MCP 捐赠给 Linux 基金会旗下的 Agentic AI Foundation（AAIF），OpenAI 和 Block 作为联合创始成员加入，AWS、Google、Microsoft、Cloudflare 等作为支持成员

MCP was donated to the newly formed Agentic AI Foundation (AAIF) under the Linux Foundation, with OpenAI and Block joining as co-founders.

（MCP 被捐赠给了 Linux 基金会旗下新成立的 Agentic AI 基金会，OpenAI 和 Block 作为联合创始成员加入。）

—— Wikipedia: Model Context Protocol

这意味着 MCP 已经从 Anthropic 的"自家项目"变成了行业标准。就像 HTTP 协议不属于任何一家公司一样，MCP 也在走同样的路。

4.3 知名 MCP Server

目前生态中已有大量实用的 MCP Server：

Server	提供的能力
GitHub	仓库管理、PR 操作、Issue 处理
Notion	笔记读写、数据库查询
Stripe	支付流程自动化
Slack	消息发送、频道管理
Hugging Face	模型搜索、数据集浏览
Postman	API 测试自动化
PostgreSQL / MySQL	数据库查询
Puppeteer	浏览器自动化
Figma	设计稿读取和代码生成

而且任何人都可以写自己的 MCP Server。比如本博客在写作过程中用到的 image-service，就是一个自定义的 MCP Server——它封装了图片生成 API，让 Claude Code 能直接调用来生成博客配图。

5. 怎么写一个 MCP Server？

说了这么多，MCP Server 到底怎么写？其实比你想象的简单。

5.1 最小示例（Python）

python

from mcp.server.fastmcp import FastMCP

# 创建一个 MCP Server
mcp = FastMCP("my-tools")

# 定义一个工具
@mcp.tool()
def add(a: int, b: int) -> int:
    """两个数字相加"""
    return a + b

# 定义一个资源
@mcp.resource("greeting://{name}")
def get_greeting(name: str) -> str:
    """获取问候语"""
    return f"Hello, {name}!"

# 启动
if __name__ == "__main__":
    mcp.run()

就这么简单——用 @mcp.tool() 装饰器标记函数，它就变成了一个可供 AI 调用的工具。函数的参数类型和文档字符串会被自动暴露给 Client，AI 根据这些信息决定什么时候调用、传什么参数。

5.2 TypeScript 版本

typescript

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "my-tools", version: "1.0.0" });

// 定义工具
server.tool("add", { a: z.number(), b: z.number() }, async ({ a, b }) => ({
  content: [{ type: "text", text: String(a + b) }],
}));

// 启动
const transport = new StdioServerTransport();
await server.connect(transport);

5.3 接入到 Claude Code

写好 Server 后，在 Claude Code 的 MCP 配置中添加即可：

stdio 模式（本地进程）：

json

{
  "mcpServers": {
    "my-tools": {
      "command": "python",
      "args": ["my_server.py"]
    }
  }
}

HTTP 模式（远程服务）：

json

{
  "mcpServers": {
    "image-service": {
      "type": "url",
      "url": "http://localhost:8090/mcp"
    }
  }
}

两种方式的区别：stdio 适合本地轻量工具，HTTP 适合部署在服务器上的远程服务（比如本博客用到的图片生成服务）。

重启 Claude Code，你的工具就能被 AI 调用了。

6. MCP vs Skills：别搞混了

如果你用过 Claude Code，可能会注意到它除了 MCP，还有一个叫 Skills 的概念。两者很容易混淆，但其实完全不同：

维度	MCP	Skills
本质	连接外部工具的协议	内置的知识/行为指南
类比	手和脚——执行能力	大脑经验——知识和规范
形式	运行中的服务进程	纯文本文件（SKILL.md）
作用	让 AI 能调用外部 API、数据库、服务	让 AI 知道怎么做某类任务
加载方式	启动时连接，实时通信	按需读取，渐进式加载
举例	image-service（生成图片）、GitHub（操作仓库）	blog-write（写博客的流程规范）

用一个实际的例子来说明：

这篇博客的写作过程中，两者同时在工作：

MCP（image-service） 负责实际生成图片——调用 Gemini API、返回图片 URL
Skill（blog-write） 负责告诉 AI 应该用什么风格生成图片、文章怎么排版、图片放哪里、怎么提交

简单记：MCP 给了 AI "做事的能力"，Skills 给了 AI "做事的方法论"。 两者配合使用，才能让 AI 既知道怎么做，又有能力去做。

7. MCP 的局限与挑战

MCP 虽然发展迅速，但也面临一些挑战：

6.1 安全性

MCP Server 本质上是在给 AI 开放系统权限——读文件、写数据库、调 API。如果 Server 实现不当，可能导致：

越权访问：AI 操作了不该操作的数据
注入攻击：恶意 prompt 通过工具执行危险操作
数据泄露：敏感信息通过 MCP 通道暴露

目前社区正在制定更完善的安全规范和认证机制。

6.2 标准化仍在进行中

MCP 协议本身还在快速迭代，某些 API 可能会有 breaking change。对于生产环境来说，需要关注版本兼容性。

6.3 性能开销

相比直接的 Function Calling，MCP 多了一层协议和通信开销。对于延迟敏感的场景，需要评估这个开销是否可接受。

8. MCP 对 AI 行业意味着什么？

站在更高的视角看，MCP 的出现标志着 AI 行业进入了基础设施标准化的阶段。

回顾互联网的发展：

HTTP 统一了网页的通信方式 → 催生了整个 Web 生态
REST API 统一了服务间的接口规范 → 催生了微服务和 SaaS 生态
USB-C 统一了设备连接方式 → 催生了配件生态

MCP 正在做同样的事——统一 AI 与工具之间的通信方式。当这个标准足够成熟，我们可能会看到：

AI 助手可以像安装"插件"一样，随时接入新的能力
企业只需要发布 MCP Server，就能让所有 AI 平台使用自家的服务
开发者可以专注于构建工具本身，而不用为每个 AI 平台写适配层

总结

回顾一下 MCP 的核心要点：

是什么：AI 模型与外部工具之间的统一通信协议，就像 USB-C 统一了充电接口
为什么需要：解决 M×N 适配问题，写一次工具，所有 AI 平台都能用
怎么工作：Host-Client-Server 三层架构，JSON-RPC 通信，支持 stdio 和 HTTP 两种传输
vs Function Calling：FC 是单平台的工具定义，MCP 是跨平台的协议标准
生态现状：5800+ Server，OpenAI/Google/Microsoft 等巨头已入场，已捐赠给 Linux 基金会
怎么用：写一个 MCP Server 只需要几十行代码

如果你是 AI 应用开发者，MCP 值得现在就关注和投入。当年 HTTP 刚出来的时候，也没人想到它会成为整个互联网的基石。

2024 年 11 月 25 日，Anthropic 开源了 MCP（Model Context Protocol，模型上下文协议）——一个连接 AI 模型与外部工具的开放标准协议。

它的野心很明确：成为 AI 领域的 USB-C。

"MCP is an open standard for connecting AI assistants to the systems where data lives — including content repositories, business tools, and development environments."

（MCP 是一个开放标准，用于将 AI 助手连接到数据所在的系统——包括内容仓库、业务工具和开发环境。）

—— Anthropic 官方公告, 2024年11月25日

1. 为什么需要 MCP？

1.1 M×N 问题

假设市面上有 M 个 AI 模型（GPT、Claude、Gemini、Llama……）和 N 个工具/数据源（GitHub、Notion、Slack、数据库……）。

MCP 的解法是：在中间加一层标准协议。

每个工具只需要实现一次 MCP Server（N 个）
每个 AI 平台只需要实现一次 MCP Client（M 个）
总适配量从 M × N 降为 M + N

这就像 USB-C 统一了充电接口：手机厂商只需要做一个 USB-C 口，配件厂商只需要做一根 USB-C 线，而不是每家适配每家。

1.2 现状有多乱？

在 MCP 之前，各家的工具接入方式完全不同：

平台	工具接入方式	问题
OpenAI	Function Calling + GPTs	与 OpenAI API 深度绑定
Claude	Tool Use API	与 Anthropic API 绑定
LangChain	自定义 Tool 抽象	只在 LangChain 生态内通用
各种 Agent 框架	各自封装	互不兼容，重复造轮子

2. MCP 是怎么工作的？

2.1 三个核心角色

MCP 的架构非常简洁，就三个角色：

Host（宿主） 就是你正在使用的 AI 应用。比如 Claude Code、Claude Desktop、Cursor、甚至 ChatGPT Desktop。它是用户直接交互的界面。

Client（客户端） Host 内部维护的 MCP 连接器，负责跟 MCP Server 通信。一个 Host 可以同时连接多个 Server——就像你的电脑可以同时插多个 USB 设备。

Server（服务端） 提供具体能力的服务。比如一个图片生成服务、一个 GitHub 操作服务、一个数据库查询服务。每个 Server 可以提供三种能力：

Tools（工具）：AI 可以调用的函数。比如 generate_image(prompt)、search_files(query)
Resources（资源）：AI 可以读取的数据。比如文件内容、数据库记录、API 响应
Prompts（提示模板）：预定义的交互模板。比如"代码审查模板"、"翻译模板"

用一个日常比喻来说：

Host 就像你的手机，Client 就像手机上的 USB-C 接口，Server 就像各种 USB-C 配件（充电器、硬盘、显示器）。接口标准统一了，什么配件插上去都能用。

2.2 通信机制：JSON-RPC 2.0

一个典型的工具调用流程：

text

1. Client → Server: "你有哪些工具？"（tools/list）
2. Server → Client: "我有 generate_image 和 list_models"
3. Client → Server: "调用 generate_image，参数是 {prompt: '一只猫'}"
4. Server → Client: "生成完毕，图片 URL 是 http://..."

2.3 两种传输方式

MCP 支持两种传输层：

3. MCP vs Function Calling：有什么区别？

很多人会问：OpenAI 不是已经有 Function Calling 了吗？为什么还需要 MCP？

这两者解决的问题不在一个层面上：

维度	Function Calling	MCP
定位	单次 API 调用中的工具定义	跨平台的标准协议
绑定	绑定特定 AI 平台（如 OpenAI）	平台无关，任何 AI 都能用
复用	换平台需要重写	写一次，到处用
发现	需要手动定义工具列表	Server 自动暴露能力，Client 动态发现
状态管理	无状态，每次调用独立	支持会话状态，工具间可以共享上下文
适用场景	简单应用、快速原型	复杂 Agent、多工具协作、生产环境

简单说：Function Calling 是"告诉模型可以调什么函数"，MCP 是"定义模型和工具之间怎么沟通"。

4. MCP 生态现状

MCP 发布仅一年多，生态增长速度远超预期。

4.1 数字说话

5800+ 个 MCP Server 已注册
300+ 个 MCP Client 已支持
MCP Registry 自 2025 年 9 月上线以来，增长了 407%

4.2 巨头入场

MCP 最值得关注的一点是：它不只是 Anthropic 自己在玩。

2025 年 3 月：OpenAI 宣布在 Agents SDK、Responses API 和 ChatGPT Desktop 中全面支持 MCP
2025 年：Google DeepMind、Hugging Face、LangChain 等纷纷接入
2025 年 12 月：Anthropic 将 MCP 捐赠给 Linux 基金会旗下的 Agentic AI Foundation（AAIF），OpenAI 和 Block 作为联合创始成员加入，AWS、Google、Microsoft、Cloudflare 等作为支持成员

MCP was donated to the newly formed Agentic AI Foundation (AAIF) under the Linux Foundation, with OpenAI and Block joining as co-founders.

（MCP 被捐赠给了 Linux 基金会旗下新成立的 Agentic AI 基金会，OpenAI 和 Block 作为联合创始成员加入。）

—— Wikipedia: Model Context Protocol

这意味着 MCP 已经从 Anthropic 的"自家项目"变成了行业标准。就像 HTTP 协议不属于任何一家公司一样，MCP 也在走同样的路。

4.3 知名 MCP Server

目前生态中已有大量实用的 MCP Server：

Server	提供的能力
GitHub	仓库管理、PR 操作、Issue 处理
Notion	笔记读写、数据库查询
Stripe	支付流程自动化
Slack	消息发送、频道管理
Hugging Face	模型搜索、数据集浏览
Postman	API 测试自动化
PostgreSQL / MySQL	数据库查询
Puppeteer	浏览器自动化
Figma	设计稿读取和代码生成

5. 怎么写一个 MCP Server？

说了这么多，MCP Server 到底怎么写？其实比你想象的简单。

5.1 最小示例（Python）

python

from mcp.server.fastmcp import FastMCP

# 创建一个 MCP Server
mcp = FastMCP("my-tools")

# 定义一个工具
@mcp.tool()
def add(a: int, b: int) -> int:
    """两个数字相加"""
    return a + b

# 定义一个资源
@mcp.resource("greeting://{name}")
def get_greeting(name: str) -> str:
    """获取问候语"""
    return f"Hello, {name}!"

# 启动
if __name__ == "__main__":
    mcp.run()

5.2 TypeScript 版本

typescript

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "my-tools", version: "1.0.0" });

// 定义工具
server.tool("add", { a: z.number(), b: z.number() }, async ({ a, b }) => ({
  content: [{ type: "text", text: String(a + b) }],
}));

// 启动
const transport = new StdioServerTransport();
await server.connect(transport);

5.3 接入到 Claude Code

写好 Server 后，在 Claude Code 的 MCP 配置中添加即可：

stdio 模式（本地进程）：

json

{
  "mcpServers": {
    "my-tools": {
      "command": "python",
      "args": ["my_server.py"]
    }
  }
}

HTTP 模式（远程服务）：

json

{
  "mcpServers": {
    "image-service": {
      "type": "url",
      "url": "http://localhost:8090/mcp"
    }
  }
}

两种方式的区别：stdio 适合本地轻量工具，HTTP 适合部署在服务器上的远程服务（比如本博客用到的图片生成服务）。

重启 Claude Code，你的工具就能被 AI 调用了。

6. MCP vs Skills：别搞混了

如果你用过 Claude Code，可能会注意到它除了 MCP，还有一个叫 Skills 的概念。两者很容易混淆，但其实完全不同：

维度	MCP	Skills
本质	连接外部工具的协议	内置的知识/行为指南
类比	手和脚——执行能力	大脑经验——知识和规范
形式	运行中的服务进程	纯文本文件（SKILL.md）
作用	让 AI 能调用外部 API、数据库、服务	让 AI 知道怎么做某类任务
加载方式	启动时连接，实时通信	按需读取，渐进式加载
举例	image-service（生成图片）、GitHub（操作仓库）	blog-write（写博客的流程规范）

用一个实际的例子来说明：

这篇博客的写作过程中，两者同时在工作：

MCP（image-service） 负责实际生成图片——调用 Gemini API、返回图片 URL
Skill（blog-write） 负责告诉 AI 应该用什么风格生成图片、文章怎么排版、图片放哪里、怎么提交

简单记：MCP 给了 AI "做事的能力"，Skills 给了 AI "做事的方法论"。 两者配合使用，才能让 AI 既知道怎么做，又有能力去做。

7. MCP 的局限与挑战

MCP 虽然发展迅速，但也面临一些挑战：

6.1 安全性

MCP Server 本质上是在给 AI 开放系统权限——读文件、写数据库、调 API。如果 Server 实现不当，可能导致：

越权访问：AI 操作了不该操作的数据
注入攻击：恶意 prompt 通过工具执行危险操作
数据泄露：敏感信息通过 MCP 通道暴露

目前社区正在制定更完善的安全规范和认证机制。

6.2 标准化仍在进行中

MCP 协议本身还在快速迭代，某些 API 可能会有 breaking change。对于生产环境来说，需要关注版本兼容性。

6.3 性能开销

相比直接的 Function Calling，MCP 多了一层协议和通信开销。对于延迟敏感的场景，需要评估这个开销是否可接受。

8. MCP 对 AI 行业意味着什么？

站在更高的视角看，MCP 的出现标志着 AI 行业进入了基础设施标准化的阶段。

回顾互联网的发展：

HTTP 统一了网页的通信方式 → 催生了整个 Web 生态
REST API 统一了服务间的接口规范 → 催生了微服务和 SaaS 生态
USB-C 统一了设备连接方式 → 催生了配件生态

MCP 正在做同样的事——统一 AI 与工具之间的通信方式。当这个标准足够成熟，我们可能会看到：

AI 助手可以像安装"插件"一样，随时接入新的能力
企业只需要发布 MCP Server，就能让所有 AI 平台使用自家的服务
开发者可以专注于构建工具本身，而不用为每个 AI 平台写适配层

总结

回顾一下 MCP 的核心要点：

是什么：AI 模型与外部工具之间的统一通信协议，就像 USB-C 统一了充电接口
为什么需要：解决 M×N 适配问题，写一次工具，所有 AI 平台都能用
怎么工作：Host-Client-Server 三层架构，JSON-RPC 通信，支持 stdio 和 HTTP 两种传输
vs Function Calling：FC 是单平台的工具定义，MCP 是跨平台的协议标准
生态现状：5800+ Server，OpenAI/Google/Microsoft 等巨头已入场，已捐赠给 Linux 基金会
怎么用：写一个 MCP Server 只需要几十行代码

如果你是 AI 应用开发者，MCP 值得现在就关注和投入。当年 HTTP 刚出来的时候，也没人想到它会成为整个互联网的基石。