无状态 on Kalend's Blog

MCP RC版全面解读：无状态架构+Extensions框架+9项规范变更

Tue, 28 Jul 2026 10:00:00 +0800

MCP 的 7 月 RC，是协议诞生以来最大的一次重构。

一句话结论：MCP 从「能调用工具的协议」变成了「可大规模运行的基础设施」。 核心变化三个：无状态设计让协议具备水平扩展能力，Extensions 框架让新功能不再往核心协议里塞，三个历史包袱（Roots/Sampling/Logging）正式废弃。3000+ 现有 MCP Server（据 MCP.Directory 统计）都需要迁移。

无状态核心：握手和会话消失了

这是最根本的架构变化。SEP-2575 移除了 initialize/initialized 握手流程，SEP-2567 移除了 Mcp-Session-Id 头。两个 SEP 合在一起，把 MCP 从有状态协议变成了完全无状态的请求-响应模型。

旧方式需要两步才能开始通信：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 旧方式：先握手拿 Session-Id
POST /mcp
Content-Type: application/json

{"method": "initialize", "params": {"protocolVersion": "2026-03-26", "clientInfo": {"name": "my-client"}}}

# 响应拿到 Session-Id
{"sessionId": "abc-123", "serverInfo": {"name": "my-server"}}

# 后续每个请求必须携带
POST /mcp
Mcp-Session-Id: abc-123

{"method": "tools/list"}

新方式每个请求自包含，协议版本和客户端信息都在 _meta 中：

1
2
3
4
5
6
7


# 新方式：直接请求，无需握手
POST /mcp
Content-Type: application/json
Mcp-Method: tools
Mcp-Name: list

{"method": "tools/list", "_meta": {"protocolVersion": "2026-07-28", "clientInfo": {"name": "my-client"}}}

Session 消失了，那需要状态怎么办？答案是显式 handle。把状态管理从协议层移到应用层：

1
2
3
4
5
6
7


# 旧方式：依赖 Session-Id 存状态
session = sessions[request.headers["Mcp-Session-Id"]]
session["basket"].add_item(item)

# 新方式：通过参数显式传递 handle
basket_id = request.params["basket_id"] # 任何实例都能处理
baskets[basket_id].add_item(item)

这意味着什么？任何 MCP 请求可以落到任意 Server 实例，不再需要 sticky session。负载均衡、自动扩缩、多区域部署，全部成为可能。Uber 已经在生产环境通过 MCP Gateway 每周运行数万次 Agent 执行，验证了这条路线。

路由/缓存/追踪：三大运维优化

无状态是基础，但光有无状态还不够。三个新 SEP 解决了生产环境的实际问题。

路由头（SEP-2243）：每个请求必须携带 Mcp-Method 和 Mcp-Name 头。LB、网关、限流器无需解析 JSON body 即可路由。头和 body 不一致时服务端必须拒绝请求——这是个安全设计，防止 header spoofing。

1
2
3
4
5
6
7


# 网关直接从 header 路由，不碰 body
POST /mcp
Mcp-Method: tools
Mcp-Name: call
Content-Type: application/json

{"method": "tools/call", "params": {"name": "search", "arguments": {"query": "MCP"}}}

缓存元数据（SEP-2549）：tools/list 和 resource read 结果带 ttlMs + cacheScope，类似 HTTP 的 Cache-Control。不再需要长连接 SSE 来监听 tools/list_changed 通知，按 TTL 主动拉取即可。

1
2
3
4
5
6
7
8


# 响应带缓存元数据
{
 "tools": [...],
 "_meta": {
 "ttlMs": 300000,
 "cacheScope": "instance"
 }
}

分布式追踪（SEP-414）：_meta 中标准化 traceparent/tracestate/baggage 键名，与 W3C Trace Context 和 OpenTelemetry 兼容。跨 SDK、跨网关的端到端追踪成为标配。

三个 SEP 加在一起，MCP 的生产运维能力从「勉强能用」升级到了「大规模可运维」。再加上 SEP-2322 引入的多轮请求机制——用 InputRequiredResult 替代 SSE 流，客户端收集回答后带 inputResponses + requestState 重新发起请求，状态同样在 payload 中，任何实例都能处理——整个无状态架构的最后一块拼图补齐了。

Extensions 框架：MCP 从协议变成平台

