仅用于站内搜索，没有排版格式，具体信息请跳转上方微信公众号内链接
Anthropic公司在2024年11月发布了模型上下文协议(ModelContextProtocol,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)
传输机制(TransportationMechanisms)
生命周期管理(LifecycleManagement)
CursorxLinear生命周期示例
MCP的局限性
ComposioMCP
关于MCP的常见问题解答
为了更清晰地说明，MCP既不是像LangChain这样的框架，也不是一个工具；它是一种协议，类似于Web的HTTP协议或消息传递的SMTP协议。
一个更相关的例子是语言服务器协议(LanguageServerProtocol,LSP)，它规范了在开发工具生态系统中添加对编程语言支持的方式。类似地，MCP规范了将额外的上下文和工具集成到AI应用生态系统中的方式。
它提供了一套通用规则，允许任何客户端与任何服务器通信，而无需考虑组件的构建者，从而为多样化和可互操作的AI生态系统奠定基础。Anthropic公司将MCP定义为智能代理系统的USB-C端口。它标准化了AI应用、大型语言模型(LLM)和外部数据源（数据库、Gmail、Slack等）之间的连接。
机器是客户端，外围设备是工具，而MCP就是Type-C端口。因此，无论设备或外围设备由谁制造，它们都可以无缝协作。
图片来源：https ://www.linkedin.com/in/norah-klintberg-sakal
MCP定义了客户端应如何与服务器通信，以及服务器应如何处理工具（API、函数等）和资源（只读文件，如日志、数据库记录等）。稍后将对此进行详细介绍。
统一集成：一个用于连接任何LLM和任何工具的通用协议。
缩短开发时间：用于资源访问和工具执行的标准模式。
清晰的职责分离：数据访问（资源）和计算（工具）被清晰地分离。
一致的发现机制：用于查找可用功能（工具、资源、提示词、根目录、采样）的统一机制。
跨平台兼容性：为一个系统构建的工具可以与其他系统协同工作。
简短的回答：不。
即使没有MCP，你也能正常工作。它并不具有革命性，但为原本混乱的智能代理开发领域带来了标准化。如果你的应用符合MCP客户端规范，你就可以连接到任何符合MCP客户端规范的服务器。在另一种情况下，作为客户端开发者，你必须根据自己的需求定制服务器，其他人也无法为你的平台构建应用。服务器开发者的情况也是如此。
例如，在Cursor内部，如果MCP服务器遵循协议，你就可以连接到任何MCP服务器。
至此，你或多或少应该清楚MCP的用途了。现在，让我们更深入地了解MCP，以获得更清晰的认识。
模型上下文协议(MCP)包含几个协同工作的关键组件。以下是MattPocock在Twitter上发布的高级架构图。
完整的MCP架构包含四个部分：
宿主(Host)：协调整个系统并管理LLM交互。
客户端(Client)：将宿主与服务器连接，采用一对一关系。
服务器(Server)：通过工具、资源和提示词提供专门的功能。
基础协议(BaseProtocol)：定义所有这些组件如何通信。
在上面的图表中，客户端和宿主被合并在一起；为了更清晰地说明，我们将它们分开。接下来，让我们详细了解每个组件，从内部理解MCP。
宿主是期望从服务器获取数据的LLM应用。宿主可以是IDE、聊天机器人或任何LLM应用。它们负责：
初始化和管理多个客户端。
客户端-服务器生命周期管理。
处理用户授权决策。
管理跨客户端的上下文聚合。
示例包括ClaudeDesktop、CursorIDE、WindsurfIDE等。
每个客户端都有以下关键职责：
专用连接：每个客户端与单个服务器保持一对一的有状态连接。这种专注的关系确保了清晰的通信边界和安全隔离。
消息路由：客户端处理所有双向通信，高效地在宿主和其连接的服务器之间路由请求、响应和通知。我们将在CursorIDE与Linear和Slack的示例中看到一个简单的例子。
功能管理：客户端通过维护有关可用工具、资源（上下文数据）和提示模板的信息，来监控其连接的服务器的功能。
协议协商：在初始化期间，客户端协商协议版本和功能，确保宿主和服务器之间的兼容性。
订阅管理：客户端维护对服务器资源的订阅，并在这些资源发生更改时处理通知事件。
服务器是丰富LLM外部数据和上下文的基本构建块。关键的服务器原语包括：
工具(Tools)：可执行函数，允许LLM与外部应用交互。工具的功能类似于传统LLM调用中的函数。工具可以是向API端点发送的POST请求；例如，一个名为LIST_FILES的工具，以目录名作为参数，将获取目录中的文件并将它们发送回客户端。工具也可以是对外部服务（如Gmail、Slack、Notion等）的API调用。
资源(Resources)：可以是任何类型的数据，例如文本文件、日志文件、数据库模式、文件内容和Git历史记录。它们为LLM提供额外的上下文信息。
提示模板(PromptTemplates)：预定义的模板或指令，用于指导语言模型的交互。
工具由模型控制，而资源和提示词由用户控制。模型可以根据给定的上下文自动发现和调用工具。
协议构成了模型上下文协议(MCP)架构的基础。它定义了不同组件（宿主、客户端和服务器）之间的通信方式。有关更深入的信息，请参阅官方的MCP规范。
该协议由几个关键层组成：
协议消息(ProtocolMessage)：核心JSON-RPC消息类型。
生命周期管理(LifecycleManagement)：客户端-服务器连接初始化、功能协商和会话控制。
传输机制(TransportMechanisms)：客户端-服务器如何交换消息，通常有两种类型：用于本地服务器的Stdio和用于托管服务器的SSE(服务器发送事件)。
服务器功能(ServerFeatures)：服务器暴露的资源、提示词和工具。
客户端功能(ClientFeatures)：客户端提供的采样和根目录列表。
在以上五个层中，基础协议，即JSON-RPC消息类型和生命周期管理，对于每个MCP实现都至关重要。其他组件可以根据特定应用的需求来实现。
MCP的核心是使用JSON-RPC2.0作为其消息传递格式，为客户端和服务器之间的通信提供了一种标准化的方式。基础协议定义了三种基本的消息类型：
请求(Requests)：用于启动从客户端到服务器或反之亦然的操作的消息。示例：
响应(Responses)：为响应请求而发送的消息。
通知(Notifications)：不需要响应的单向消息。
该协议可以基于不同的传输层实现，具体取决于部署需求：
stdio：通过标准输入/输出流进行通信。
客户端和服务器通过标准输入(stdin)接收JSON消息，并通过标准输出(stdout)响应。
简化了本地进程集成和调试。
非常适合本地服务器，如文件服务器、Git服务器等。
基于服务器发送事件(Server-SentEvents,SSE)的HTTP：
通过HTTP建立双向通信模式。
服务器维护一个SSE连接，用于向客户端推送消息。
客户端通过标准的HTTPPOST请求发送命令。
支持具有多个并发客户端的分布式架构。
更适合托管服务器。
自定义传输(Customtransports)：实现可以根据需要创建额外的传输机制。
基础协议为客户端和服务器之间的连接实现了结构化的生命周期：
初始化阶段(InitializationPhase)：
客户端和服务器协商协议版本。
它们交换功能信息（客户端与服务器共享工具和采样功能，服务器与客户端共享工具、资源和提示词）。
它们共享实现细节。
操作阶段(OperationPhase)：
进行正常的协议通信。-双方都遵守协商好的功能。
关闭阶段(ShutdownPhase)：
优雅地终止连接。
让我们通过一个简单的例子来理解我们目前所学的内容。其中：
宿主是CursorIDE。
服务器是Linear和Slack。
以下是MCP交互生命周期过程的详细工作流程：
建立连接(ConnectionEstablishment)：当用户在CursorIDE中激活Linear集成时，IDE会启动与LinearMCP服务器的连接，通常通过stdio或WebSockets。
功能协商(CapabilityNegotiation)：
Cursor发送一个initialize请求，其中包含其功能（它支持的功能）。
Linear服务器响应其功能（可用的资源、工具、协议版本）。
Cursor评估兼容性，确保双方都支持必要的协议功能。
功能发现(FeatureDiscovery)：
Cursor请求可用的工具(tools/list)。
Linear响应工具列表，例如create_ticket、assign_ticket、add_comment等。
就绪通知(ReadyNotification)：Cursor发送一个initialized通知，表明它已准备好开始正常操作。
工具执行(ToolExecution)：
用户告诉Cursor：“创建一个关于登录页面崩溃的Bug工单”。-Cursor中的LLM确定需要使用一个工具。
Cursor发送一个tools/call请求，调用create_ticket工具，并附带适当的参数。
Linear服务器创建工单并返回结果。
Cursor向用户显示结果。
跨服务集成(Cross-ServiceIntegration)：
用户说：“在Slack上通知团队关于这个新工单”。
Cursor连接到SlackMCP服务器（一个单独的连接，有自己的生命周期）。
Cursor向Slack服务器发送一个tools/call请求。
Slack服务器发布消息并返回成功状态。
Cursor确认通知已发送。
健康检查(HealthChecks)：
Cursor定期发送ping请求，以确保连接仍然存活。
Linear服务器响应以确认可用性。
优雅关闭(GracefulShutdown)：
当用户关闭工作区或禁用集成时。
Cursor向Linear发送一个shutdown请求。
Linear确认收到响应。-Cursor发送一个exit通知。
Linear服务器释放与会话关联的资源。
错误恢复(ErrorRecovery)：
如果连接意外失败。
Cursor实现带有指数退避的重试逻辑。
成功重新连接后，初始化生命周期重新开始。
这种标准化的生命周期确保了任何MCP宿主和服务器之间可靠、可预测的交互，而无需考虑它们的具体实现。无论是Cursor连接到Linear进行工单管理，还是连接到Slack进行消息传递，都应用相同的协议模式，从而使集成保持一致性和互操作性。
MCP当前的局限性之一是缺乏标准化的身份验证机制。协议本身没有规定应如何处理身份验证，而是留给实现者创建自己的解决方案。这可能会导致不同MCP服务器和客户端之间的安全实践不一致。
作为一个相对较新的协议，MCP的生态系统仍在发展中。服务器数量较少，并且许多应用程序没有官方的MCP服务器。
MCP与Langchain或任何其他框架有何不同？
LangChain是一个框架，而MCP是一种协议。使用框架，你可能会面临供应商锁定的风险，但协议则不会。只要你遵循协议指南，就不会有问题。即使是LangChain也可以采用MCP作为构建有状态智能代理的标准。
MCP服务器与工具调用有何不同？
直接调用工具不是更容易吗，为什么还要绕圈子使用MCP服务器？是的，但是协议确保开发者以统一的方式定义和调用工具，从而更容易开发客户端（宿主应用）和服务器（集成）。
管理LLM上下文并没有那么困难，为什么还需要协议？
同样，目标是尽可能减少开发开销。例如，Cursor开发者只需关心客户端实现，而Linear只需关心服务器实现。只要两者都符合基础协议标准（我们在上面详细描述过），就万事大吉。
MCP是必要的吗？
不会，但随着MCP客户端的增长，对MCP服务器的需求将会猛增。
添加微信，备注”MCP“进入MCP专属技术交流群，入群门槛需要分享一篇MCP技术文章（非广告，公开即可）
如果你觉得这篇文章对你有帮助，别忘了点个赞、送个喜欢
/作者：致Great
下一篇我们将会从零手动实现MCP
