MCP(模型上下文协议)的集成架构是一种典型的客户端(AI应用)与服务器(MCP Server)架构。相对于本地模式中的进程间通信,跨越机器边界的远程模式则体现出更多的复杂性:传输协议、状态维持、并发处理等,都是棘手的问题,这也导致其Remote模式的标准一直还在不断完善中。
01 消息协议:JSON-RPC 2.0
既然是用来简化集成、提高互操作性的标准,首当其中的是消息协议。这就像一个国际交流会议,大家说相同的”语言“,效率才会更高。
在MCP中规定了唯一的标准消息格式,就是JSON-RPC 2.0。JSON-RPC 2.0是一种轻量级的、用于远程过程调用(RPC)的消息交换协议,使用JSON作为数据格式。
注意:它不是一个底层通信协议,只是一个应用层的消息格式标准。形象的说,就像两个人需要交换包裹,它规定了包裹应该如何打包、内部如何分区、如何贴标签等,但它不规定包裹如何运送。
比如,你需要调用MCP Server上的一个计算器来计算“5+3”,这就是一次远程过程调用。那么JSON-RPC2.0就约束了你给Server的消息必须遵循以下格式:
{
"jsonrpc": "2.0", // 协议版本,固定为 "2.0"
"method": "calculate", // 要调用的方法名
"params": {
// 方法参数,可以是对象或数组
"expression": "5+3"
},
"id": 1 // 请求标识符,用于匹配响应
}
而当MCP Server处理完成,JSON-RPC又约束了回复的消息必须长这样:
{
"jsonrpc": "2.0", // 协议版本
"result": 8, // 调用结果
"id": 1 // 对应请求的标识符
}
这样两边就非常和谐的完成了一次请求处理。在实际的JSON-RPC 2.0规范中,还规定了通知类消息的格式、异常时的标准错误代码等。
所以,你可以很容易看出这种消息协议的好处:
- 语言无关:还有语言不支持JSON吗?
- 简单易用:结构简单,天然可读,易于调试。
- 轻量灵活:可以适配各种传输方式(不规定怎么运输“包裹”)。
02 基于JSON-RPC 2.0的MCP模拟
规定了消息的标准,再选择一种传输方式,就可以简单模拟出MCP的远程方法调用过程。你肯定会首先想到简单又好用的HTTP协议,比如我们写一个简单的服务端来处理上面的请求:
...
app = FastAPI()
#可调用的工具
def safe_calculate(expression: str) -> float:
...省略...
@app.post('/jsonrpc')
async def jsonrpc_endpoint(request: Request):
"""处理所有JSON-RPC请求的FastAPI端点"""
try:
content = await request.json()
method_name = content.get("method")
params = content.get("params", {
})
request_id = content.get("id", None)
if method_name == "calculate": #暂时hard coding
try:
expression = params.get("expression", "")
result = safe_calculate(expression)
response = {
"jsonrpc": "2.0","result": result,"id": request_id}
except ValueError as ve:
response = {
"jsonrpc": "2.0",
"error": {
"code": -32603,"message": str(ve)},
"id": request_id
}
else:
.....其他错误处理...
return JSONResponse(content=response)
except Exception as e:
#处理其他异常
...
再写一个客户端来测试调用这个Server:
#模拟一个MCP客户端,基于简单的HTTP Post
......
class MCPClient:
......
def call(self, method, params=None, timeout=10):
"""调用远程方法"""
payload = {
"jsonrpc": "2.0",
"method": method,
"params": params if params is not None else {
},
"id": self.request_id
}
self.request_id += 1
headers = {
'Content-Type': 'application/json'}
try:
response = requests.post(
self.server_url,
data=json.dumps(payload),
headers=headers,
timeout=timeout
)
response.raise_for_status()
return response.json()
except Exception as e:
...
...client.call("caculate",{
"expression":"3+5"})
这样,我们就模拟了一个基于JSON-RPC2.0的MCP通信的"雏形":