SEP-2133 引入的 Extensions 框架是这次 RC 的另一个核心变化。之前所有新功能只能往核心协议里塞，协议越来越臃肿，版本迭代越来越慢。Extensions 把这个耦合拆开了。

设计很直接：核心协议只管通信，扩展能力按需加载。每个 Extension 用反向 DNS ID 标识（如 io.modelcontextprotocol/apps），独立版本、独立仓库（ext-* 系列），有委托维护者。新增 Extensions Track 在 SEP 流程中走规范审批。

能力协商发生在 initialize 阶段——Client 和 Server 通过 capabilities 字段声明各自支持的 extensions，取交集生效。认证模块可以独立发布 v2，不影响 Tasks 的版本节奏。

两个官方扩展：MCP Apps 和 Tasks

Extensions 框架定下来，立刻就有两个重量级扩展落地。它们代表了两个不同的扩展方向：一个扩展「表达能力」，一个扩展「时间维度」。

MCP Apps（SEP-1865）：让工具调用返回交互式 UI。Server 在 tools/list 中声明关联的 app 资源，工具调用后返回 app:// URI，Host 在沙箱 iframe 中渲染 Server 提供的 HTML，通过 postMessage 实现双向通信。Claude 和 ChatGPT 已原生支持。

举个实际场景：你有一个数据库查询工具，旧方式只能返回 JSON 文本，你需要自己解析、自己拼表格。有了 MCP Apps，同一个工具可以直接返回一个可排序、可筛选的交互式表格界面——你在对话窗口里直接操作，不用切到别的应用。Server 开发者只需按规范打包前端资源，Client 端负责渲染和沙箱隔离，安全边界很清晰。官方仓库在 github.com/modelcontextprotocol/ext-apps。

Tasks（SEP-2663）：从 2025 年 11 月的实验功能正式毕业为独立扩展。tools/call 不再同步阻塞等结果，而是返回异步 task handle。Client 通过 tasks/get 轮询状态，支持 tasks/update 推送进度、tasks/cancel 取消。注意：tasks/list 被移除了——在无会话设计下无法安全作用域。

创建模式是 server-directed：客户端声明支持 Tasks 扩展，服务端决定哪些调用作为 task 处理。这对长时间运行的操作（模型训练、大规模数据处理、编译任务）很有价值——Agent 可以同时发起多个长任务，轮流检查进度，而不是排队阻塞等待。从串行等待变成并行管理，用户体验完全不同。

两者共同指向一个方向：MCP 从只能传文本数据的管道，变成了能渲染 UI、能管理异步任务的平台。

授权加固：2 个 SEP 补齐安全短板

MCP 的授权一直被诟病「不够严谨」。这次 RC 用 2 个 SEP 补齐：

SEP	内容	解决什么问题
SEP-2468	iss 参数验证（RFC 9207）	防 mix-up 攻击
SEP-2207	OIDC refresh token 指南	明确 offline_access scope 下的 refresh token 行为

这两个 SEP 把 MCP 的安全模型从「能用」变成了「可审计」。

废弃清单：Roots、Sampling、Logging 正式退役

SEP-2577 定义了三个功能的废弃路线。注解级废弃（不是立即删除），12 个月移除窗口。

废弃功能	替代方案	理由
Roots	Tool 参数传路径、Resource URI、服务端配置	无状态架构下不需要客户端告知文件系统根目录
Sampling	直接集成 LLM provider API	Server 端直接调用模型 API 更高效、更可控
Logging	stderr（stdio 模式）/ OpenTelemetry（结构化日志）	行业标准方案，不需要协议层自建

如果你的 Server 还在用这三个功能，现在就该动手迁移了。12 个月听着长，但 Tier 1 SDK 需要在 10 周窗口内发布支持，生态倒逼的速度会比你想象得快。

迁移行动指南

阶段	时间	做什么
现在	7月	读 draft spec，审计 auth 代码，检查是否依赖 Roots/Sampling/Logging
6 周内	8月	用 RC SDK 重建 Server，验证路由头和缓存元数据
10 周内	9月	部署无状态变体，测试自动扩缩，声明新协议版本
12 个月后	2027年7月	废弃功能正式移除，确保迁移完成

最优先的改动：移除 initialize 握手和 Mcp-Session-Id 依赖，改用 _meta 传递协议信息。这是所有其他变更的前提。如果你的 Server 框架（如 FastMCP）还没有发布 RC 兼容版本，关注框架的更新动态，等框架适配后再动手会省很多力气。

