MCP第1章：MCP基础理论(从基本概念到通信原理)文章介绍 MCP 基础理论，包括其解决 Agent 与工具、Agen

本系列文章：

1. 概述

本文介绍了 MCP 基础理论，包括其解决 Agent 与工具、Agent 间交互的挑战，定义、功能、类比及价值，还涉及使用工具、安装、两大基础协议、C/S 架构、交互流程和相关平台等内容。

2. 引言

2.1. 两个互联领域的重大挑战：

2.1.1. 第一、Agent 与 Tools（工具）的交互

Aent 需要调用外部工具和API、访问数据库、执行代码等。

通过 MCP 解决

举例1：旅游规划

当我要去旅行时，旅行规划助手通过 MCP 同时调用天气 API（获取目的地气象）、交通 API（查询航班动态）、地图 API（规划路线），AI 自动生成带实时数据的行程方案。

举例2：联网搜索

我们在与 LLM 交互时，经常需要联网搜索最新信息以减少幻觉。然而，这里也存在问题：

1、并非所有聊天机器人都支持联网功能。

2、即使支持联网，也可能不包含你习惯使用的搜索引擎。

2.1.2. 第二、Agent 与 Agent（其他智能体或用户）的交互

Agent 需要理解其他 Agent 的意图、协同完成任务、与用户进行自然的对话。

通过 A2A 解决

3. MCP 是什么？

3.1. 什么是 MCP

官网地址：

modelcontextprotocol.io/

定义：

MCP（Model Context Protocol，模型上下文协议），2024年11月底，由Anthropic 推出的一种开放标准。旨在为大语言模型（LLM）提供统一的、标准化方式与外部数据源和工具之间进行通信。

核心功能：

提供标准化方法，使AI模型能够以一致的方式连接各种数据源和工具。

类比：

MCP就像AI世界的"USB-C"接口，为AI模型提供了统一的连接标准。

价值：

解决了传统Function Call的平台依赖问题，提供更统一、开放、安全、灵活的工具调用机制。

3.2. 如何理解 MCP

大模型是脑，MCP 工具就是眼和手。

有了DeepSeek，你就有了一个"智能助理"。但是，我们期望 LLM 能够承担更多功能，不仅限于简单对话，还能与外部的多种数据、工具进行交互。有了MCP，成为了现实！

3.3. MCP 带来的便利

传统AI集成的问题：这种为每个数据源构建独立连接的方式，可以被视为一个M*N问题。

问题：架构碎片化，难以扩展，限制了AI获取必要上下文信息的能力

MCP解决方案：提供统一且可靠的方式来访问所需数据，克服了以往集成方法的局限性。

举例2：联网搜索

在没有 MCP 的情况下，用户只能等待开发者添加特定搜索引擎的支持。

有了 MCP 后，只需简单配置，就能将所需服务接入当前使用的聊天机器人。

3.4. MCP有哪些好处

LLM应用的简化：不用适配各种私有协议，只需要知道怎么连接MCP server
LLM应用的快速扩展：随时“插拔”新的MCP Server即可，一个不够就再来一个
快速适应变化：若一个外部资源的接口发生变化，只需要对它的MCP Server做修改，所有的LLM应用就可以无缝适应
新的AI能力共享生态：通过MCP Server的共享，新的LLM应用可以快速获得各种工具，形成了一种新的合作体系，提高整体效用

3.5. MCP与传统方法的对比

4. 如何使用 MCP

4.1. 客户端工具

cherry studio（cherry-ai.com/）
vscode(cline 插件)
cursor

4.2. mcp server 环境安装

4.2.1. stdio的本地环境安装

stdio的本地环境有两种：

一种是Python 编写的服务；

一种用TypeScript 编写的服务。

分别对应着uvx 和 npx 两种指令。

4.2.2. uvx

第1种：若已配置Python环境，可使用以下命令安装：

pip install uv

第2种：在Windows下可以通过PowerShell运行命令来安装uv。

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex”

验证：重启终端并运行以下命令检查是否正常：

uv --version
uvx --help

4.2.3. npx

