MCP 协议详解：给 AI 装一个万能 USB-C 接口

为什么需要 MCP？

2024 年的 AI 世界有一个尴尬的现实：每个 AI 应用都在发明自己的轮子。

Claude 接了文件系统，GPT 连了数据库，本地开源的模型挂了个搜索引擎——但每家都是自己搓一套集成方案。开发者要对接 N 个 AI 平台，就得写 N 套代码。这就像你家有十个电器，每个都自带一根专属充电线，出门必须背一麻袋。

Anthropic 站了出来，说了一句大概相当于"我们要给 AI 搞一个 USB-C"的话，然后在 2024 年底开源了Model Context Protocol（MCP）。不是产品，不是框架，是一个协议——谁都可以实现它，谁都可能从它受益。

MCP 是什么？

官方定义：MCP 是一个开放标准，用于连接 AI 应用和外部系统。但这句话太正经了，我们来换个说法：

MCP 就是 AI 界的 USB-C。

想想 USB-C 做了什么：以前你买一根线只能充一台手机，现在一根线能充手机、笔记本、平板、耳机，甚至还能传数据、投屏幕。MCP 想对 AI 做同样的事情——让任何 AI 应用（Claude、ChatGPT、本地跑的小模型）都能用同一套标准接口，去连接任何数据源和工具。

具体来说，MCP 定义了三个核心角色的协作关系：

MCP Host：AI 应用本身，比如 Claude Desktop、VS Code Copilot、Cursor。它负责跟用户交互，但自己不做脏活累活。

MCP Client：Host 内部的一个连接器，每个 MCP Server 对应一个 Client。Client 负责跟 Server 聊天（通过 JSON-RPC）。

MCP Server：真正干活的东西。暴露文件系统、数据库、搜索引擎、Sentry、GitHub 等能力给 AI 用。一个 Server 专职干一类事。

这三者的关系可以简单理解为：Host 是老板，Client 是秘书，Server 是各个部门的专家。老板（Host）不直接跟专家沟通，秘书（Client）负责传话。

┌─────────────────────────────┐
│      MCP Host (AI App)      │
│  ┌─────────┐ ┌─────────┐   │
│  │Client 1 │ │Client 2 │…  │
│  └────┬────┘ └────┬────┘   │
└───────┼───────────┼────────┘
        │           │
  ┌─────▼──┐  ┌────▼─────┐
  │ Server │  │  Server  │
  │ Files  │  │ Database │
  └────────┘  └──────────┘

三大核心原语

MCP 给 Server 定义了三种能力，业界黑话叫"原语"（Primitives）。它们分别是：Tools（工具）、Resources（资源）、Prompts（提示模板）。理解这三样，就懂了 MCP 的 80%。

Tools：让 AI 动手

Tool 是可执行函数——AI 模型主动决定什么时候调用。比如查天气、搜航班、发邮件、创建日历事件。每个 Tool 有名字、描述和输入参数的 JSON Schema，AI 模型根据用户请求自主选择调用哪个。

举个栗子：你问"明天巴黎多少度"，AI 模型检索到一个 get_weather Tool，自动填入参数 location: "Paris", date: "tomorrow"，调用后把结果告诉你。全程不需要你手动点任何按钮。

{
  "name": "get_weather",
  "description": "获取任意城市的天气",
  "inputSchema": {
    "type": "object",
    "properties": {
      "location": { "type": "string" },
      "date": { "type": "string" }
    }
  }
}

Resources：让 AI 有知识

Resource 是只读数据源——文件内容、数据库记录、API 返回结果。不像 Tools 是 AI 主动调用，Resources 通常由应用层决定提供哪些给模型。

每个 Resource 有一个唯一 URI，比如 file:///docs/resume.md 或 database://schema/user。Server 还可以暴露 Resource Template，让你动态传参查询：

{
  "uriTemplate": "weather://forecast/{city}",
  "name": "weather-forecast",
  "description": "按城市查天气预报"
}

// 实际使用方式：
// weather://forecast/北京
// weather://forecast/Tokyo

Tools vs Resources 的直觉区分：Resources 是"只读的知识"，Tools 是"能动的操作"。Resources 告诉 AI 世界是什么样，Tools 让 AI 改变世界。

Prompts：给 AI 一个剧本

Prompt 是预定义的模板——告诉 AI"当用户想做这件事时，应该按什么步骤来"。它与普通的系统提示词不同，它是用户显式触发的，通常配合资源和工具一起使用。