其次是检查授权代码——2 个 SEP 涉及 OAuth/OIDC 流程的细节改动，如果授权实现不规范，安全审计这关过不去。

最后别忘了 JSON Schema 升级到 2020-12（SEP-2106），支持 oneOf/anyOf/allOf/$ref/$defs。错误码也有调整：-32002 改为 -32602（SEP-2164），和 JSON-RPC 规范对齐。

结语

这次 RC 的意义不只是「改了 9 个东西」。MCP 从一个原型友好的实验协议，转型为可大规模运行的基础设施。无状态核心让它能水平扩展，Extensions 框架让它能持续演进，授权加固让它能过安全审计。Apple Safari 技术预览版 247 已支持 MCP，Linux Foundation 已接手协议托管——这些信号说明 MCP 的生态位已经从「Anthropic 的项目」变成了「行业基础设施」。

对于正在使用或计划使用 MCP 的开发者，协议刚定型、生态还在早期，现在介入的门槛和成本都比较低。

作者：varkm

MCP RC 迁移实战：Roots/Sampling/Logging 废弃后的代码改造指南

Mon, 13 Jul 2026 08:30:00 +0800

MCP 的 7 月 RC 不是小版本迭代，是协议诞生以来最大的一次重构。3000+ 现有 MCP Server 都需要迁移，Roots、Sampling、Logging 三个核心功能直接废弃。如果你在维护 MCP Server，现在就该动手了。

一、为什么这次升级必须重视

RC 锁定日期是 2026-05-21，正式版 2026-07-28。核心变化就一句话：从有状态变成无状态。

项目	旧协议	RC 协议
会话模型	服务端维护 Session-Id，需要 sticky session	完全无状态，任何请求可落到任意实例
初始化流程	initialize 握手 → 拿 Session-Id → 后续携带	每个请求自包含，协议版本在 `_meta` 中
影响范围	—	3000+ MCP Server（MCP.Directory 统计）
废弃窗口	—	12 个月（不是立即删除，但现在就要准备）

时间线很清晰：5 月锁定 → 7 月 28 日发布 → 12 个月后移除废弃功能。 Tier 1 SDK 需要在 10 周窗口内发布支持。

二、5 个 Breaking Changes 详解

每个 Breaking Changes 都有旧代码 vs 新代码对比，不是纯文字描述。

2.1 移除 initialize 握手（SEP-2575）

旧方式需要两步握手才能拿到 Session-Id，新方式每个请求直接带协议信息：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# ❌ 旧方式：initialize 握手
async def handle_mcp_request(request):
 if request.method == "initialize":
 session_id = generate_session_id()
 sessions[session_id] = {"client": request.params}
 return {"sessionId": session_id, "serverInfo": {...}}
 
 # 后续请求必须携带 Session-Id
 session_id = request.headers.get("Mcp-Session-Id")
 if not session_id or session_id not in sessions:
 return error("Invalid session")

# ✅ 新方式：每个请求自包含
async def handle_mcp_request(request):
 # 不再需要 initialize，协议版本和客户端信息在 _meta 中
 protocol_version = request.meta.get("protocolVersion")
 client_info = request.meta.get("clientInfo")
 # 直接处理业务逻辑
 return process_request(request)

改造要点：删除 initialize/initialized 的处理逻辑，从 _meta 中读取协议版本和客户端信息。

2.2 移除 Mcp-Session-Id（SEP-2567）

这是最根本的变化——从有状态变无状态：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# ❌ 旧方式：服务端维护会话状态
class McpServer:
 def __init__(self):
 self.sessions = {} # 有状态，需要 sticky session
 
 def handle(self, request):
 sid = request.headers["Mcp-Session-Id"]
 session = self.sessions[sid]
 # session 上下文用于后续请求...

# ✅ 新方式：完全无状态
class McpServer:
 def handle(self, request):
 # 没有 session，每个请求独立处理
 # 需要状态？用应用层 handle
 basket_id = request.params.get("basket_id")
 # 状态通过参数显式传递，任何实例都能处理

改造要点：把状态管理从协议层移到应用层。如果你的 Server 依赖 Session-Id 存状态（比如购物篮、浏览器上下文），改用显式 handle（basket_id、browser_id 等）。

2.3 新增路由头（SEP-2243）