-
客户端构造符合JSON-RPC2.0规范的请求消息
-
通过HTTP Post发送请求到服务端
-
服务端接收并解析请求,比如需要调用的方法(‘caculate’)
-
服务端根据请求参数调用对应逻辑(caculate函数)
-
获得结果,构造并返回JSON-RPC2.0标准的响应
03 传输协议:为什么需要SSE
MCP Server的其他功能(Resource等)当然也可以采用相同的方式实现。既然这种方式简单易用,为什么MCP的通信标准并不是简单的HTTP Post呢?
如果你采用FastMCP开发MCP Server,可能无法感知到这一点,因为FastMCP是在低层MCP SDK上封装的简易框架,隐藏了细节。
【单一的HTTP Post方式存在的不足】
用下图表示基于简单HTTP Post的请求-响应模式:
考虑到AI应用场景的实际特点, 存在着一些可以想象的局限性:
-
同步阻塞模式:不适应长时间任务需求
单一的请求/响应模式下,客户端必须等待服务端处理完成,这适合快速响应的API,但不擅长应对长时间运行的任务。比如,你可能会把一个复杂工作流发布成MCP Server的工具。那么这种模式就会带来客户端阻塞甚至超时的问题。
-
无法服务端推送:缺乏双向通信的能力
服务端不能主动向客户端推送消息,数据流动必须由客户端触发。但正如上面的场景,如果你的MCP Server运行一个长时间的任务,你可能需要定期的向客户端报告处理进度或者中间结果,而简单HTTP Post无法做到。
在MCP Server的功能规范中,也存在部分服务端发起的能力,这也依赖于服务端主动推送的能力。
-
短连接:无法应对对话式会话的需求
在实际应用场景中,你的客户端AI应用可能会在一次会话中多次频繁地与MCP Server对话,来访问其中的资源或工具。这种对话式的交互需要保持会话状态和连接,这需要建立长连接的会话。
-
流式输出的需求
AI Agent的应用场景中,有时候也需要工具调用做流式的输出,这也需要MCP Server的支持。
基于这样一些原因,MCP采用了带有SSE(Server-Sent Events)的HTTP协议作为Remote模式下的传输方式。
04 基于SSE的Remote模式
现在我们来了解这种“HTTP with SSE”的传输方式。
【什么是SSE】
SSE(服务器发送事件) 是一种基于HTTP协议的单向通信技术,允许服务器主动实时向客户端推送消息,客户端只需建立一次连接即可持续接收消息。它的特点是:
- 单向(仅服务器→客户端)
- 基于HTTP协议,一般借助一次HTTP Get请求建立连接
- 适合实时消息推送场景(如进度更新、实时数据流等)
其基本通信过程如下:
【MCP的HTTP with SSE模式】
由于SSE是一种单向通信的模式,所以它需要配合HTTP Post来实现客户端与服务端的双向通信。严格的说,这是一种HTTP Post(客户端->服务端) + HTTP SSE(服务端->客户端)的伪双工通信模式。
为什么是伪双工?因为它不是在一个通道上完成双向通信,WebSocket才是。
这种传输模式下:
-
一个HTTP Post通道,用于客户端发送请求。比如调用MCP Server中的Tools并传递参数。注意,此时服务端会立即返回。
-
一个HTTP SSE通道,用于服务端推送数据,比如返回调用结果或更新进度。
-
两个通道通过session_id来关联,而请求与响应则通过消息中的id来对应。
一次完整的会话过程用下图表示:
详细描述如下:
- 连接建立:客户端首先请求建立 SSE 连接,服务端“同意”,然后生成并推送唯一的Session ID。
- 请求发送:客户端通过 HTTP POST 发送 JSON-RPC2.0 请求(请求中会带有Session ID 和Request ID信息)。
- 请求接收确认:服务端接收请求后立即返回 202 (Accepted) 状态码,表示已接受请求。
- 异步处理:服务端应用框架会自动处理请求,根据请求中的参数,决定调用某个工具或资源。
- 结果推送:处理完成后,服务端通过 SSE 通道推送 JSON-RPC2.0 响应,其中带有对应的Request ID。
- 结果匹配:客户端的SSE连接侦听接收到数据流后,会根据Request ID 将接收到的响应与之前的请求匹配。
- 重复处理: 循环2-6这个过程。这里面包含一个MCP的初始化过程。
- 连接断开: 在客户端完成所有请求后,可以选择断开SSE连接,会话结束。
以上就是MCP远程模式下的HTTP with SSE的传输工作模式。简单总结:通过HTTP Post发送请求,但通过SSE的长连接异步获得服务端的响应结果。
现在,你应该可以理解,如果使用官方的低层SDK来开发MCP Server,为什么Server启动代码大概长这样:
这里服务端的两个端点,/sse是用于会话的开始建立SSE连接,/messages/则用于后续的客户端Post请求处理。
如果你愿意,你甚至可以直接使用最基础的HTTP代码与服务端通信(比如小编),以验证这个交互过程。
05 最新变化:Streamable HTTP
尽管HTTP with SSE的模式带来了很多优点,但也引入了复杂性。所以在最新的MCP标准(2025-03-26版)中,对目前的传输方式做了调整,改名为Streamable HTTP。
其主要变动在于允许在MCP Server端根据自身需要来选择:你可以选择简单的无状态模式,也可以按需选择支持目前的HTTP with SSE模式。这给予了开发者更大的选择权,具体包括:
-
移除了专门的
/sse
端点,所有通信都通过单一/message
端点进行。 -
任何 HTTP POST 请求都可被服务器按需升级为 SSE 流(不再强制);客户端也可通过GET 请求初始化 SSE 流(目前模式)。
-
服务器支持完全无状态部署。
当然,最终的协议版本与SDK以官方的正式发布为准。
如何系统学习掌握AI大模型?
AI大模型作为人工智能领域的重要技术突破,正成为推动各行各业创新和转型的关键力量。抓住AI大模型的风口,掌握AI大模型的知识和技能将变得越来越重要。
学习AI大模型是一个系统的过程,需要从基础开始,逐步深入到更高级的技术。
这里给大家精心整理了一份
全面的AI大模型学习资源
,包括:AI大模型全套学习路线图(从入门到实战)、精品AI大模型学习书籍手册、视频教程、实战学习、面试题等,资料免费分享
!
1. 成长路线图&学习规划
要学习一门新的技术,作为新手一定要先学习成长路线图,方向不对,努力白费。
这里,我们为新手和想要进一步提升的专业人士准备了一份详细的学习成长路线图和规划。可以说是最科学最系统的学习成长路线。
2. 大模型经典PDF书籍
书籍和学习文档资料是学习大模型过程中必不可少的,我们精选了一系列深入探讨大模型技术的书籍和学习文档,它们由领域内的顶尖专家撰写,内容全面、深入、详尽,为你学习大模型提供坚实的理论基础。(书籍含电子版PDF)
3. 大模型视频教程
对于很多自学或者没有基础的同学来说,书籍这些纯文字类的学习教材会觉得比较晦涩难以理解,因此,我们提供了丰富的大模型视频教程,以动态、形象的方式展示技术概念,帮助你更快、更轻松地掌握核心知识。
4. 2024行业报告
行业分析主要包括对不同行业的现状、趋势、问题、机会等进行系统地调研和评估,以了解哪些行业更适合引入大模型的技术和应用,以及在哪些方面可以发挥大模型的优势。
5. 大模型项目实战
学以致用 ,当你的理论知识积累到一定程度,就需要通过项目实战,在实际操作中检验和巩固你所学到的知识,同时为你找工作和职业发展打下坚实的基础。
6. 大模型面试题
面试不仅是技术的较量,更需要充分的准备。
在你已经掌握了大模型技术之后,就需要开始准备面试,我们将提供精心整理的大模型面试题库,涵盖当前面试中可能遇到的各种技术问题,让你在面试中游刃有余。
全套的AI大模型学习资源已经整理打包,有需要的小伙伴可以
微信扫描下方CSDN官方认证二维码
,免费领取【保证100%免费
】