比如一个"规划旅行"的 Prompt，它会定义参数（目的地、天数、预算），然后 Server 实现这个 Prompt，让 AI 结合用户的日历资源、天气工具、航班搜索工具，一步步完成规划。

{
  "name": "plan-vacation",
  "description": "帮你规划一场旅行",
  "arguments": [
    { "name": "destination", "type": "string", "required": true },
    { "name": "days", "type": "number", "description": "天数" },
    { "name": "budget", "type": "number" }
  ]
}

一句话总结三者的分工：

架构与通信：MCP 到底怎么跑起来的？

MCP 的通信基于JSON-RPC 2.0——一个轻量级的远程调用协议。简单说就是 Client 和 Server 互相发 JSON 格式的请求和响应，谁都能看懂。

生命周期：先握手，再干活

Client 和 Server 建立连接后，第一件事不是干活，而是握手（Initialize）。双方互相亮明身份：

• Client 说："我支持协议版本 X，我有这些能力（比如支持用户交互 Elicitation）"
• Server 说："我也支持协议版本 X，我有这些能力（比如 Tools 支持变更通知）"

握手完成后，Client 发一条 notifications/initialized 通知，表示"好了，正式开工"。之后双方就可以愉快地发请求、收响应、互相通知了。

传输层：本地还是远程？

MCP 支持两种传输方式：

STDIO（本地）：Server 作为子进程运行，通过标准输入输出通信。延迟低、不占网络，适合文件系统、本地数据库等场景。Claude Desktop 启动本地 Server 就用这个。

Streamable HTTP（远程）：基于 HTTP POST + Server-Sent Events。Server 跑在远端，支持 OAuth 认证。适合像 Sentry、GitHub 这样的云服务。一台远程 Server 可以服务多个 Client。

有意思的是，传输层的差异对数据层完全透明。无论 Server 是本地进程还是远在天边的 API，Client 用的 JSON-RPC 消息格式完全一样。这就是"分层"的好处：底层随便换，上层不感知。

通知机制：Server 也可以主动说话

MCP 支持 Server 向 Client 推送通知。比如 Server 的 Tool 列表变了（新增了工具或下架了旧的），它可以发送 notifications/tools/list_changed 通知。Client 收到后自动重新拉取最新列表。

这避免了"客户端定期轮询"这种又蠢又费电的做法。用工程师的话说：不要问，等通知。

客户端与服务端的双向奔赴

很多人以为 MCP 只是"Server 提供能力给 Client 用"。实际上 MCP 是双向的——Server 也可以反过来向 Client 请求东西。这就是 MCP 的客户端原语：Elicitation（用户交互）、Sampling（模型采样）、Roots（根目录）。

Elicitation：Server 也能问用户要信息

想象一个订酒店的 Server，它把所有航班和酒店都查好了，但就差你一句确认。传统做法是：Server 返回"请用户确认"，Client 再想办法弹窗。MCP 的 Elicitation 把这个过程标准化了。

Server 发一个 elicitation/create 请求，附上 JSON Schema 描述它需要哪些信息（确认、座位偏好、房型选择等）。Client 收到后在界面上展示给用户。用户填完，Client 把结果返回 Server。

这个机制让 Server 可以做需要人类介入的决策，而不用自己硬猜。再也不用担心 AI 擅自替你订了头等舱。

Sampling：Server 也能找 AI 帮忙

有时候 Server 也需要"AI 思考"一下。比如一个航班推荐 Tool 查到了 47 个航班，它自己不会分析哪个最好。这时它可以发起 Sampling 请求，让 Client 调用大模型帮它分析。

流程是这样的：Server 请求采样 → Client 展示给用户审批 → 用户同意 → Client 调 LLM → 结果返回给 Server。每一步都可以加入人工审核，保证安全。

Roots：告诉 Server 你的地盘在哪

Roots 是 Client 告诉 Server"你的活动范围"的机制。比如你在 VS Code 里打开了一个项目文件夹，Client 会把 file:///Users/you/project 作为 Root 告诉文件 Server。

这不是安全边界（Server 真要越界你也拦不住），而是上下文提示——让 Server 知道该关注哪些目录，不要在无关的文件里翻来翻去。就像一个实习生刚入职，你先告诉他"你的工位在这片区域"，而不是让他满公司乱窜。

为什么 MCP 很重要？

