MCP原理

1、MCP概念

2024年11月25日，由 Anthropic 所推动的一项开放标准，Model Context Protocol（MCP，模型上下文协议），旨在为 大语言模型（LLMs） 应用提供一个标准化的接口，使其能够连接和交互 外部数据源和工具。

一句话概括：MCP 就是用于标准化大模型与各类外部工具和数据源之间的交互，换句话说，就是标准化了应用程序如何为大模型提供上下文信息。

2025年3月，OpenAI 宣布采用 MCP 后，该协议逐渐被广泛采用。

2、使用 MCP 的好处

为什么要使用 MCP ？
使用 MCP 的好处是什么？
了解目前 大型语言模型（LLM）的局限：

• 知识更新慢，大型语言模型无法有效回应未经过训练的知识。例如，若某项新技术刚刚发布，而该模型使用的数据仅限于几个月前的资料，它将无法提供有关该新技术的详细信息或特点。
• 缺乏专业领域的知识，大型语言模型通常基于公开的常规数据进行训练，因而缺乏对特定专业领域知识的深入理解。这使得它们在面对特定业务场景中的专业数据和信息时，无法提供精准的分析和解答。
• 没有统一的外部数据访问标准，为大型语言模型提供上下文信息的方式多种多样，例如：检索增强生成（RAG）、知识库以及结合互联网搜索等。然而，缺乏统一的标准化方法，使得开发过程繁琐且复杂。

MCP 提供标准化接口，使大型语言模型能够连接和交互外部数据源和工具，方便开发。
使用 MCP 的好处：

• 简化开发：一次编写，多次集成，无需为每个集成重写自定义代码。
• 灵活性： 切换 AI 模型或工具，无需复杂的重新配置。
• 预构建工具多，很多厂商为他们的应用程序构建 MCP 接口，开发时可以直接使用，无需设计复杂的使用逻辑。

3、MCP 架构

下面这张图应该十分熟悉了吧，很多文章都使用过。（图片来源）

由图可知，MCP 采用经典的 C/S 架构（客户端/服务器），主要有以下三部分：

• MCP hosts（MCP 主机）：通常指基于大模型的 AI 应用，比如 Claude Desktop、ChatGPT
  Desktop、Cursor 等桌面端应用，这类应用需要访问外部数据或工具；
• MCP clients（MCP 客户端）：内置在应用中，与 MCP server建立一对一的连接；
• MCP server（MCP 服务器）：连接本地或远程的数据源，提供特定功能；
  • 本地数据源：文件或数据库；
  • 远程服务：外部 API 或互联网服务；

MCP 协议以统一的方式将外部数据或工具接入 AI 应用，类似于 USB-C 接口标准化不同设备的连接方式，从而减少开发者因多样化的接口标准而产生的适配成本。

简单说，MCP 就像一座桥梁，它本身不处理复杂逻辑，只负责协调 AI 应用与外部资源之间的信息流动。

总结：
MCP 的核心在于建立一个标准化的通信层，使得 LLMs 能够在处理用户请求或执行任务时，如果需要访问外部信息或功能，可以通过 MCP clients（MCP 客户端）向 MCP server（MCP 服务器）发送请求。MCP server 则负责与相应的外部数据源或工具进行交互，获取数据并按照 MCP 协议规范进行格式化，最后将格式化后的数据返回给 LLM。LLM 接收到上下文信息后，可以将其用于生成更准确、更相关的回复，或者执行用户请求的操作。

4、MCP 和 API 的区别

在推出 MCP 之前，AI 应用如果要对接外部工具，通常需要单独整合多个不同的 API，每个 API 的接口可能都各不相同，认证方式和错误处理也可能不同，极大地增加了开发复杂度和维护成本。

传统 API 的整合方式类似于为每扇门配备不同的钥匙，而 MCP 则通过标准化的协议实现统一接入，开发者仅需集成一次即可兼容多种工具或服务。

