GitHub 于 2026 年 7 月 23 日介绍 GitHub MCP Server 对下一版 Model Context Protocol 规范的支持。公告指出，MCP protocol 预计在 7 月 28 日转向 stateless core，而 GitHub MCP Server 已在正式发布前完成相应更新。
对于 agent 系统来说，最重要的变化不是名称，而是连接状态的处理方式。GitHub 描述的新核心移除 sessions 和 initialize，让 client 可以更快连接 server，并可以并行完成 handshake。公告还提到，新的 extensions 为 MCP apps 和 Enterprise Managed Auth 等能力提供空间，多轮 HTTP request 则让 remote server 可以支持 elicitation 等互动。
GitHub 为配合新规范做了三项具体调整。第一，移除 Redis sessions，initialize 不再写入数据库，每次调用也不再读取数据库。第二，避免在 SDK 处理前深入检查每个 request payload；需要用于 logging 和 secret scanning 的数据，改从规范保证存在的 HTTP headers 读取。第三，更新 elicitation 实现，让 stdio MCP server 的 URL login 可以配合新旧 client，并由 Go SDK wrapper 同时处理两种机制。
这些改动显示 MCP server 的可靠性开始由「一个长时间保存状态的连接」转向「可水平扩展的 request、身份和工具协议」。对于多个 agent、remote tool 或跨区域部署来说，少一层 session state 可以简化扩展；但状态并没有消失，而是需要由 client、身份系统、外部数据存储和每次操作的语义共同处理。
另一个值得留意的部分是官方 conformance tests。GitHub 表示，新规范提供测试套件，让 agent 可以协助检查 client、server、draft spec 和 tier 1 SDK 是否符合预期。这对于 MCP 生态很重要，因为只靠「模型成功调用一次工具」不足以证明在错误、重试、认证、elicitation 和版本切换时仍然可靠。
不过，这篇是 GitHub 的产品公告，不能独立证明所有 MCP server 都会在 7 月 28 日以相同方式切换。供应商提到的向后兼容性、性能改善和不需采取行动等说法，仍应配合实际使用的 SDK 版本、client 行为、proxy、认证流程及企业网络政策核对。Stateless transport 也不等于自动安全；权限最小化、secret redaction、审计和工具输入验证仍需要在应用层设计。
对于开发团队来说，这次更新可以作为一个检查点：先盘点是否依赖 server-side session，是否把 auth 或交易上下文错误放在 initialize，是否有 proxy 会改写 headers，以及是否已经有跨版本 conformance test。MCP 的下一步不只在于让 agent 接更多工具，也在于让这些工具连接可以被测试、扩展和治理。
