支持私有云部署
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


Cursor里很火的 MCP(Model Context Protocol)是什么?长文介绍,收藏起来!

发布日期:2025-03-21 05:37:01 浏览次数: 1773 来源:三黄工作室
推荐语

探索AI领域新热点MCP,了解其如何改变AI应用开发。

核心内容:
1. MCP的起源和基本概念
2. MCP的架构和标准化好处
3. MCP对AI开发领域的影响及未来展望

杨芳贤
53A创始人/腾讯云(TVP)最具价值专家

大家好呀!今天和大家深入探讨一下在 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 architecture image

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 diagram

完整的 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 服务器等本地服务器。
MCP Stdio
  1. 使用服务器发送事件(SSE)的 HTTP
  • 通过 HTTP 建立双向通信模式。
  • 服务器维护 SSE 连接以将消息推送给客户端。
  • 客户端通过标准 HTTP POST 请求发送命令。
  • 更适合托管服务器。
MCP over SSE
  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 -

53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费场景POC验证,效果验证后签署服务协议。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询