MCP

MCP（Model Context Protocol）说白了就是一个协议，类似于 HTTP 协议，只不过它是专门在 Agent 架构下，为大语言模型（LLM）与服务端之间的交互设计的。在没有 MCP 协议之前，不同厂商的大语言模型和服务端之间往往采用各自不同的接口和数据格式去进行 function_call 交互，这就导致了集成的复杂度和维护成本较高。MCP 通过定义一套统一的协议规范，简化了这种交互，使得不同的模型和服务端可以更容易地互操作。

MCP Server

MCP Server 可以理解为一个用了 MCP 协议并对外暴露能力（定义的函数/工具、Prompts）的后端。典型交互链条是：

1）LLM 产出函数调用意图 function_call（仅是文本，不直接执行），比如：

1
2
3
4
5
{
      "type": "tool_call",
      "name": "get_weather",
      "arguments": { "date": "2025-11-11", "location": "Beijing" }
}

2）Agent（带 MCP 客户端） 接收到 LLM 的输出后，解析 function_call，MCP 客户端再根据 MCP 协议将请求发送给 MCP Server。

1
2
3
4
5
6
7
8
9
{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "date": "2025-11-11", "location": "Beijing" }
  }
}

3）MCP Server 在自己的权限内实际执行 LLM 想要调用的函数/工具，得到结果。
4）Agent 将标准化的结果回灌给 LLM，进入下一轮推理或结束。

说到底，LLM 只是一个文本生成器，Agent 把 LLM 的意图通过 MCP 协议告诉 MCP Server 它要执行里面的什么函数，MCP Server 再去执行然后返回标准响应结果给 LLM。

案例

现在主流平台以 Agent 集成 MCP 的方式暴露工具：例如 OpenAI 平台通过 Connectors 与远程 MCP 服务器给模型提供白名单工具访问，深度研究（Deep Research）能力也支持连接远程 MCP 服务器；开发者也可在应用内用 Apps SDK 对接 MCP。模型本身仍只产出“工具调用意图”，由 Agent 把它转成 MCP 消息并与 MCP Server 通信与执行。

也有一些比较热门的开源的 MCP Server 实现：

当然，你也可以自己实现一个 MCP Server，你可以定义自己的工具和函数，然后通过 MCP 协议让 Agent 调用它们。

总结

在 MCP 官网有一个比喻：“Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems。” 大体意思是说，MCP 就像是 AI 应用的 USB-C 接口，就像 USB-C 为电子设备连接各种外设和配件提供了标准化的方式一样，MCP 为 AI 应用连接外部系统提供了标准化的方式。

而在 MCP 的中文官方文档中，这句话是这样的：“MCP 是一个开放协议，它为应用程序向 LLM 提供上下文的方式进行了标准化。你可以将 MCP 想象成 AI 应用程序的 USB-C 接口。就像 USB-C 为设备连接各种外设和配件提供了标准化的方式一样，MCP 为 AI 模型连接各种数据源和工具提供了标准化的接口。” 虽然只是 AI 应用 和 AI 模型的区别，但我认为中文版的表述是存在一定误导性的。

从技术角度来看，AI 模型本身并不能直接“连接”或“调用” MCP。因为大语言模型的本质是一个文本生成器，它只能根据上下文生成下一步的输出，不具备主动发起交互的能力。真正执行“交互”操作、协调数据流和调用函数的，是外层的 Agent 架构。也就是说，Agent 才是那个“插着 MCP 接口”的实体，而不是 LLM 本身。可以理解为，MCP 不是插在 LLM 上的 USB-C，而是插在 Agent 上的 USB-C，而 LLM 只是 Agent 手里用的一块 “芯片”，它提供语言能力，但并不理解 MCP。