一文详解模型上下文协议MCP

引言

Anthropic 公司在 2024 年 11 月发布了模型上下文协议 (Model Context Protocol, MCP)。开发者社区最初对此反应积极，但很少有人意识到它的全部潜力。快进到 2025 年 3 月，MCP 突然成为了人工智能领域最热门的话题。

当流行的消费级 IDE，如 Cursor、Cline 和 Goose 官方宣布支持 MCP 时，这种转变变得显而易见。随着越来越多的客户端应用采用 MCP，服务器端集成变得愈发重要，进一步放大了其影响力。

然而，尽管 MCP 备受瞩目，许多开发者仍然心存疑问：“MCP 到底是什么？我应该关注它吗？这真的是下一个重大技术趋势，还是又一个 AI 炒作？”这些困惑是真实存在的，也是可以理解的。

在本文中，我们将揭开 MCP 的神秘面纱，阐明其用途，并剖析它为何重要（或不重要）。

目录

• 那么，MCP 究竟是什么？
• 为什么你应该关注 MCP？
• MCP具有革命性吗？
• MCP 架构

• 宿主 (Host)
• 客户端 (Client)
• 服务器 (Server)

• MCP 中的“协议 (Protocol)”
• MCP 的底层结构

• 消息 (Messages)
• 传输机制 (Transportation Mechanisms)
• 生命周期管理 (Lifecycle Management)

• Cursor x Linear 生命周期示例

• MCP 的局限性

• ComposioMCP

• 关于 MCP 的常见问题解答

  那么，MCP 究竟是什么？

---

为了更清晰地说明，MCP 既不是像 LangChain 这样的框架，也不是一个工具；它是一种协议，类似于 Web 的 HTTP 协议或消息传递的 SMTP 协议。

一个更相关的例子是语言服务器协议 (Language Server Protocol, LSP)，它规范了在开发工具生态系统中添加对编程语言支持的方式。 类似地，MCP 规范了将额外的上下文和工具集成到 AI 应用生态系统中的方式。

它提供了一套通用规则，允许任何客户端与任何服务器通信，而无需考虑组件的构建者，从而为多样化和可互操作的 AI 生态系统奠定基础。Anthropic 公司将 MCP 定义为智能代理系统的 USB-C 端口。它标准化了 AI 应用、大型语言模型 (LLM) 和外部数据源（数据库、Gmail、Slack 等）之间的连接。

机器是客户端，外围设备是工具，而 MCP 就是 Type-C 端口。因此，无论设备或外围设备由谁制造，它们都可以无缝协作。

MCP 架构图

图片来源：https://www.linkedin.com/in/norah-klintberg-sakal

MCP 定义了客户端应如何与服务器通信，以及服务器应如何处理工具（API、函数等）和资源（只读文件，如日志、数据库记录等）。 稍后将对此进行详细介绍。

为什么你应该关注 MCP？

标准化的优势

1. 统一集成 ：一个用于连接任何 LLM 和任何工具的通用协议。
2. 缩短开发时间 ：用于资源访问和工具执行的标准模式。
3. 清晰的职责分离 ：数据访问（资源）和计算（工具）被清晰地分离。
4. 一致的发现机制 ：用于查找可用功能（工具、资源、提示词、根目录、采样）的统一机制。
5. 跨平台兼容性 ：为一个系统构建的工具可以与其他系统协同工作。

MCP 具有革命性吗？

简短的回答：不。

即使没有 MCP，你也能正常工作。它并不具有革命性，但为原本混乱的智能代理开发领域带来了标准化。如果你的应用符合 MCP 客户端规范，你就可以连接到任何符合 MCP 客户端规范的服务器。在另一种情况下，作为客户端开发者，你必须根据自己的需求定制服务器，其他人也无法为你的平台构建应用。服务器开发者的情况也是如此。

例如，在 Cursor 内部，如果 MCP 服务器遵循协议，你就可以连接到任何 MCP 服务器。