每个请求必须携带 Mcp-Method 和 Mcp-Name 头，让 LB/网关/限流器无需解析 body 即可路由：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# ❌ 旧方式：网关需要解析 JSON body 才能路由
def route_request(request):
 body = json.loads(request.body)
 method = body.get("method") # 必须解析 body
 if method.startswith("tools/"):
 return forward_to_tools_server(request)

# ✅ 新方式：从路由头直接判断
def route_request(request):
 mcp_method = request.headers.get("Mcp-Method")
 mcp_name = request.headers.get("Mcp-Name")
 
 # 无需解析 body，直接路由
 if mcp_method == "tools" and mcp_name == "call":
 return forward_to_tools_server(request)

注意：头和 body 不一致时，服务端必须拒绝请求。这是个安全设计——防止 header spoofing。

2.4 缓存元数据（SEP-2549）

tools/list 和 resource read 结果现在带 ttlMs + cacheScope，类似 HTTP 的 Cache-Control：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# ❌ 旧方式：需要长连接 SSE 来发现列表变更
async def watch_tools(client):
 async for event in client.subscribe("notifications/tools/list_changed"):
 tools = await client.call("tools/list")
 update_tools_cache(tools)

# ✅ 新方式：缓存元数据，按 TTL 刷新
async def get_tools(client):
 result = await client.call("tools/list")
 tools = result["tools"]
 ttl_ms = result.get("meta", {}).get("ttlMs", 60000)
 cache_scope = result.get("meta", {}).get("cacheScope", "instance")
 # 在 ttl_ms 内使用缓存，过期再请求
 return tools

改造要点：移除 tools/list_changed 的 SSE 监听逻辑，改用 TTL 主动拉取。

2.5 多轮请求（SEP-2322）

InputRequiredResult 替代 SSE 流，客户端收集回答后带 inputResponses + requestState 重新发起请求：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# ❌ 旧方式：通过 SSE 流收集多轮输入
async def handle_tool_call(client, tool_call):
 async for chunk in client.stream(tool_call):
 if chunk.type == "input_required":
 user_input = await collect_user_input(chunk.prompt)
 # 通过同一个 SSE 流回传...
 await client.send_input(user_input)

# ✅ 新方式：请求-响应模式，状态在 payload 中
async def handle_tool_call(client, tool_call):
 result = await client.call("tools/call", tool_call)
 
 if result.get("type") == "inputRequired":
 # 收集用户输入
 user_input = await collect_user_input(result["prompt"])
 # 带 inputResponses + requestState 重新发起
 result = await client.call("tools/call", {
 **tool_call,
 "inputResponses": [{"promptId": result["promptId"], "value": user_input}],
 "requestState": result["requestState"]
 })
 
 return result

关键设计：状态在 payload 中，任何实例都能处理（和无状态架构一致）。

三、3 个废弃功能 + 替代方案

这是每个 MCP Server 开发者都会遇到的问题。废弃 ≠ 立即删除，但 12 个月后就真没了。

3.1 Roots 废弃

Roots 让服务端声明文件系统根目录，客户端通过 roots/list_changed 通知变更。替代方案有三种：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


# ❌ 旧方式：Roots 能力声明
server = McpServer(
 capabilities={
 "roots": {"listChanged": True}
 }
)

# 客户端通过 roots 通知路径变更
await client.notify("notifications/roots/list_changed")

# ✅ 替代方案 1：Tool 参数传路径
@tool("read_file", description="读取文件内容")
async def read_file(path: str):
 # 路径作为参数显式传递
 return open(path).read()

# ✅ 替代方案 2：Resource URI 声明
@resource("file://{path}")
async def get_file(path: str):
 return open(path).read()

# ✅ 替代方案 3：服务端配置文件
# 在 MCP Server 启动时读取配置
config = load_config("~/.mcp-server/config.yaml")
base_dir = config.get("base_dir", "/workspace")

改造建议：如果你的 Server 依赖 Roots 来确定工作目录，用 Tool 参数最简单。

3.2 Sampling 废弃

Sampling 让服务端通过 sampling/createMessage 请求客户端采样（即调用 LLM）。替代方案：服务端直接集成 LLM API。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# ❌ 旧方式：请求客户端采样
@tool("analyze_text")
async def analyze_text(text: str):
 # 服务端不能自己调模型，必须请求客户端
 result = await request_client_sampling(
 messages=[{"role": "user", "content": f"分析：{text}"}],
 model="claude-sonnet-4"
 )
 return result.content