下面是 MCP 和传统 API 的对比：

功能	MCP	API
整合难度	一次标准化整合	每个API单独整合
实时双向通信	支持	不支持
动态发现工具	支持	不支持
拓展性	即插即用	需要额外开发
安全性与控制	所有工具统一标准	每个API单独定义

MCP 与 API 的区别：

• 单一协议：MCP 充当标准化的“连接器”，因此集成一个 MCP 意味着可能访问多个工具和服务，而不仅仅是一个。
• 动态发现：MCP 允许 AI 模型动态发现可用工具并与之交互，而无需对每个集成进行硬编码。
• 双向通信：MCP 支持持久、实时的双向通信。

MCP 提供实时的双向通信：

• 获取数据：LLM 查询 MCP server（MCP 服务器）以获取上下文信息 → 例如检查您的日历
• 触发：LLM 指示 MCP server（MCP 服务器）采取行动 → 例如：重新安排会议、发送电子邮件

5、JSON-RPC 2.0 消息格式

MCP 的核心通信协议基于 JSON-RPC 2.0 消息格式。
JSON-RPC 2.0 是一种用于远程过程调用（RPC）的协议，它允许计算机系统之间通过网络进行通信，调用某一方的程序功能。它使用 JSON（JavaScript Object Notation）格式来传输消息，因此这种消息格式是轻量级且易于解析的。
JSON-RPC 2.0 消息格式包含以下几个关键部分：

1. version：版本号，告诉接收方消息遵循的协议版本。对于 JSON-RPC 2.0，通常是 “2.0”。
2. id：每个请求或响应都需要有一个唯一的标识符，用于关联请求和响应。它通常是数字或字符串。
3. method：请求中需要调用的方法或功能的名称。
4. params：方法所需的参数，这个部分是可选的，具体取决于方法的要求。
5. result：响应中返回的结果，它出现在响应消息中，表示方法执行的结果。
6. error：如果方法执行过程中发生错误，会包含错误信息。

举例子：
例子 1：查询用户信息
假设我们有一个系统，用户可以通过 API 获取自己在数据库中的信息。比如查询用户 ID 为 123 的用户信息。
  请求消息：

    {
      "jsonrpc": "2.0",
      "method": "getUserInfo",
      "params": [123],
      "id": 1
    }

在这个请求中，method 表示我们要调用的函数是 getUserInfo，params 是传递的参数（这里是用户 ID：123），id 是请求的标识符，方便后续返回时进行匹配。
响应消息：

    {
      "jsonrpc": "2.0",
      "result": {
        "id": 123,
        "name": "John Doe",
        "age": 30
      },
      "id": 1
    }

在这个响应中，result 是执行 getUserInfo 方法后的返回结果，即用户的详细信息。

例子 2：调用计算器功能
假设我们有一个计算器应用程序，可以通过 RPC 进行加法运算。客户端请求服务端加法运算两个数的和。
请求消息：

    {
      "jsonrpc": "2.0",
      "method": "add",
      "params": [5, 7],
      "id": 2
    }

这个请求要求计算 5 和 7 的和，method 是 add，params 是两个数字 5 和 7。
响应消息：

    {
      "jsonrpc": "2.0",
      "result": 12,
      "id": 2
    }

响应中，result 返回了加法运算的结果 12。

总结

MCP 客户端和服务器之间的所有消息都必须遵循 JSON-RPC 2.0 规范。该协议定义了这些类型的消息：
请求

    {
      "jsonrpc": "2.0";
      "id": "string | number";
      "method": "string";
      "params": {
        "[key: string]": "unknown";
      };
    }

• 请求必须包含字符串或整数 ID。
• 与基本 JSON-RPC 不同，ID 必须非空。
• 请求 ID 之前不得被请求者使用过。

反应

    {
      "jsonrpc": "2.0";
      "id": "string | number";
      "result": {
        "[key: string]": "unknown";
      }
      "error": {
        "code": "number";
        "message": "string";
        "data": "unknown";
      }
    }

