在过去一年半里，Model Context Protocol（MCP）已成为智能体与外部服务交互的通用标准。
但对 MCP 的主要批评之一是，该协议要求客户端与服务器之间保持有状态的连接。这源于 MCP 的起源，以及为本地应用设计的第一个 STDIO 传输。当 MCP 服务器走向远程时，它把在本地运行得很好的有状态连接原样搬到了 Web 基础设施上。构建一个行为良好的 MCP 服务器，意味着要管理到粘性会话的请求路由、保持流的打开、消息重放，总体而言，开销和复杂度都超过传统的 Web 服务器。现在，这一切改变了。
最新的 MCP 2026-07-28 规范已于上周发布，同时发布的还有更新后的 TypeScript、Python、Go 和 C# SDK。MCP 现在是一个完全无状态的协议。规范、交互模型和 SDK 都已重写，以利用这一新协议并简化使用。这意味着 MCP 服务器现在只需一个 Worker 就能运行，不需要有状态的基础设施，客户也能受益于更简单的运维和更少活动部件所带来的更低成本。
全新的 MCP
在 Cloudflare，我们与 MCP 的渊源可以追溯到最初。2025 年 3 月，我们发布了 McpAgent 原语，用于通过 Cloudflare Agents SDK 构建 MCP 服务器。两个月后，我们举办了 MCP Demo Day，展示了 Asana、Atlassian、Block、Intercom、Linear、PayPal、Sentry、Stripe 和 Webflow 等客户推出自己的 MCP 服务器，同时还有 13 个 Cloudflare 产品专属的 MCP 服务器。一年前，我们发布了 MCP Server Portals，帮助企业在组织内安全地采用 MCP。
Cloudflare Durable Objects 独具优势，是托管这些新应用的最佳场所。它们是有状态的服务器，把计算、持久化的事务性存储（通过内嵌的 SQLite）和实时协调结合在一起。它们可按需扩容，闲置时休眠，并保持 MCP 在智能体与人类交互时所需的有状态连接。
McpAgent 加上 Workers OAuth Provider 包，曾经是托管远程 MCP 服务器的最佳选择。然而，MCP 显然可以更简单、更高效、更易于托管，同时保留我们已经喜爱的所有能力。
MCP 2026-07-28 规范的这次发布，凝聚了整个 MCP 团队和 SDK 维护者数月的工作。在这篇文章中，我们将概述对开发者最重要的协议变更，分享在生产环境中运行它的客户的评价，并介绍如何开始使用新规范进行构建。
MCP 现在是无状态的
早期的 MCP 传输以 initialize 和 initialized 的交换开始，用来建立会话。服务器可以分配一个 Mcp-Session-Id 请求头，之后的每个请求都必须找到与该会话关联的状态。实际上，这意味着自动扩缩容的基础设施必须保留活跃会话，部署时必须排空或迁移这些会话，而丢失一个活跃实例可能迫使客户端重新连接，或导致会话中断。无服务器平台可以运行 MCP 服务器，但代价是为一个大多数交互根本用不上的协议会话增加协调机制。
新协议把必需的握手、Mcp-Session-Id 请求头和协议会话从核心请求路径中移除。每个请求都携带它所需的协议版本、客户端身份和客户端能力。希望在发出下一个请求之前先检查服务器的客户端，可以调用 server/discover，但这是可选的。
这个简单的细节改变了 MCP 服务器的部署方式。请求可以到达服务器，调用一个工具、提示词或资源，然后直接返回结果。没有需要存储的协议会话。这消除了 MCP 复杂性的很大一部分，同时保留了对它所期望的全部功能，使 MCP 服务器更易于部署、扩展和长期维护。
因此，这份新规范也不再需要 McpAgent。当应用本身需要状态时，Durable Objects 仍然是合适的原语，但 MCP 本身不再需要 Durable Object 来说这个协议。服务器可以在 Cloudflare Workers 等以请求为作用域的基础设施上更快地扩展。
Cloudflare 的 Agents SDK 从第一天起就支持新规范。在规范最终确定之前，客户和合作伙伴已经在 Cloudflare 上使用了候选版本，这让我们有信心，从 McpAgent 到新的 createMcpHandler（见下文）的迁移路径能够承载生产流量。
诱导式提问（Elicitation）不再需要打开的流
MCP 服务器有时需要更多信息才能完成一个请求。例如，部署工具可能需要先获得批准才能发布到生产环境；设计工具可能需要用户选择颜色；计费工具可能需要在发起退款前先确认。MCP 把这种交互称为诱导式提问（elicitation）。
此前，由服务器发起的请求（例如 elicitation/create）依赖于一个打开的流。部署这样的服务器，需要在流、成本和请求超时的复杂性之间权衡。
新协议用多轮往返请求（Multi Round-Trip Requests，MRTR）重做了这一机制。服务器可以返回一个 input_required 结果，描述它所需要的内容。客户端收集答案，并带着该输入重试操作。原来的操作随后便可完成，双方都无需在这些请求之间保留传输会话。
这是对旧的诱导式提问方式的破坏性变更。不过它在运维上实现起来简单得多，我们相信这会让更多开发者利用这一能力来构建丰富的智能体应用。
HTTP 基础设施能读懂 MCP
MCP 请求是通过 HTTP 发送的 JSON-RPC 消息，但此前有关请求的信息只存在于 JSON 正文内部。网关必须解析该正文，才能知道请求是在调用 tools/list、调用某个工具，还是读取某个资源。
新规范要求 Streamable HTTP 请求带有 Mcp-Method 和 Mcp-Name 请求头。例如，一次工具调用可以是这样的：
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search",
"arguments": { "q": "otters" }
}
}
网关、速率限制器或 Web 应用防火墙现在可以根据请求头做出决策，而无需解析任意的 JSON。运维人员可以对不同方法应用不同规则，或者使用他们在别处已经在用的同样的 HTTP 原语来记录工具级别的指标。
规范还为 tools/list、prompts/list、resources/list 和 resources/read 的结果增加了 ttlMs 和 cacheScope 提示。工具目录按确定的顺序排列，使客户端可以复用它们，同时让上游的提示词缓存在重新连接后保持稳定。
授权持续演进
新规范还收紧了 MCP 的授权。当服务器和客户端已经有既有关系时，MCP 现在优先采用预注册客户端，其次是用于动态注册的客户端 ID 元数据文档（Client ID Metadata Documents，CIMD），动态客户端注册（Dynamic Client Registration，DCR）作为后备。DCR 对新的实现已被弃用，并计划在 2027 年夏季之后移除。
规范还采用了 RFC 9207 的颁发者标识。授权服务器会声明 authorization_response_iss_parameter_supported: true，并在成功的授权响应中包含 iss。客户端将其与开始授权流程之前发现的颁发者进行比对。这可以防止把来自某个颁发者的授权响应与来自另一个颁发者的响应混淆。
还有一些不那么显眼的变更，弥补了生产部署中的漏洞。MCP 客户端现在会在授权请求和令牌请求中，把规范化的服务器 URI 作为 RFC 8707 的 resource 发送。令牌必须为该受众（audience）签发，也只能被该受众接受。
Workers OAuth Provider 为 Workers 上的 MCP 服务器实现了所有这些要求。只需像这样包装你的处理函数：
import { OAuthProvider } from "@cloudflare/workers-oauth-provider";
export default new OAuthProvider({
apiRoute: "/mcp",
apiHandler: mcpHandler,
defaultHandler: authorizationHandler,
authorizeEndpoint: "/authorize",
tokenEndpoint: "/oauth/token",
clientIdMetadataDocumentEnabled: true,
resourceMetadata: {
resource: "https://mcp.example.com/mcp",
authorization_servers: ["https://mcp.example.com"],
scopes_supported: ["mcp:read"],
},
});
走向成熟的标准的生命周期
技术变更只是这次发布的一部分。MCP 2026-07-28 还引入了正式的功能生命周期。
功能分为 Active（活跃）、Deprecated（弃用）或 Removed（移除）。被弃用的功能必须至少保留 12 个月，才能被移除。Roots、Sampling、Logging、动态客户端注册以及旧版 HTTP+SSE 传输，在这次发布中被弃用，但现有实现有明确的迁移窗口期。
这项政策让团队至少有一段时间来规划升级，而不是被动应对突然的移除。它也为核心协议的稳定留出了空间。
新想法可以通过新的扩展框架更快推进，而无需立即成为核心协议的一部分。MCP Apps 和企业托管授权（Enterprise-Managed Authorization）已经是扩展，而 Tasks 已被迁移出来，为可靠的长时间运行任务提供一条路径。实现者可以在需要时再采用这些能力。
全新的 MCP 与全新的 SDK
2025 年 11 月，我们基于 MCP TypeScript SDK 中的实验性无状态模式，在 Agents SDK 中推出了 createMcpHandler。这让只使用工具（tools）、提示词（prompts）和资源（resources）的 MCP 服务器可以部署到 Cloudflare Worker 上，降低复杂度和成本，部署也更轻松。
很高兴看到 createMcpHandler 在此次发布中正式并入 官方 MCP TypeScript SDK！
2026 年初，我们还与 MCP 维护者合作，把 MCP TypeScript SDK 从 Node.js 迁移到 Web 标准平台，以提升它与 Bun、Deno 和 Cloudflare Workers 等其他 JavaScript 运行时的互操作性。我们为该 TypeScript SDK 贡献了打包、运行时垫片（shim）和拆分包，缩小了部署体积，整个生态都从中受益。
客户可以迁移到新规范，同时保持对旧规范的向后兼容。/mcp 端点既接受新协议，也接受来自 2025 年 Streamable HTTP 客户端的无状态请求，因此大多数客户端无需修改配置即可重新连接。
例如，今年 2 月我们发布了覆盖整个 Cloudflare API 的 Code Mode MCP 服务器，用的就是这种非官方的无状态模式和那个（名字很上口的）WebStandardsStreamableHTTPServerTransport。此后它已扩展到每秒数千次请求，累计处理了数十亿次工具调用。
下面是使用官方 SDK 和 Cloudflare Agents SDK 的最小服务器示例：
import { McpServer } from "@modelcontextprotocol/server";
import { createMcpHandler } from "agents/mcp/server";
import { z } from "zod";
function createServer() {
const server = new McpServer({
name: "hello-server",
version: "1.0.0",
});
server.registerTool(
"hello",
{
description: "Return a greeting",
inputSchema: { name: z.string().optional() },
},
async ({ name }) => ({
content: [
{
type: "text",
text: `Hello, ${name ?? "World"}!`,
},
],
}),
);
return server;
}
export default {
fetch(request, env, ctx) {
return createMcpHandler(createServer)(request, env, ctx);
},
}
真正依赖旧版协议会话、服务器向客户端发起请求或独立流的服务器，则需要更审慎的迁移。它们可以在现有的有会话路由旁边运行一条严格无状态的路由，逐步迁移功能，等活跃会话自然结束后，再在弃用期内移除旧路径。我们的 MCP SDK v2 迁移指南涵盖了这一流程。对于 MCP 客户端，过程更简单：只需升级 agents 的版本，一切就能正常工作。
createMcpHandler API 诞生于 Agents SDK，今后也将继续留在那里。我们还会继续封装上游处理器，提供面向 Worker 的接口，它的默认值更实用，交互模式也比底层的 MCP TypeScript SDK 更丰富。
新一代 MCP 已在生产环境中运行
David Cramer 是 Sentry 的联合创始人兼首席产品官，既公开谈过 MCP 的前景，也指出过它早期有待改进之处。根据他早期的实际使用经验，最新的 MCP 规范兑现了这一前景，同时也回应了早期的批评。
“我们的 Sentry MCP 是基于 Cloudflare 的 SDK 构建的，非常喜欢。”Cramer 告诉我们，“7-28 版规范还没定稿，我们就上线了这个新版本，而且没有搞挂生产环境，这点也很让人满意。新规范清理了围绕认证和工具的一堆乱七八糟的东西，这正是我想要的。只有当底层管道不再是全部故事时，智能体才会真正有用。”
Linear 打造了一款快速、现代的问题跟踪与项目管理工具。他们采用 MCP，让智能体能够以简单、安全的方式访问 Linear 的数据。
“MCP 清楚地说明了开放标准为什么重要。”Linear 工程负责人 Tom Moor 说，“规范的最新版本是一次很大的改进，让托管 MCP 服务器更容易、更可靠，同时还补上了急需的功能。我依然认为 MCP 被严重低估了：我们基于标准构建了一次服务器，它就能配合用户想用的任何 AI 客户端。Linear 一贯主张让你的 Linear 数据在你需要的任何地方都能被访问，而这套共享规范让我们不必构建成百上千个集成就能做到这一点。”
Anthropic 创建了 MCP，并将其捐赠给 Agentic AI Foundation。对于发起这一协议的团队来说，新规范既衡量了它已走了多远，也衡量了社区现在为它出了多少力。
“我们把 MCP 捐赠给 Agentic AI Foundation，是为了让它成为整个生态系统开放、中立于厂商的基础设施。如今，MCP 已是智能体软件的基石，应用借助这一层来连接人们每天依赖的工具和数据，而这是协议自发布以来最重大的一次进步。客户端只需极少的工程工作，就能获得可观的性能提升。
安全性遵循保护互联网其他部分的同一套成熟标准。来自整个社区的维护者和贡献者借助企业级规模的真实生产经验，使这一切成为可能。我们迫不及待想看到开发者在 MCP 上构建出什么。”MCP 联合创始人兼首席维护者、Anthropic 技术团队成员 David Soria Parra 说。
MCP 万岁
新的 MCP 规范现已在 Cloudflare 上同时支持客户端和服务器。你可以在 Cloudflare Worker 中运行无状态 MCP 服务器，用 Workers OAuth Provider 保护它，并从 Agent 中的 MCP 客户端连接它。当应用确实需要协调状态时，请使用 Cloudflare Durable Objects；在用户迁移期间，可以用同一条路由同时服务新的和旧的无状态客户端。
安装最新的 Agents SDK 和 MCP TypeScript 服务器 SDK，按照迁移指南操作，或者从 createMcpHandler 文档入手。你也可以连接 Cloudflare 的 MCP 服务器，它们已经支持新规范。
MCP 不再需要有状态的基础设施，也能完成有用的交互式工作。服务器可以作为普通的 HTTP 工作负载运行在 Workers 上，靠近用户，并具备开发者在 Web 其他部分所用的扩展、安全和可观测性原语。