MCP 不是第一个做 AI 工具集成的尝试。Function Calling、Plugin、Tool Use 这些概念早就有了。MCP 的不同之处在于：它在做"去中心化的标准化"。

1. 一次开发，到处运行。 你写一个 MCP Server（比如查天气），Claude 能用、ChatGPT 能用、VS Code Copilot 能用、Cursor 能用。不用为每个平台写一套适配器。这对工具开发者是巨大的效率提升。

2. 开源协议，非商业绑定。 MCP 是开放的，不属于任何一家公司。Anthropic 发起了它，但任何人都可以实现和扩展。这避免了"我的插件只能在你的平台跑"的生态锁死。

3. 分层设计，灵活部署。 数据层和传输层分离。同一个 Server 可以本地跑（STDIO）也能远程部署（HTTP）。开发者不需要关心底层通信细节，SDK 全包了。

4. 双向通信，闭环能力。 不只是 Client 调用 Server，Server 也能请求 Client。这让 Server 可以做更复杂的交互——需要用户确认时请求 Elicitation，需要 AI 分析时请求 Sampling。

目前 MCP 已经在广泛生态中得到支持：

MCP 的设计哲学：它是怎么想问题的？

看了这么多技术细节，我们来聊聊 MCP 背后的设计理念。官方文档里提到了几条核心原则，我们用大白话翻译一下：

原则一：简单到可以轻松实现。 MCP 基于 JSON-RPC，没有花哨的二进制协议，没有复杂的握手流程。一个 Python 文件就能写一个 Server。门槛越低，生态越大。

原则二：可组合，不捆绑。 一个 Server 只做一件事，多个 Server 一起工作。你的旅行 Agent 可以同时接天气 Server + 航班 Server + 日历 Server，各司其职。MCP 不搞全家桶。

原则三：增量演进，不搞大爆炸。 协议版本通过初始化协商兼容，老 Server 不用改也能跟新 Client 通信。你不需要"升级到 MCP 2.0 全部重写"这种噩梦。

原则四：安全是一等公民。 所有 Tools 调用默认不是"直接执行"，Client 可以弹窗让用户确认才放行。Sampling 请求也经过用户审核。MCP 的设计前提是"AI 可能会犯傻，人类得兜底"。

原则五：不求包罗万象，但求解决真问题。 MCP 只定义协议，不规定你怎么用 LLM、怎么处理上下文、怎么实现 AI 应用。它专注于一件事——让 AI 和外部世界通信——然后把它做好。

面试常考：几个关键判断

Q: MCP 和 Function Calling 有什么区别？
Function Calling 是单个 AI 模型调用自己平台函数的机制，是私有的。MCP 是开放协议，任何 AI 平台都可以实现，任何工具提供商都可以接入。你做了一个 MCP Server，全网 AI 都能用。

Q: MCP 是不是只能用在 Claude 上？
不是。MCP 是开放的，ChatGPT、Copilot、Cursor 都已经支持。它属于整个 AI 生态，不属于任何一家公司。

Q: 写一个 MCP Server 难吗？
不难。官方提供 Python、TypeScript、Java、Kotlin 的 SDK。一个简单的文件读取 Server 大概 50 行代码就能跑起来。

Q: MCP 能保证安全吗？
协议层面提供了 Elicitation 让用户审核、Roots 让 Server 知道范围。但最终安全取决于实现——Client 是否弹窗让用户确认、Server 是否遵守边界。协议本身不做安全强制执行，它给你工具，你要自己用。

Q: MCP 会不会被其他协议取代？
有可能。但 MCP 是目前最被广泛采用的开放标准。Anthropic 把它捐给了社区，成立了工作组和 SIG（特别兴趣小组）来共同治理。一个协议的生命力取决于生态，MCP 的生态正在快速壮大。

彩蛋

MCP 的 Logo 是一个插头。是的，就是那种你每天都要用到、但永远找不到正反面的 USB 插头（虽然 USB-C 已经解决了这个问题）。

这个 Logo 完美传达了 MCP 的核心理念："插上就能用"。不用读手册、不用写适配器、不用烧香拜佛——只要你的程序实现了 MCP，它就能跟任何 AI 应用对话。

更有意思的是，MCP 团队的内部代号曾经是"Project USB-C for AI"。他们真的把"给 AI 造一个通用接口"这件事写在了白板上，然后做出来了。

有时候，最好的想法就是那种"说出来大家都觉得理所当然，但之前就是没人做"的事。