Cursor里很火的 MCP（Model Context Protocol）是什么？长文介绍，收藏起来！

大家好呀！今天和大家深入探讨一下在 AI 领域掀起热潮的 Model Context Protocol（MCP）。Anthropic 在 2024 年 11 月发布了 MCP，起初开发者社区反应积极，然而那时很少有人意识到它的全部潜力。转眼间到了 2025 年 3 月，MCP 突然成为了 AI 领域最热门的话题。

这种转变在 Cursor、Cline 和 Goose 等流行的消费级 IDE 正式支持 MCP 时变得尤为明显。随着越来越多的客户端应用程序采用它，服务器端的集成变得愈发重要，其影响力也随之扩大。

然而，尽管备受关注，大家仍然心存疑惑：“MCP 究竟是什么？我应该关注它吗？它真的会成为下一个重大突破，还是只是又一个 AI 炒作呢？”

在本文中，我将为大家揭开 MCP 的神秘面纱，阐明它的用途，并剖析它为何重要。

 MCP 是什么 

为了让大家更清楚地了解，MCP 既不是像 LangChain 那样的框架，也不是一种工具，它是一种协议，类似于网络的 HTTP 协议或消息传递的 SMTP 协议。

一个更贴切的例子是 LSP（语言服务器协议），它在开发工具生态系统中对添加编程语言支持进行了标准化。同样地，MCP 对将额外上下文和工具集成到 AI 应用程序生态系统中进行了标准化。

它提供了通用规则，允许任何客户端与任何服务器进行通信，无论这些组件是由谁构建的，从而为多样化且可互操作的 AI 生态系统奠定了基础。Anthropic 将其定义为类似于智能体系统的 USB-C 端口。它对 AI 应用程序、大语言模型（LLM）和外部数据源（数据库、Gmail、Slack 等）之间的连接进行了标准化。

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

MCP 定义了客户端应如何与服务器通信，以及服务器应如何处理工具（API、函数等）和资源（如日志、数据库记录等只读文件）。后面我们会详细介绍这些内容。

 为什么我们应该关注MCP 

标准化的好处

1. 统一集成：使用单一协议即可将任何 LLM 连接到任何工具。
2. 减少开发时间：资源访问和工具执行采用标准模式。
3. 明确的职责分离：数据访问（资源）和计算（工具）清晰分离。
4. 一致的发现机制：使用统一的机制来查找可用的功能（工具、资源、提示、根目录、采样）。
5. 跨平台兼容性：为一个系统构建的工具可在其他系统上使用。

 MCP具有革命性吗？ 

回答是：没有。

没有 MCP 你也能开展工作。它并非具有革命性，但它为原本混乱的智能体开发领域带来了标准化。如果你的应用程序符合 MCP 客户端标准，你就可以连接到任何符合 MCP 客户端标准的服务器。在另一种情况下，作为客户端开发者，你必须根据自己的需求定制服务器，而其他人无法为你的平台进行开发。对于服务器开发者来说也是如此。

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

此时，大家对 MCP 的用途或多或少有了一定的了解。现在，让我们更透彻地理解 MCP。

 MCP 架构 

Model Context 协议由几个关键组件协同工作。以下是 Matt Pocock 在 Twitter 上发布的一张架构图。

完整的 MCP 架构由四个部分组成：

• 主机（Host）：协调整个系统并管理 LLM 的交互。
• 客户端（Clients）：以 1:1 的关系将主机连接到服务器。
• 服务器（Servers）：通过工具、资源和提示提供特定功能。
• 基础协议（Base Protocol）：定义所有这些组件如何通信。

在上面的图表中，客户端和主机是合并的；为了更清楚地说明问题，我们将它们分开来讲解。

1. 主机（Host）

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

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

例如 Claude Desktop、Cursor IDE、Windsurf IDE 等。

2. 客户端（Client）

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

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

3. 服务器（Server）

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

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

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

协议

该协议构成了 Model Context 协议（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）

根据部署需求，该协议可以在不同的传输层上实现：

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

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

1. 使用服务器发送事件（SSE）的 HTTP：

• 通过 HTTP 建立双向通信模式。
• 服务器维护 SSE 连接以将消息推送给客户端。
• 客户端通过标准 HTTP POST 请求发送命令。
• 更适合托管服务器。

1. 自定义传输（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 发送包含其功能（支持的功能）的初始化请求。
• Linear 服务器回复其功能（可用资源、工具、协议版本）。
• Cursor 评估兼容性，确保双方都支持必要的协议功能。
• 功能发现（Feature Discovery）：
• Cursor 请求可用工具（tools/list）。
• Linear 回复工具，如 create_ticket、assign_ticket、add_comment 等。
• 准备好通知（Ready Notification）：Cursor 发送已初始化的通知，表明它已准备好开始常规操作。

操作阶段（Operation Phase）

1. 工具执行（Tool Execution）：
• 用户告诉 Cursor，“为登录页面崩溃创建一个错误工单”。
• Cursor 中的 LLM 确定需要使用一个工具。
• Cursor 发送针对 create_ticket 的 tools/call 请求，并带有适当的参数。
• 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 发送关闭请求。
• Linear 回复确认。
• Cursor 发送退出通知。
• Linear 服务器释放与会话相关的资源。
• 错误恢复（Error Recovery）：
• 如果连接意外失败。
• Cursor 实施带有指数退避的重试逻辑。
• 成功重新连接后，初始化生命周期再次开始。

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

 MCP 的局限性 

1. 身份验证（Authentication）

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

2. 缺乏可靠的服务器（Lack of reliable Servers）

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

 Composio MCP：具有内置身份验证的托管 MCP 服务器 

Composio MCP 解决了身份验证和生态系统成熟度的核心挑战。我们的托管服务器为超过 100 个应用程序提供内置身份验证支持，自动处理 OAuth、API 密钥和基本身份验证流程。我们为 Linear、Slack、GitHub 和 Google Workspace 等服务创建了预构建的 MCP 服务器，因此你可以专注于构建 AI 体验，而无需担心集成细节。

这消除了维护自己的 MCP 服务器和处理复杂身份验证流程的挑战。它适用于集成具有访问受限资源的应用程序。

 关于 MCP 的常见问题 

1. MCP 与 Langchain 或其他框架有何不同？LangChain 是一个框架，而 MCP 是一种协议。使用框架时，你可能会面临供应商锁定的风险，但协议不会出现这种情况。只要你遵循协议指南，就没有问题。甚至 LangChain 也可以采用 MCP 作为构建有状态智能体的标准。
2. MCP 服务器与工具调用有何不同？直接调用工具不是比绕一圈更简单吗？是的，但是协议确保了开发者以统一的方式定义和调用工具，这使得开发客户端（主机应用程序）和服务器（集成）都更加容易。
3. 管理 LLM 上下文并不是那么困难，为什么还需要一个协议呢？同样，目标是尽可能减少开发开销。例如，Cursor 开发者只需要关注客户端实现，而 Linear 只需要关注服务器实现。只要双方都符合我们详细描述的基础协议标准，就都没问题。
4. 它是必要的吗？不是必要的，但是随着 MCP 客户端的增长，对 MCP 服务器的需求将会急剧增加。
- END -