至此，你或多或少应该清楚 MCP 的用途了。现在，让我们更深入地了解 MCP，以获得更清晰的认识。

MCP 架构

模型上下文协议 (MCP) 包含几个协同工作的关键组件。以下是 Matt Pocock 在 Twitter 上发布的高级架构图。

完整的 MCP 架构包含四个部分：

• 宿主 (Host) ：协调整个系统并管理 LLM 交互。
• 客户端 (Client) ：将宿主与服务器连接，采用一对一关系。
• 服务器 (Server) ：通过工具、资源和提示词提供专门的功能。
• 基础协议 (Base Protocol) ：定义所有这些组件如何通信。

在上面的图表中，客户端和宿主被合并在一起；为了更清晰地说明，我们将它们分开。接下来，让我们详细了解每个组件，从内部理解 MCP。

1. 宿主 (Host)

宿主是期望从服务器获取数据的 LLM 应用。宿主可以是 IDE、聊天机器人或任何 LLM 应用。它们负责：

• 初始化和管理多个客户端。
• 客户端-服务器生命周期管理。
• 处理用户授权决策。
• 管理跨客户端的上下文聚合。

示例包括 Claude Desktop、Cursor IDE、Windsurf IDE 等。

2. 客户端 (Client)

每个客户端都有以下关键职责：

• 专用连接 ：每个客户端与单个服务器保持一对一的有状态连接。这种专注的关系确保了清晰的通信边界和安全隔离。
• 消息路由 ：客户端处理所有双向通信，高效地在宿主和其连接的服务器之间路由请求、响应和通知。我们将在 Cursor IDE 与Linear 和 Slack 的示例中看到一个简单的例子。
• 功能管理 ：客户端通过维护有关可用工具、资源（上下文数据）和提示模板的信息，来监控其连接的服务器的功能。
• 协议协商 ：在初始化期间，客户端协商协议版本和功能，确保宿主和服务器之间的兼容性。
• 订阅管理 ：客户端维护对服务器资源的订阅，并在这些资源发生更改时处理通知事件。

3. 服务器 (Server)

服务器是丰富 LLM 外部数据和上下文的基本构建块。关键的服务器原语包括：

• 工具 (Tools) ：可执行函数，允许 LLM 与外部应用交互。工具的功能类似于传统 LLM 调用中的函数。工具可以是向 API 端点发送的POST 请求；例如，一个名为 LIST\_FILES 的工具，以目录名作为参数，将获取目录中的文件并将它们发送回客户端。工具也可以是对外部服务（如 Gmail、Slack、Notion 等）的 API 调用。
• 资源 (Resources) ：可以是任何类型的数据，例如文本文件、日志文件、数据库模式、文件内容和 Git 历史记录。它们为 LLM 提供额外的上下文信息。
• 提示模板 (Prompt Templates) ：预定义的模板或指令，用于指导语言模型的交互。

工具由模型控制，而资源和提示词由用户控制。模型可以根据给定的上下文自动发现和调用工具。

MCP 中的 “协议 (Protocol)”

协议构成了模型上下文协议 (MCP) 架构的基础。它定义了不同组件（宿主、客户端和服务器）之间的通信方式。有关更深入的信息，请参阅官方的 MCP 规范 。

MCP 的底层结构（协议层）

该协议由几个关键层组成：

• 协议消息 (Protocol Message) ：核心 JSON-RPC 消息类型。
• 生命周期管理 (Lifecycle Management) ：客户端-服务器连接初始化、功能协商和会话控制。
• 传输机制 (Transport Mechanisms) ：客户端-服务器如何交换消息，通常有两种类型：用于本地服务器的 Stdio 和用于托管服务器的 SSE (服务器发送事件)。
• 服务器功能 (Server Features) ：服务器暴露的资源、提示词和工具。
• 客户端功能 (Client Features) ：客户端提供的采样和根目录列表。