# ✅ 新方式：服务端直接集成 LLM
from anthropic import Anthropic

client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

@tool("analyze_text")
async def analyze_text(text: str):
 # 服务端自己调模型，不再依赖客户端
 response = client.messages.create(
 model="claude-sonnet-4",
 max_tokens=1024,
 messages=[{"role": "user", "content": f"分析：{text}"}]
 )
 return response.content[0].text

改造要点：移除 sampling/createMessage handler，接入 OpenAI/Anthropic/其他 LLM provider 的 SDK。API Key 通过环境变量注入。

3.3 Logging 废弃

协议层的 logging/setLevel 控制日志级别，替代方案：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


# ❌ 旧方式：协议层日志控制
@method("logging/setLevel")
async def set_log_level(level: str):
 # 通过 MCP 协议控制日志级别
 logging.getLogger("mcp").setLevel(level)

@method("notifications/message")
async def log_message(level: str, message: str, logger: str = None):
 # 日志通过协议通知发送
 await send_notification("notifications/message", {
 "level": level,
 "message": message,
 "logger": logger
 })

# ✅ 替代方案 1：stdio 用 stderr
import sys
import logging

logger = logging.getLogger("mcp-server")
handler = logging.StreamHandler(sys.stderr) # stdio 模式用 stderr
handler.setFormatter(logging.Formatter('%(asctime)s %(levelname)s %(message)s'))
logger.addHandler(handler)
logger.setLevel(logging.INFO)

# ✅ 替代方案 2：远程用 OpenTelemetry
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

provider = TracerProvider()
processor = BatchSpanProcessor(OTLPSpanExporter(endpoint="http://otel-collector:4317"))
provider.add_span_processor(processor)
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("mcp-server")

改造建议：stdio 模式直接用 stderr + 标准 logging；HTTP/SSE 模式用 OpenTelemetry 结构化日志，和 SEP-414 的分布式追踪配合。

四、迁移检查清单

按时间线拆解，每一步都有具体的检查项和验证方法。

时间	检查什么	怎么改	改完怎么验
现在（6月前）	读 draft spec，审计 auth 代码	标记所有 `initialize`、`Session-Id`、Roots/Sampling/Logging 调用点	`grep -rn "initialize\|Session-Id\|roots\|sampling\|logging" src/`
6 月	用 RC SDK 重建，验证路由头	升级 SDK，添加 `Mcp-Method`/`Mcp-Name` 头	抓包验证每个请求都带路由头，头和 body 一致
7 月	部署无状态变体，测试自动扩缩	移除 session 管理，状态改应用层 handle	多实例部署，任意请求落到任意实例都能正常返回
7月28日+	声明新协议版本，保持废弃功能可用	`protocolVersion` 更新为 RC 版本	12 个月内新旧功能并行，监控废弃功能调用量

具体验证命令：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# 1. 审计代码中的废弃功能调用
grep -rn "initialize\|initialized\|Session-Id\|roots\|sampling\|logging/setLevel" src/

# 2. 检查是否还有 session 状态
grep -rn "sessions\[" src/ # 如果有，需要改造成应用层 handle

# 3. 验证路由头
curl -X POST http://localhost:3000/mcp \
 -H "Content-Type: application/json" \
 -H "Mcp-Method: tools" \
 -H "Mcp-Name: list" \
 -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

# 4. 测试无状态：发同一个请求到不同实例
for port in 3001 3002 3003; do
 curl -s "http://localhost:$port/mcp" \
 -H "Mcp-Method: tools" -H "Mcp-Name: list" \
 -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | jq '.result.tools | length'
done

五、总结

这次 RC 升级的核心逻辑就一条：无状态 = 水平扩展友好。

三个关键认知：

废弃 ≠ 删除。 12 个月窗口内旧功能仍可用，但新开发应该直接用新方案
状态不是消失了，是下沉到应用层。 Session-Id 移除后，你的 basket_id、browser_id 等显式 handle 更清晰
现在就开始。 7 月 28 日发布后，Tier 1 SDK 会在 10 周内跟进，你的 Server 应该在 SDK 生态更新前完成适配

建议：先跑一遍上面的 grep 审计，标记所有需要改的地方。然后按检查清单的时间线逐步推进。别等到正式版发布才动手——那时候你会同时面对 SDK 升级 + 协议适配 + 用户反馈，手忙脚乱。