MCP最大更新移除许多服务器依赖的机制
内容提要
MCP协议将迎来重大更新，移除会话和初始化握手，简化远程服务器部署。新设计让每个请求独立，通过显式句柄管理状态，支持无状态HTTP服务。缓存和扩展机制改进，Tasks转为扩展，提供12个月弃用期。此更新降低运维复杂度，但需迁移现有实现。
延伸解读
对运维的直接影响
此次更新将远程MCP服务器从有状态会话中解放出来，不再需要会话亲和性、共享会话存储或解析JSON的网关逻辑。部署可以像普通无状态HTTP服务一样，使用轮询负载均衡，滚动发布也不会使会话失效。但需注意，无状态化只解决路由问题，不保证确定性：不同副本可能因版本或数据差异返回不同结果。
显式句柄的取舍
用显式句柄（如basket_id）替代隐式会话状态，让模型能感知并组合状态，但也意味着状态会出现在提示词、日志中。因此，句柄必须绑定到已认证主体，并在每次使用时验证权限，不能视为授权凭证。这种模式虽增加了模型的可控性，却对安全设计提出了更高要求。
缓存与性能优化
新的缓存机制要求列表和读取结果包含ttlMs和cacheScope，类似HTTP缓存控制，允许客户端在指定时间内复用目录数据。同时，工具返回顺序的确定性有助于提高提示缓存命中率，可能降低延迟和token成本。但ttlMs只是新鲜度提示，不保证数据仍然有效，客户端需自行处理过期风险。
弃用与迁移风险
核心功能如Tasks和Sampling被弃用或转为扩展，迁移并非简单替换。例如，Sampling原本无需提供商凭证，直接调用提供商API则需承担凭证、计费和数据处理责任。协议提供了12个月弃用期和迁移路径，但开发者需评估现有依赖，并注意请求状态的回放跟踪和认证问题。
Q&A
MCP协议这次重大更新的核心目标是什么？
核心目标是简化MCP协议，让每个请求独立，移除会话和初始化握手，使远程服务器部署更接近无状态HTTP服务，降低运维复杂度。
MCP更新中移除了哪些机制？为什么移除？
移除了会话（Session）和初始化握手（initialization handshake）。原因是这些机制在远程、水平扩展的部署中导致会话亲和性、外部会话存储或MCP感知网关等复杂问题，增加了运维成本。
MCP更新后，服务器如何管理需要记住的状态？
通过显式句柄（explicit handle）管理状态，例如工具返回一个basket_id，模型在后续调用中将其作为普通参数传回。句柄对模型可见，可组合和传递，但需绑定认证主体并每次验证权限。
MCP更新对缓存机制有哪些改进？
受影响的list和read结果必须包含ttlMs和cacheScope，类似HTTP Cache-Control，客户端可在指定时间内缓存目录。同时要求服务器以确定性顺序返回工具，以提高提示缓存命中率，降低延迟和成本。
MCP更新中Tasks功能发生了什么变化？
Tasks从实验性核心功能被重新设计为扩展，因为生产使用暴露了设计问题。作为扩展，它可以通过能力标志或设置级版本控制演进，避免频繁破坏性变更。
MCP更新提供了多长的弃用期？
至少12个月，从功能首次标记为Deprecated的修订版开始计算。只有在存在已发布公告或记录在案的利用的安全风险时，才能缩短，且最短为90天。
MCP更新对服务器部署和运维有什么好处？
远程MCP服务器可以像常规无状态HTTP服务一样运行，例如三个副本在轮询负载均衡后无需亲和性配置，无需协议会话存储。滚动部署不会使会话失效，网关可以基于Mcp-Method和Mcp-Name进行限流或授权，无需解析请求体。
MCP更新中，客户端如何发现服务器能力？
通过新的server/discover方法，客户端可以独立查询服务器能力，可以在调用前或需要时查询。协议版本和客户端能力通过_meta字段在每个请求中传递。
MCP更新对现有实现有哪些迁移要求？
使用实验性Tasks API的开发者需要迁移到新生命周期；服务器向客户端发起请求的模式需改为Multi Round-Trip Requests模式；服务器需认证回传的requestState；Sampling和Logging等弃用功能需要寻找替代方案。
MCP更新中，Sampling功能被弃用后有什么影响？
Sampling被弃用后，服务器不能再依赖客户端进行模型采样，需要直接调用提供商API，这会使服务器成为凭证持有者、计费方和用户数据的独立处理者，增加了责任和成本。