Node.js下载的官网：nodejs.org/zh-cn

安装，配置环境变量，并测试

5. MCP两大基础协议

5.1. 消息协议：JSON-RPC 2.0

在MCP中规定了唯一的标准消息格式，就是JSON-RPC 2.0

JSON-RPC 2.0是一种轻量级的、用于远程过程调用（RPC）的消息交换协议，使用JSON作为数据格式

注意： 它不是一个底层通信协议，只是一个应用层的消息格式标准。这种消息协议的好处，与语言无关(还有语言不支持JSON吗)、简单易用(结构简单，天然可读，易于调试)、轻量灵活(可以适配各种传输方式)

5.2. 传输协议

根据 MCP 的规范，当前支持三种通信机制（传输方式）：

stdio(标准输入输出)：主要用在本地服务上，操作你本地的软件或者本地的文件。比如 Blender 这种就只能用 Stdio 因为他没有在线服务。 MCP默认通信方式
SSE(基于Http的服务器推送事件Server-Sent Events)：主要用在远程通信服务上，这个服务本身就有在线的 API，比如访问你的谷歌邮件，天气情况等。

使用场景：

stdio，客户端和服务端部署在一台主机上，快速响应本地应用
sse，客户端和服务器在分布式部署场景下更合适

5.2.1. STDIO模式

5.2.1.1. 原理

STDIO（Standard Input/Output）是一种基于标准输入（stdin）和标准输出（stdout）的本地通信方式

MCP Client启动一个子进程（MCP Server）并通过stdin和stdout交换JSON-RPC消息来实现通信

其基本通信过程如下：

详细描述如下:

启动子进程（MCP Server）

MCP Client以子进程形式启动MCP Server，通过命令行指定Server的可执行文件及其参数

消息交换

MCP Client通过stdin向MCP Server写入JSON-RPC消息
MCP Server处理请求后，通过stdout返回JSON-RPC消息，也可通过stderr输出日志

生命周期管理

MCP Client控制子进程(MCP Server)的启动和关闭。通信结束后，MCP Client关闭stdin，终止MCP Server

5.2.1.2. 优点

这种方式适用于客户端和服务器在同一台机器上运行的场景，简单。
stdio模式无需外部网络依赖，通信速度快，适合快速响应的本地应用。
可靠性高，且易于调试

5.2.1.3. 缺点

Stdio 的配置比较复杂，我们需要做些准备工作，你需要提前安装需要的命令行工具。
stdio模式为单进程通信，无法并行处理多个客户端请求，同时由于进程资源开销较大，不适合在本地运行大量服务。（限制了其在更复杂分布式场景中的使用）

5.2.2. 基于SSE的Remote模式(MCP标准(2025-03-26版之前))

SSE(服务器发送事件)是一种基于HTTP协议的单向通信技术，允许Server主动实时向Client推送消息，Client只需建立一次连接即可持续接收消息。它的特点是:

单向（仅Server → Client）
基于HTTP协议，一般借助一次HTTP Get请求建立连接
适合实时消息推送场景（如进度更新、实时数据流等）

由于SSE是一种单向通信的模式，所以它需要配合HTTP Post来实现Client与Server的双向通信

严格的说，这是一种HTTP Post（Client->Server）+ HTTP SSE（Server -> Client）的伪双工通信模式

这种传输模式下:

一个HTTP Post通道，用于Client发送请求。比如调用MCP Server中的Tools并传递参数。注意，此时Server会立即返回
一个HTTP SSE通道，用于Server推送数据，比如返回调用结果或更新进度
两个通道通过session_id来关联，而请求与响应则通过消息中的id来对应

其基本通信过程如下:

详细描述如下:

连接建立： Client首先请求建立 SSE 连接，Server“同意”，然后生成并推送唯一的Session ID
请求发送： Client通过 HTTP POST 发送 JSON-RPC2.0 请求（请求中会带有Session ID 和Request ID信息）
请求接收确认： Server接收请求后立即返回 202(Accepted)状态码，表示已接受请求
异步处理： Server应用框架会自动处理请求，根据请求中的参数，决定调用某个工具或资源
结果推送： 处理完成后，Server通过 SSE 通道推送 JSON-RPC2.0 响应，其中带有对应的Request ID
结果匹配： Client的SSE连接侦听接收到数据流后，会根据Request ID 将接收到的响应与之前的请求匹配
重复处理： 循环2-6这个过程。这里面包含一个MCP的初始化过程
连接断开： 在Client完成所有请求后，可以选择断开SSE连接，会话结束

简单总结：通过HTTP Post发送请求，但通过SSE的长连接异步获得Server的响应结果

5.2.2.1. 场景

SSE方式适用于客户端和服务器位于不同物理位置的场景。
适用于实时数据更新、消息推送、轻量级监控和实时日志流等场景
对于分布式或远程部署的场景，基于 HTTP 和 SSE 的传输方式则更为合适。

5.2.2.2. 优点

配置方式非常简单，基本上就一个链接就行，直接复制他的链接填上就行

5.2.3. Streamable HTTP模式（MCP标准（2025-03-26版））

在MCP新标准(2025-03-26版)中，MCP引入了新的Streamable HTTP远程传输机制来代替之前的HTTP+SSE的远程传输模式，STDIO的本地模式不变

该新标准还在OAuth2.1的授权框架、JSON-RPC批处理、增强工具注解等方面进行增加和调整，且在2025.05.08号发布的MCP SDK 1.8.0版本中正式支持了Streamable HTTP

HTTP+SSE这种方式存在问题有:

需要维护两个独立的连接端点
有较高的连接可靠性要求。一旦SSE连接断开，Client无法自动恢复，需要重新建立新连接，导致上下文丢失
Server必须为每个Client维持一个高可用长连接，对可用性和伸缩性提出挑战
强制所有Server向Client的消息都经由SSE单向推送，缺乏灵活性

其主要变化部分的基本通信过程如下:

这里的主要变化包括:

Server只需一个统一的HTTP端点（/messages）用于通信
Client可以完全无状态的方式与Server进行交互，即Restful HTTP Post方式
必要时Client也可以在单次请求中获得SSE方式响应，如：一个需要进度通知的长时间运行的任务，可以借助SSE不断推送进度
Client也可以通过HTTP Get请求来打开一个长连接的SSE流，这种方式与当前的HTTP+SSE模式类似
增强的Session管理。Server会在初始化时返回Mcp-Session-Id，后续Client在每次请求中需要携带该MCP-Session-Id。这个Mcp-Session-Id作用是用来关联一次会话的多次交互;Server可以用Session-Id来终止会话，要求Client开启新会话;Client也可以用HTTP Delete请求来终止会话

Streamable HTTP在旧方案的基础上，提升了传输层的灵活性与健壮性:

允许无状态的Server存在，不依赖长连接。有更好的部署灵活性与扩展能力
对Server中间件的兼容性更好，只需要支持HTTP即可，无需做SSE处理
允许根据自身需要开启SSE响应或长连接，保留了现有规范SSE模式的优势

5.3. MCP 的 C/S 架构

MCP 遵循客户端-服务器架构（client-server），其中包含以下5个核心概念：

MCP 主机(MCP Hosts)
MCP 客户端( MCP Clients )
MCP 服务器( MCP Servers )
本地资源( Local Resources )
远程资源( Remote Resources )

5.3.1. MCP Host

作为运行 MCP 的主应用程序，例如 Claude Desktop、Cursor、Cline 或 AI 工具。

为用户提供与LLM交互的接口，同时集成 MCP Client 以连接 MCP Server。

5.3.2. MCP Client

MCP Client是由LLM应用程序使用MCP SDK创建并维护的一个Server会话，就像在程序中维护一个数据库的Connection一样，借助MCP SDK可以与MCP Server通信，如查看Server的Tools。在本地模式下，Client与Server是一对一的关系。如果需要连接多个MCP Server，需要自行维护多个Session。

MCP client 充当 LLM 和 MCP server 之间的桥梁，嵌入在主机程序中，主要负责：