MCP | NotionNext BLOG

type

Post

status

Published

date

Dec 7, 2025

slug

summary

• MCP 的核心想法：给大模型一个统一的“工具调用协议”，让模型能通过标准方式去调用各种外部工具，从而扩展能力边界（不只是思考，还能做事）。 • 要解决的问题：如果工具分别用 Java、Python、Rust 写，直接把它们做成某个特定语言的 tool 会受限。MCP 通过统一协议，把“跨语言、跨进程”工具调用标准化。 • MCP 最大特点：跨进程调用工具 ◦ 本地跨进程：通过 stdio（标准输入输出）与子进程通信 ◦ 远程跨进程：通过 http 连接远程服务通信 • 消息协议标准：统一使用 JSON-RPC 2.0，优点是与语言无关、结构清晰、易调试、轻量灵活。 • 传输模式演进： ◦ Stdio：客户端启动 MCP Server 子进程，用 stdin/stdout 交换 JSON-RPC 消息，并管理子进程生命周期。 ◦ SSE（旧远程标准）：HTTP POST 发请求 + SSE 长连接收结果，用 sessionId 和 requestId 关联请求响应，属于“伪双工”。 ◦ Streamable HTTP（新标准，2025-03-26 起）：用更统一、健壮的方式替代 HTTP+SSE，减少双连接维护问题，并增强 session 管理（例如返回并使用 Mcp-Session-Id，支持终止会话等），更利于扩展和部署。

MCP的基本原理

我们实现的 tool 怎么调用、参数是什么都是大模型自己决定的。

tool 给大模型扩展了做事情的能力，本来它只能思考，不能做事情，但是现在可以自己调用 tool 来帮你做事情了。

但你有没有发现 tool 有个问题：node 写的 ai agent 的代码，你的 tool 也得是 node 写。如果你之前有一些工具是 java、python、rust 写的呢？你想封装成 tool 怎么办呢？

有的人说：现在不是可以执行命令么，通过单独进程把这些其他语言写的代码跑一下就行啊。

确实，也就是这样：这里的 stdio 就是标准输入输出流，也就是键盘输入、控制台输出。当你进程跑一个子进程，就可以用这种方式通信。

还有的人说：简单，用 http 啊！本地跑个服务就好了。也就是这样：现在是解决了跨语言调用工具的问题。

那如果每个人都这样搞，它们提供的服务都不一样，我想接入别的 tool，是不是要了解每个服务都是怎么定义的呢？

能不能定义一个统一的通信协议，我们都按照这个格式来沟通，这样所有的跨进程工具调用就都可以接入了。

也就是这样：想跨进程调用某个工具，通过这个协议通信就行。不管是本地工具，直接跑那个进程，然后 stdio 通信。还是远程工具，通过 http 连接远程服务进程。

这个协议叫什么呢？是给 Model 扩展 Context 上下文，让它能做的更多，知道的更多的 Protocal 协议。就叫 MCP 吧。恭喜你，你发明了 MCP！

MCP 最大的特点就是可以跨进程调用工具。

跨本地的进程调用，就是用 stdio。

跨远程的进程调用，就是用 http。

你的 AI Agent 就是 MCP 客户端，可以通过 MCP 协议调用各种 MCP Server，实现跨进程的工具调用。

当然，在 langchain 里，它也是 tool ，只不过是 tool 的一种而已：你在 tool 的函数里，调用下 MCP Client，访问下远程 Mcp Server，它本质上还是 tool，但是却集成了 MCP 工具。

MCP传输模式与核心架构深度剖析

1.消息协议:JSON-RPC2.0