在以上五个层中，基础协议，即 JSON-RPC 消息类型和生命周期管理，对于每个 MCP 实现都至关重要。其他组件可以根据特定应用的需求来实现。

协议的关键部分

1. 消息 (Messages)

MCP 的核心是使用 JSON-RPC 2.0 作为其消息传递格式，为客户端和服务器之间的通信提供了一种标准化的方式。基础协议定义了三种基本的消息类型：

1. 请求 (Requests) ：用于启动从客户端到服务器或反之亦然的操作的消息。 示例：

  
{  
  "jsonrpc": "2.0",  
  "id": "string | number",  
  "method": "string",  
  "params"?: {  
    "[key: string]": "unknown"  
  }  
}

1. 响应 (Responses) ：为响应请求而发送的消息。

  
{  
  "jsonrpc": "2.0",  
  "id": "string | number",  
  "result"?: {  
    "[key: string]": "unknown"  
  },  
  "error"?: {  
    "code": "number",  
    "message": "string",  
    "data"?: "unknown"  
  }  
}

1. 通知 (Notifications) ：不需要响应的单向消息。

  
{"jsonrpc": "2.0",  
  "method": "string",  
  "params"?: {  
    "[key: string]": "unknown"  
  }  
}

2. 传输机制 (Transport Mechanisms)

该协议可以基于不同的传输层实现，具体取决于部署需求：

• stdio ：通过标准输入/输出流进行通信。

• 客户端和服务器通过标准输入 (stdin) 接收 JSON 消息，并通过标准输出 (stdout) 响应。
• 简化了本地进程集成和调试。
• 非常适合本地服务器，如文件服务器、Git 服务器等。

• 基于服务器发送事件 (Server-Sent Events, SSE) 的 HTTP ：

• 通过 HTTP 建立双向通信模式。
• 服务器维护一个 SSE 连接，用于向客户端推送消息。
• 客户端通过标准的 HTTP POST 请求发送命令。
• 支持具有多个并发客户端的分布式架构。
• 更适合托管服务器。

MCP SSE 传输

• 自定义传输 (Custom transports) ：实现可以根据需要创建额外的传输机制。

3. 生命周期管理 (Lifecycle Management)

基础协议为客户端和服务器之间的连接实现了结构化的生命周期：

1. 初始化阶段 (Initialization Phase) ：

• 客户端和服务器协商协议版本。
• 它们交换功能信息（客户端与服务器共享工具和采样功能，服务器与客户端共享工具、资源和提示词）。
• 它们共享实现细节。

• 操作阶段 (Operation Phase) ：

• 进行正常的协议通信。- 双方都遵守协商好的功能。

• 关闭阶段 (Shutdown Phase) ：

• 优雅地终止连接。

客户端-服务器生命周期管理

MCP 交互生命周期：Cursor IDE 到 Linear/Slack 示例

让我们通过一个简单的例子来理解我们目前所学的内容。其中：

• 宿主是 Cursor IDE。
• 服务器是 Linear 和 Slack。

以下是 MCP 交互生命周期过程的详细工作流程：

初始化阶段 (Initialization Phase)

1. 建立连接 (Connection Establishment) ：当用户在 Cursor IDE 中激活 Linear 集成时，IDE 会启动与 Linear MCP 服务器的连接，通常通过 stdio 或WebSockets。
2. 功能协商 (Capability Negotiation) ：

• Cursor 发送一个 initialize 请求，其中包含其功能（它支持的功能）。
• Linear 服务器响应其功能（可用的资源、工具、协议版本）。
• Cursor 评估兼容性，确保双方都支持必要的协议功能。

• 功能发现 (Feature Discovery) ：

• Cursor 请求可用的工具 ( tools/list )。
• Linear 响应工具列表，例如 create\_ticket 、 assign\_ticket 、 add\_comment 等。

