大家好呀！今天和大家深入探讨一下在 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
标准化的好处
统一集成：使用单一协议即可将任何 LLM 连接到任何工具。 减少开发时间：资源访问和工具执行采用标准模式。 明确的职责分离：数据访问（资源）和计算（工具）清晰分离。 一致的发现机制：使用统一的机制来查找可用的功能（工具、资源、提示、根目录、采样）。 跨平台兼容性：为一个系统构建的工具可在其他系统上使用。
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 作为其消息格式，为客户端和服务器之间的通信提供了一种标准化的方式。基础协议定义了三种基本消息类型：
请求（Requests）：从客户端发送到服务器或从服务器发送到客户端以启动操作的消息。示例：
{jsonrpc:"2.0";id:string|number;method:string;params?:{[key:string]:unknown;};}
响应（Responses）：对请求的回复消息。
{jsonrpc:"2.0";id:string|number;result?:{[key:string]:unknown;}error?:{code:number;message:string;data?:unknown;}}
通知（Notifications）：不需要响应的单向消息。
{jsonrpc:"2.0";method:string;params?:{[key:string]:unknown;};}
2. 传输机制（Transport Mechanisms）
根据部署需求，该协议可以在不同的传输层上实现：
stdio：通过标准输入/输出流进行通信。
客户端和服务器通过 stdin 接收 JSON 消息，并通过 stdout 进行响应。 简化了本地进程集成和调试。 非常适合像文件、Git 服务器等本地服务器。
使用服务器发送事件（SSE）的 HTTP：
通过 HTTP 建立双向通信模式。 服务器维护 SSE 连接以将消息推送给客户端。 客户端通过标准 HTTP POST 请求发送命令。 更适合托管服务器。
自定义传输（Custom transports）：实现可以根据需要创建额外的传输机制。
3. 生命周期管理（Lifecycle Management）
基础协议为客户端和服务器之间的连接实现了结构化的生命周期：
初始化阶段（Initialization Phase）：
客户端和服务器协商协议版本。 它们交换功能信息（客户端与服务器共享工具和采样，服务器与客户端共享工具、资源和提示）。 它们共享实现细节。
操作阶段（Operation Phase）： 进行正常的协议通信。 双方都遵守协商的功能。 关闭阶段（Shutdown Phase）： 优雅地终止连接。 主机是 Cursor IDE。 服务器是 Linear 和 Slack。 连接建立（Connection Establishment）：当用户在 Cursor IDE 中激活 Linear 集成时，IDE 会发起与 Linear MCP 服务器的连接，通常通过 stdio 或 WebSockets。 功能协商（Capability Negotiation）： Cursor 发送包含其功能（支持的功能）的初始化请求。 Linear 服务器回复其功能（可用资源、工具、协议版本）。 Cursor 评估兼容性，确保双方都支持必要的协议功能。 功能发现（Feature Discovery）： Cursor 请求可用工具（tools/list）。 Linear 回复工具，如 create_ticket、assign_ticket、add_comment 等。 准备好通知（Ready Notification）：Cursor 发送已初始化的通知，表明它已准备好开始常规操作。 工具执行（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 确认通知已发送。 健康检查（Health Checks）： Cursor 定期发送 ping 请求以确保连接仍然有效。 Linear 服务器回复以确认可用性。 优雅关闭（Graceful Shutdown）： 当用户关闭工作区或禁用集成时。 Cursor 向 Linear 发送关闭请求。 Linear 回复确认。 Cursor 发送退出通知。 Linear 服务器释放与会话相关的资源。 错误恢复（Error Recovery）： 如果连接意外失败。 Cursor 实施带有指数退避的重试逻辑。 成功重新连接后，初始化生命周期再次开始。 MCP 与 Langchain 或其他框架有何不同？LangChain 是一个框架，而 MCP 是一种协议。使用框架时，你可能会面临供应商锁定的风险，但协议不会出现这种情况。只要你遵循协议指南，就没有问题。甚至 LangChain 也可以采用 MCP 作为构建有状态智能体的标准。 MCP 服务器与工具调用有何不同？直接调用工具不是比绕一圈更简单吗？是的，但是协议确保了开发者以统一的方式定义和调用工具，这使得开发客户端（主机应用程序）和服务器（集成）都更加容易。 管理 LLM 上下文并不是那么困难，为什么还需要一个协议呢？同样，目标是尽可能减少开发开销。例如，Cursor 开发者只需要关注客户端实现，而 Linear 只需要关注服务器实现。只要双方都符合我们详细描述的基础协议标准，就都没问题。 它是必要的吗？不是必要的，但是随着 MCP 客户端的增长，对 MCP 服务器的需求将会急剧增加。
MCP 交互生命周期：Cursor IDE 与 Linear/Slack 的示例
让我们通过一个简单的示例来理解我们到目前为止所学到的内容。其中：
以下是 MCP 交互生命周期过程的详细工作流程：
初始化阶段（Initialization Phase）
操作阶段（Operation Phase）
维护阶段（Maintenance Phase）
终止阶段（Termination Phase）
这种标准化的生命周期确保了任何 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 服务器和处理复杂身份验证流程的挑战。它适用于集成具有访问受限资源的应用程序。