在MCP中规定了唯一的标准消息格式，就是JSON-RPC2.0JSON-RPC2.0是一种轻量级的、用于远程过程调用(RPC)的消息交换协议，使用JSON作为数据格式注意:它不是一个底层通信协议，只是一个应用层的消息格式标准。这种消息协议的好处，与语言无关(还有语言不支持JSON吗)、简单易用(结构简单，天然可读，易于调试)、轻量灵活(可以适配各种传输方

2.三种传输模式

MCP提供了三种不同的传输实现。

默认传输方式:基于Stdio、SSE、Streamable HTTP

STDlO(Standard Input/Output)

是一种基于标准输入(stdin)和标准输出(stdout)的本地通信方式

MCPClient启动一个子进程(MCR Server)并通过stdin和stdout交换JSON-RPC消息来实现通信

详细描述如下:

1.启动子进程(MCPServer)

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

2.消息交换

MCPClient通过stdin向MCPServer写入JSON-RPC消息

MCPServer处理请求后,通过stdout返回JSON-RPC消息，也可通过stderr输出日志

3.生命周期管理

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

SSE模式

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

单向(仅ServerClient)

基于HTTP协议，一般借助一次HTTPGet请求建立连接

适合实时消息推送场景(如进度更新、实时数据流等)由于SSE是一种单向通信的模式，所以它需要配合HTTPPost来实现Client与Server的双向通信严格的说,这是一种HTTP Post(Client->Server)+HTTPSSE(Server->Client)的伪双工通信模式

这种传输模式下:

一个HTTPPost通道,用于Client发送请求。比如调用MCPServer中的Tools并传递参数。注意,此时Server会立即返回

一个HTTPSSE通道，用干Server推送数据，比如返回调用结果或更新进度

两个通道通过sessionid来关联，而请求与响应则通过消息中的id来对应

详细描述如下: 1.连接建立:Client首先请求建立SSE连接，Server"同意"，然后生成并推送唯一的SessionID

2.请求发送:Client通过HTTPPOST发送JSON-RPC2.0请求(请求中会带有SessionID和Request ID信息)

3.请求接收确认:Server接收请求后立即返回202(Accepted)状态码，表示已接受请求

4.异步处理:Server应用框架会自动处理请求，根据请求中的参数，决定调用某个工具或资源

5.结果推送:处理完成后，Server通过SSE通道推送JSON-RPC2.0响应，其中带有对应的RequestID

6.结果匹配:Client的SSE连接侦听接收到数据流后，会根据Request ID将接收到的响应与之前的请求匹配

7.重复处理:循环2-6这个过程。这里面包含一个MCP的初始化过程

8.连接断开:在Client完成所有请求后，可以选择断开SSE连接，会话结束

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

Streamable 模式

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

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

需要维护两个独立的连接端点

有较高的连接可靠性要求。一旦SSE连接断开，Client无法自动恢复，需要重新建立新连接，导致上下文丢失

Server必须为每个Client维持一个高可用长连接，对可用性和伸缩性提出挑战

强制所有Server向Client的消息都经由SSE单向推送，缺乏灵活性

这里的主要变化包括:

Server只需一个统一的HTTP端点(/messages)用于通信

Client可以完全无状态的方式与Server进行交互,即RestfulHTTPPost方式.必要时Client也可以在单次请求中获得SSE方式响应，如:一个需要进度通知的长时间运行的任务可以借助SSE不断推送进度

Client也可以通过HTTPGet请求来打开一个长连接的SSE流，这种方式与当前的HTTP+SSE模式类似

增强的Session管理。Server会在初始化时返回Mcp-Session-ld,后续Client在每次请求中需要携带该MCP-Session-ld。这个Mcp-Session-ld作用是用来关联一次会话的多次交互; Server可以用Session-ld来终止会话,要求Client开启新会话;Client也可以用HTTPDelete请求来终止会话

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

允许无状态的Server存在，不依赖长连接。有更好的部署灵活性与扩展能力

对Server中间件的兼容性更好，只需要支持HTTP即可，无需做SSE处理

允许根据自身需要开启SSE响应或长连接，保留了现有规范SSE模式的优势

总结

MCP 的核心想法：给大模型一个统一的“工具调用协议”，让模型能通过标准方式去调用各种外部工具，从而扩展能力边界（不只是思考，还能做事）。 • 要解决的问题：如果工具分别用 Java、Python、Rust 写，直接把它们做成某个特定语言的 tool 会受限。MCP 通过统一协议，把“跨语言、跨进程”工具调用标准化。 • MCP 最大特点：跨进程调用工具 ◦ 本地跨进程：通过 stdio（标准输入输出）与子进程通信 ◦ 远程跨进程：通过 http 连接远程服务通信 • 消息协议标准：统一使用 JSON-RPC 2.0，优点是与语言无关、结构清晰、易调试、轻量灵活。 • 传输模式演进： ◦ Stdio：客户端启动 MCP Server 子进程，用 stdin/stdout 交换 JSON-RPC 消息，并管理子进程生命周期。 ◦ SSE（旧远程标准）：HTTP POST 发请求 + SSE 长连接收结果，用 sessionId 和 requestId 关联请求响应，属于“伪双工”。 ◦ Streamable HTTP（新标准，2025-03-26 起）：用更统一、健壮的方式替代 HTTP+SSE，减少双连接维护问题，并增强 session 管理（例如返回并使用 Mcp-Session-Id，支持终止会话等），更利于扩展和部署。