# 深入解析模型上下文协议（MCP）

- URL: https://www.yidoo.xyz/mcp
- 作者: 核动力蜗牛
- 发布时间: 2025-03-12
- 更新时间: 2025-03-12
- 分类: LLM技术内幕
- 标签: agent, mcp

# 概述

随着 Cursor 等智能编程工具的崛起、Manus 产品的推出，以及 Claude Sonnet 等大语言模型在编程领域能力的显著提升，MCP 逐渐引起了技术社区的广泛关注与重视。本文将深入浅出地介绍 MCP 的核心概念，并结合具体场景探讨其实际应用价值。

# 什么是 MCP？

MCP（The Model Context Protocol，模型上下文协议）是一个开放协议，由 Anthropic 在 2024 年 11 月提出。MCP 能够实现 LLM 应用与外部数据源和工具之间的无缝集成。无论是在构建一个 AI 驱动的 IDE、增强聊天界面，还是创建自定义 AI 工作流，MCP 都提供了一种标准化的方式，将 LLM 与所需的上下文连接起来。 **可以把 MCP 理解为 Agent 世界的 转接头**。

![2456f8e57cfcf4c02f49964bddeba6e1.png](https://www.yidoo.xyz/images/2456f8e57cfcf4c02f49964bddeba6e1.png)

# MCP 整体架构

MCP 遵循 client-server 架构，对于一个 Agent 而言可以连接多个 MCP Server。整体架构包含 4 部分：

- MCP Host：通过 MCP 访问数据的 AI 工具的程序，如 Claude Desktop、集成开发环境（IDE）或 Agent 等
- MCP Client：与 MCP Server 保持 1:1 连接的协议客户端
- MCP Server：轻量级程序，通过标准化的 MCP 暴露特定功能，包括工具（Tools）、外部资源（Resources）和提示词模版（Prompts）等。
- MCP Protocols：定义 MCP Client 和 MCP Server 之间的通信方式

![81b16e8ec94283df1df07d99ca0eefa9.png](https://www.yidoo.xyz/images/81b16e8ec94283df1df07d99ca0eefa9.png)

## MCP Host

MCP Host 可以是任何需要访问外部数据的 LLM 应用/Agent。它们负责：

- 初始化和管理多个 MCP Client。
- MCP Client-MCP Server 生命周期管理。
- 处理用户授权。
- 管理跨 MCP Client 的上下文聚合。

## MCP Client

每个 MCP Client 负责：

- 专用连接：每个 MCP Client 与 MCP Server 保持一对一的有状态连接。这种专用连接模式确保了通信界限清晰，并实现安全隔离。
- 消息路由：MCP Client 负责处理所有双向通信，高效地在 MCP Host 和所连接 MCP Server 之间传递请求、响应和通知。
- 能力管理：MCP Client 通过维护服务器的可用工具、资源（上下文数据）以及提示模板等信息，监控并管理所连接 MCP Server 的能力。
- 协议协商：在初始化阶段，MCP Client 会与 MCP Server 协商协议版本和相关能力，以确保 MCP Host 与 MCP Server 之间的兼容性。
- 订阅管理：MCP Client 维护对 MCP Server 资源的订阅关系，当这些资源发生变化时，负责处理并分发相应的通知事件。

## MCP Server

MCP Server 是为 LLM 提供外部数据和上下文的基础构建单元。MCP Server 的关键组成包括：

- 工具（Tools）：工具是可执行的函数，使得大语言模型能够与外部应用进行交互，其作用方式类似于传统 LLM 调用中的函数。例如，一个名为 `LIST_FILES` 的工具，接收目录名称作为参数，执行后会获取该目录下的文件，并将结果返回给客户端。此外，工具也可以是对外部服务的 API 调用，例如 Gmail、Slack 和 Notion 等。
- 资源（Resources）：资源包括文本文件、日志文件、数据库结构定义、文件内容以及 Git 历史记录等，可以为 LLM 提供额外的上下文信息。
- 提示模板（Prompt Templates）：预定义的模板或指令，用于指导 LLM 的互动行为。

工具由模型自主控制，而资源和提示模板则由用户进行控制。模型能够根据给定的上下文自动发现并调用所需工具。

## MCP Protocols

所有的 MCP Protocol 必须遵循 JSON-RPC 2.0。目前协议定义的类型有：

- Requests：执行操作的消息，必须包含唯一的 ID 和方法名。
- Responses：返回的消息，必须包括 Request 中的 ID。
- Notifications：单向消息无需返回，必须不包含 ID。

关于协议的更多内容可以参考：https://spec.modelcontextprotocol.io/specification/2024-11-05/

# Function Calling vs MCP

主要区别如下：

Function Calling 由特定的大模型服务提供商（如 OpenAI 的 GPT-4）引入的功能。它允许模型根据输入，生成特定格式的函数调用请求。应用程序接收到该请求后，执行相应的操作，并将结果返回给模型。这种机制使模型能够主动请求外部功能的执行，但并不强制要求使用特定的通信协议或格式。

MCP 是在 OpenAI 的 Function call 和 GPTs 之后提出的，可以说 Function call 为 MCP 提供了灵感和基础功能。MCP 是一种开放协议，旨在通过标准化的接口，实现大型语言模型与外部数据源及工具的无缝集成。它规定了上下文与请求的结构化传递方式，确保消息传递的标准化和一致性。MCP 的设计初衷是通过本地运行服务器来确保用户数据的安全性，避免将敏感信息直接发送给 LLM。

**主要区别：**

- 层级定位：Function Calling 更侧重于模型的具体实现和特性，是特定大模型厂商提供的独特功能。而 MCP 则是一个更底层、更通用的标准，相当于为所有人提供的“公共基础设施”。
- 通信方式：Function Calling 的通信格式并不固定，可能根据不同厂商的实现而有所不同。而 MCP 要求通信格式遵循 JSON-RPC 2.0 标准，确保消息传递的标准化和一致性。
- 依赖关系： 两者并不互相包含，也没有谁必须依赖谁。应用可以选择在 MCP 之上通过特定机制（包括 Function Calling）与模型交互，也可以在 MCP 范式下使用其他不基于 Function Calling 的方式与模型或数据源交互。

# 参考资料

- [Model Context Protocol Introduction](https://modelcontextprotocol.io/introduction)
- [Model Context Protocol Specification](https://spec.modelcontextprotocol.io/specification/2024-11-05/)
- [给 MCP 祛魅](https://mp.weixin.qq.com/s/qtsxTC8_LioHUuZHQo5CoA)
- [MCP 与 Function Call 区别 - 蝈蝈俊 - 博客园](https://www.cnblogs.com/ghj1976/p/18602070/mcp-yu-function-call-qu-bie)