• 就绪通知 (Ready Notification) ：Cursor 发送一个initialized通知，表明它已准备好开始正常操作。

操作阶段 (Operation Phase)

1. 工具执行 (Tool Execution) ：

• 用户告诉 Cursor：“创建一个关于登录页面崩溃的 Bug 工单”。 -Cursor 中的 LLM 确定需要使用一个工具。
• Cursor 发送一个 tools/call 请求，调用 create\_ticket 工具，并附带适当的参数。
• Linear 服务器创建工单并返回结果。
• Cursor 向用户显示结果。

• 跨服务集成 (Cross-Service Integration) ：

• 用户说：“在 Slack 上通知团队关于这个新工单”。
• Cursor 连接到 Slack MCP 服务器（一个单独的连接，有自己的生命周期）。
• Cursor 向 Slack 服务器发送一个 tools/call 请求。
• Slack服务器发布消息并返回成功状态。
• Cursor 确认通知已发送。

维护阶段 (Maintenance Phase)

1. 健康检查 (Health Checks) ：

• Cursor 定期发送 ping 请求，以确保连接仍然存活。
• Linear 服务器响应以确认可用性。

终止阶段 (Termination Phase)

1. 优雅关闭 (Graceful Shutdown) ：

• 当用户关闭工作区或禁用集成时。
• Cursor 向 Linear 发送一个 shutdown 请求。
• Linear 确认收到响应。 -Cursor 发送一个 exit 通知。
• Linear 服务器释放与会话关联的资源。

• 错误恢复 (Error Recovery) ：

• 如果连接意外失败。
• Cursor 实现带有指数退避的重试逻辑。
• 成功重新连接后，初始化生命周期重新开始。

这种标准化的生命周期确保了任何 MCP 宿主和服务器之间可靠、可预测的交互，而无需考虑它们的具体实现。无论是 Cursor 连接到 Linear 进行工单管理，还是连接到 Slack 进行消息传递，都应用相同的协议模式，从而使集成保持一致性和互操作性。

MCP 的局限性

1. 身份验证 (Authentication)

MCP 当前的局限性之一是缺乏标准化的身份验证机制。协议本身没有规定应如何处理身份验证，而是留给实现者创建自己的解决方案。这可能会导致不同 MCP 服务器和客户端之间的安全实践不一致。

2. 缺乏可靠的服务器 (Lack of reliable Servers)

作为一个相对较新的协议，MCP 的生态系统仍在发展中。服务器数量较少，并且许多应用程序没有官方的 MCP 服务器。

关于 MCP 的常见问题解答

1. MCP 与Langchain 或任何其他框架有何不同？

LangChain 是一个框架，而 MCP 是一种协议。使用框架，你可能会面临供应商锁定的风险，但协议则不会。只要你遵循协议指南，就不会有问题。即使是 LangChain 也可以采用 MCP 作为构建有状态智能代理的标准。

1. MCP 服务器与工具调用有何不同？

直接调用工具不是更容易吗，为什么还要绕圈子使用 MCP 服务器？ 是的，但是协议确保开发者以统一的方式定义和调用工具，从而更容易开发客户端（宿主应用）和服务器（集成）。

1. 管理 LLM 上下文并没有那么困难，为什么还需要协议？

同样，目标是尽可能减少开发开销。例如，Cursor 开发者只需关心客户端实现，而 Linear 只需关心服务器实现。只要两者都符合基础协议标准（我们在上面详细描述过），就万事大吉。

1. MCP 是必要的吗？

不会，但随着 MCP 客户端的增长，对 MCP 服务器的需求将会猛增。

添加微信，备注”MCP “进入MCP专属技术交流群，入群门槛需要分享一篇MCP技术文章（非广告，公开即可）

如果你觉得这篇文章对你有帮助，别忘了点个赞、送个喜欢

/ 作者：致Great

/ 作者：欢迎转载，标注来源即可

下一篇我们将会从零手动实现MCP