• 响应必须包含与其对应的请求相同的 ID。
• 响应进一步细分为成功结果或错误。必须设置 a 或 an。响应中 result 与 error 字段不可同时存在。
• 结果可以遵循任何 JSON 对象结构，而错误必须包含 错误代码和消息。
• 错误代码必须是整数。

通知

    {
      "jsonrpc": "2.0";
      "method": "string";
      "params": {
        "[key: string]": "unknown";
      };
    }

• 通知不得包含 ID。

6、连接生命周期

1、初始化

图1	图2

1. 客户端发送包含协议版本和功能的请求initialize
2. Server 使用其协议版本和功能进行响应
3. 客户端发送通知作为确认initialized
4. 正常消息交换开始

2、消息交换
初始化后，支持以下模式：

• 请求-响应：客户端或服务器发送请求，另一个响应
• 通知：任一方发送单向消息

3、终止
任何一方都可以终止连接：

• 干净关机方式close()
• 传输断开
• 错误条件

总结

Model Context Protocol（MCP）作为一项由 Anthropic 推动的开放标准，通过建立统一的通信层，为大语言模型（LLMs）与外部数据源及工具之间的交互提供了标准化解决方案。其核心价值在于简化开发流程并提升灵活性。

传统LLM应用面临知识更新滞后、专业领域知识不足以及接口碎片化等问题，而MCP通过统一的协议接口，将外部资源整合为“即插即用”模式，使开发者无需为不同工具重复编写适配代码。

例如，通过一次标准化集成，AI应用即可动态调用本地数据库、远程API或互联网服务，大幅降低维护成本。此外，MCP支持实时双向通信，允许LLM主动获取上下文信息或触发外部操作（如查询日历、发送邮件），显著提升了模型在实际场景中的响应能力与实用性。

从技术架构来看，MCP采用经典的客户端-服务器（C/S）模型，由 MCP Host（AI应用）、MCP Client（内置客户端）和MCP Server（连接数据源的服务端）三部分组成，其通信基于 JSON-RPC 2.0 协议。

该协议通过轻量级的 JSON 格式实现请求、响应与通知的标准化交互，支持动态发现工具和持久连接生命周期管理。相较于传统 API 需逐一适配不同接口的繁琐流程， MCP 的“单一协议”设计不仅实现了即插即用，还通过统一的安全标准增强了系统可控性。

例如，JSON-RPC 的消息格式规范确保了数据传输的一致性与可扩展性，而初始化、消息交换和终止的完整生命周期管理则保障了连接的稳定性。

总体而言，MCP 通过技术标准化与架构创新，为 AI 应用的高效集成与功能拓展提供了可靠的基础设施。

参考文章

1. Model Context Protocol 简介（官方介绍）：https://www.anthropic.com/news/model-context-protocol
2. 维基百科：模型上下文协议：https://zh.wikipedia.org/wiki/%E6%A8%A1%E5%9E%8B%E4%B8%8A%E4%B8%8B%E6%96%87%E5%8D%8F%E8%AE%AE?utm_source=chatgpt.com#
3. 模型上下文协议MCP（Model Context Protocol）是什么？：https://www.11meigui.com/2025/model-context-protocol.html
4. 什么是模型上下文协议 （MCP）？与 API 相比，它如何简化 AI 集成：https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained/
5. 实战 Model Context Protocol：https://www.aneasystone.com/2025/03/
6. MCP 官方文档：https://modelcontextprotocol.io/introduction
7. JSON-RPC 2.0 （部分内容由 ChatGPT-o4-mini 生成，提示词：以通俗易懂的语言解释 JSON-RPC 2.0 消息格式，并提供两个示例）
8. MCP 概念：https://modelcontextprotocol.io/docs/concepts/architecture#python
9. JSON-RPC 2.0 内容总结：https://modelcontextprotocol.io/specification/2025-03-26/basic