大家好呀！今天和大家深入探讨一下在 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;};}{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） 根据部署需求，该协议可以在不同的传输层上实现：
客户端和服务器通过 stdin 接收 JSON 消息，并通过 stdout 进行响应。 客户端通过标准 HTTP POST 请求发送命令。 自定义传输（Custom transports） ：实现可以根据需要创建额外的传输机制。3. 生命周期管理（Lifecycle Management） 基础协议为客户端和服务器之间的连接实现了结构化的生命周期：
初始化阶段（Initialization Phase） ：它们交换功能信息（客户端与服务器共享工具和采样，服务器与客户端共享工具、资源和提示）。 MCP 交互生命周期：Cursor IDE 与 Linear/Slack 的示例 让我们通过一个简单的示例来理解我们到目前为止所学到的内容。其中：
以下是 MCP 交互生命周期过程的详细工作流程：
初始化阶段（Initialization Phase） 连接建立（Connection Establishment） ：当用户在 Cursor IDE 中激活 Linear 集成时，IDE 会发起与 Linear MCP 服务器的连接，通常通过 stdio 或 WebSockets。功能协商（Capability Negotiation） ：Cursor 发送包含其功能（支持的功能）的初始化请求。 Linear 服务器回复其功能（可用资源、工具、协议版本）。 Cursor 评估兼容性，确保双方都支持必要的协议功能。 Cursor 请求可用工具（tools/list）。 Linear 回复工具，如 create_ticket、assign_ticket、add_comment 等。 准备好通知（Ready Notification） ：Cursor 发送已初始化的通知，表明它已准备好开始常规操作。操作阶段（Operation Phase） 用户告诉 Cursor，“为登录页面崩溃创建一个错误工单”。 Cursor 中的 LLM 确定需要使用一个工具。 Cursor 发送针对 create_ticket 的 tools/call 请求，并带有适当的参数。 跨服务集成（Cross-Service Integration） ：用户说，“在 Slack 上通知团队关于这个新工单的情况”。 Cursor 连接到 Slack MCP 服务器（这是一个具有自己生命周期的单独连接）。 Cursor 向 Slack 服务器发送 tools/call 请求。 维护阶段（Maintenance Phase） Cursor 定期发送 ping 请求以确保连接仍然有效。 终止阶段（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 服务器和处理复杂身份验证流程的挑战。它适用于集成具有访问受限资源的应用程序。
关于 MCP 的常见问题 MCP 与 Langchain 或其他框架有何不同？ LangChain 是一个框架，而 MCP 是一种协议。使用框架时，你可能会面临供应商锁定的风险，但协议不会出现这种情况。只要你遵循协议指南，就没有问题。甚至 LangChain 也可以采用 MCP 作为构建有状态智能体的标准。MCP 服务器与工具调用有何不同？ 直接调用工具不是比绕一圈更简单吗？是的，但是协议确保了开发者以统一的方式定义和调用工具，这使得开发客户端（主机应用程序）和服务器（集成）都更加容易。管理 LLM 上下文并不是那么困难，为什么还需要一个协议呢？ 同样，目标是尽可能减少开发开销。例如，Cursor 开发者只需要关注客户端实现，而 Linear 只需要关注服务器实现。只要双方都符合我们详细描述的基础协议标准，就都没问题。它是必要的吗？ 不是必要的，但是随着 MCP 客户端的增长，对 MCP 服务器的需求将会急剧增加。
