Forrest’s 博客📧MCP
type
Post
status
Published
date
Dec 16, 2025
slug
MCP
summary
category
agentic
tags
思考
MCP
A2A
icon
password
AI summary
Blocked by
Blocking
Category
是什么
MCP(Model Context Protocol，由Anthropic主导)是一个基于 JSON-RPC 2.0 的协议，用来规范Agent如何以“统一、可扩展、可编程”的方式调用外部能力（Tools / Resources / Prompts）。
- 标准化的“工具注册-能力发现-调用鉴权”流程：比如anthropic的MCP定义了工具的schema，agent能够自动读懂工具功能，无需hard code写死
- 安全沙箱的理念：工具调用时隔离的，比如代码执行器不会影响agent本身的运行环境，这是MCP比agent直接本地调用API更安全的地方
- 与agent的memory联动：MCP调用结果会自动回写到agent上下文，供后续推理使用
组成
MCP Server 与 MCP Client
MCP Server 作为能力提供方，核心聚焦于能力的对外输出与调用支撑，不参与对话逻辑的处理，具体职责包括：
- 定义并暴露自身能力描述（Schema）
- 接收 MCP Client 发起的调用请求
- 返回结构化的执行结果或标准错误信息
MCP Client 作为请求发起方，承担着会话管理与工具调度的核心职责，具体工作内容如下：
- 维护会话（Session）的生命周期与状态
- 调用
list_tools方法获取可用工具列表
- 根据大模型的决策结果，筛选并触发目标工具的调用
- 将工具执行结果回传给大模型，作为后续决策的上下文输入
JSON-RPC 2.0（MCP 协议适配版）
握手流程
MCP Client请求
所有请求严格遵循 JSON-RPC 2.0 标准，格式定义如下：
- jsonrpc
- 规定值，表示这是JSON-RPC 2.0
- id
- 标识一次RPC调用，Server返回结果必须带一个id，client用它来做请求-响应配对
- method
- initialize 建立会话
- tools/list 列出工具
- tools/call 调用工具
- resource/read 读资源
- params标识真正的业务参数
以调用
add 工具为例，请求格式如下：对应服务端工具定义（Python 示例）：
MCP Server响应
成功响应
失败的请求
Stdio场景
MCP Stdio 是基于标准输入输出（stdin/stdout）的轻量级传输方式，适用于客户端与服务端部署在同一个机器或同一个进程的场景，是MCP三种transport中架构最简单、通讯开销最低的一种。
- 通讯方式：客户端以子进程的方式启动MCP Server，二者共用同一台主机的资源，无需网络通信链路
- 数据格式：所有通信消息均遵循 JSON-RPC 规范，支持请求、通知、响应三类消息类型。
- 传输通道：
- MCP Server 从 ** 标准输入（stdin）** 读取客户端发送的 JSON-RPC 消息
- MCP Server 将处理结果或状态信息通过 ** 标准输出（stdout）** 回传给客户端
- 消息分隔：每条消息以换行符作为分隔符，禁止消息内容中嵌入换行符，确保客户端与服务端能准确解析消息边界
适用场景与优缺点
特性 | 具体说明 |
优势 | 1. 无网络开销，通信延迟极低；
2. 部署简单，无需配置端口、网关等网络组件；
3. 消息格式简单，解析成本低。 |
劣势 | 1. 仅支持单机部署，客户端与服务端无法跨机器通信；
2. 不支持长连接会话的断连重连；
3. 子进程的生命周期与客户端强绑定，扩展性弱。 |
典型场景 | 1. 本地调试的 MCP 工具插件；
2. 嵌入式 AI 应用的本地能力调用；
3. 对延迟要求极高的轻量级工具调用。 |
SSE场景
双端点架构
/sse端点：客户端发起 GET 请求建立 SSE 长连接，专门用于接收服务端推送的消息（如工具调用结果、状态通知）；
/message端点：客户端发起 POST 请求提交 JSON-RPC 格式的任务指令（如初始化会话、调用工具），属于短连接请求
二者通过 session 强绑定。
通讯过程
- Client端发起一个 GET 请求，建立SSE长连接。（Connection1）
- Server端回复
event：endpoint类型的事件，将sessionId信息放入data中返回。（Connection1）
- Client端使用第2步返回的sessionId信息发起首个HTTP POST 请求。（Connection2）
- Server端迅速响应202，但无内容。（Connection2）
- Server端返回第3步请求的实际消息。（Connection1）
- Client端使用第2步返回的sessionId发起HTTP POST请求
initialized作为确认。（Connection3）
- Server端迅速响应202，无内容。（Connection3）
- Client端使用第2步返回的sessionId发起HTTP POST请求
list tools。（Connection4）
- Server端迅速响应202，无内容。（Connection4）
- Server端返回第8步请求的实际消息，即工具列表。（Connection1）
- Client端使用第2步返回的sessionId发起HTTP POST请求
call tool。（Connection5）
- Server端迅速响应202，无内容。（Connection5）
- Server端返回第11步请求的实际消息，即工具调用结果。（Connection1）
/messag 可以理解为往session的事件循环里添加一条任务在 SSE 模式下，一个 MCP Server 内部通常是这样：
所有
/messages 请求，最终都会进入某个 session 的执行上下文。适用场景与优缺点
特性 | 具体说明 |
优势 | 1. 支持跨机器通信，适合分布式部署
2. 服务端可主动推送消息，无需客户端轮询
3. 会话与长连接绑定，状态管理简单。 |
劣势 | 1. 不支持断连重连，连接断开后会话状态丢失，任务需重新执行；
2. 长连接占用服务端资源，高并发下易引发性能瓶颈；
3. 双端点架构增加部署复杂度，且部分网络基础设施（如 CDN、防火墙）会主动断开长时间空闲连接；
4. 所有响应必须通过 SSE 流返回，即使是简单的同步请求也无法直接通过 POST 接口响应。 |
典型场景 | 1. 早期跨节点的 MCP 服务调用；
2. 对实时性要求不高、并发量较小的工具调用场景；
3. 无需断连恢复的一次性任务（如短文本分析）。 |
Streamable场景
MCP Streamable HTTP 是 MCP 协议的新一代跨网络传输方案，以统一端点 + 按需流式 + 会话可恢复为核心设计，解决了 MCP SSE 的长连接资源浪费、断连丢失会话、基础设施兼容性差等问题，是目前官方推荐的 MCP 远程通信方式。
一次请求 = 一次完整的“请求 + 多段响应”生命周期
- 会话初始化（有状态场景）
- 客户端向
/mcp发 POST 初始化请求（无会话 ID）； - 服务端返回
Mcp-Session-Id头（UUID 级安全 ID）； - 客户端后续所有请求必须携带该头，否则返回 400 错误。
- 消息传输流程
- 客户端→服务端：所有 JSON-RPC 消息通过 POST 到
/mcp，支持单条或批量请求； - 服务端→客户端：
- 同步响应：直接返回 200+JSON 结果，适合短任务；
- 流式响应：升级为 SSE 流推送分批结果，传输完成后关闭流；
- 通知推送：客户端发 GET 到
/mcp建立 SSE 流，服务端通过该流推送通知。
- 会话管理规范
- 服务端可主动终止会话，后续该 ID 请求返回 404，客户端需重新初始化；
- 客户端退出时可发 DELETE 请求显式终止会话（服务端可返回 405 拒绝）。
不同版本下MCP 的区别
2024-11-05（基础奠基版）
- 核心定位：定义 MCP 核心架构与消息格式，奠定工具、资源、提示等基础概念。
- 传输能力：仅支持 Stdio（单机子进程通信）和 MCP SSE（双端点，单向长连接推送），无断连恢复能力。
- 会话机制：会话依赖 SSE 连接，session_id 通过 endpoint 事件推送，无官方统一管理规范。
- 安全与扩展：基础 OAuth 2.0 授权，无强制安全要求；工具定义仅支持基础 JSON Schema。
- 局限：SSE 长连接资源占用高，高并发易瓶颈；断连后会话丢失，任务需重跑。
2025-03-26（核心升级版）
- 传输革命：推出 Streamable HTTP 单端点
/mcp，支持同步响应 + 按需 SSE 流，传输完成关闭连接，解决长连接浪费。
- 安全强化：升级 OAuth 2.1，废弃隐式授权，强制 PKCE 与 HTTPS，降低 Token 泄露风险。
- 功能扩展：新增工具注解（如 read-only、destructive）、JSON-RPC 批处理、音频内容支持、进度消息优化。
- 兼容性：服务端需同时保留双端点（兼容旧客户端）和单端点（新客户端），官方不建议融合。
2025-06-18（稳定优化版）
- 传输优化：强化 Streamable HTTP 会话恢复，支持 Last-Event-ID 续传未完成消息。
- 功能调整：移除 JSON-RPC 批处理（减少复杂性），完善 Elicitation 协议，支持主动向用户询问参数确认。
- 会话规范：明确 Mcp-Session-Id 生成、携带、终止规则，客户端可通过 DELETE 请求主动终止会话。
- 错误处理：规范 400（缺会话 ID）、404（会话终止）等响应码，提升排查效率。
2025-11-25（生态扩展版）
- 生态适配：标准化 Streamable HTTP 配置格式，确保多客户端解析一致性。
- 交互增强：支持 URL 模式 Elicitation，优化枚举类型 Schema，适配表单与单选 / 多选场景。
- 安全扩展：支持 OpenID Connect 服务发现，三种客户端注册机制，提升认证灵活性。
- 运维优化：动态健康检查替代静态 status 字段，确保注册表数据可信度。
Ref
Prev
Nginx
Next
Knative Architecture
Loading...