返回
原文
Cloudflare Blog
精选
65AI 编辑部评分，满分 100

MCP 新规范发布：从有状态转向无状态协议

2026-08-06 21:00· 1小时前· Matt Carey
AI 导读

MCP 2026-07-28 规范发布，协议全面转向无状态，移除握手、Mcp-Session-Id 和协议会话，服务器可在 Cloudflare Workers 上直接运行，无需 Durable Objects 等有状态基础设施。

推荐理由

无状态化消解了部署 MCP 服务器必须维持长连接的负担，Serverless 工作负载可直接响应工具调用，部署选项和成本结构都发生了变化。

正文 · AI 翻译

在过去一年半的时间里，模型上下文协议（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（见下文）的路径能够经受生产流量的考验。

BLOG-3384 2.png

引导（Elicitation）不再需要开放的流

MCP 服务器有时在完成请求之前需要更多信息。例如，部署工具在发布到生产环境之前可能需要审批。设计工具可能需要用户选择颜色。计费工具在退款之前可能需要确认。MCP 将这种交互称为引导（elicitation）。

此前，诸如 elicitation/create 之类的服务器发起的请求依赖于开放的流。部署此类服务器需要在流的复杂性、成本和请求超时之间进行权衡。

新协议通过多轮往返请求（Multi Round-Trip Requests，MRTR）重新设计了这一机制。服务器可以返回一个 input_required 结果，描述它需要什么。客户端收集答案，并使用该输入重试操作。原始操作随后即可完成，而双方都无需在这些请求之间保持传输会话。

这与旧的引导实现方式相比是一个破坏性变更。然而，它在运维上实现起来要简单得多，我们相信这将让更多开发者能够利用这一能力来构建丰富的智能体应用。

BLOG-3384 3.png

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 提示。工具目录现在按确定性顺序排列，使客户端能够复用这些目录，同时在重连期间保持上游提示词缓存的稳定。

BLOG-3384 .png

授权机制持续演进

新规范还收紧了 MCP 的授权机制。当服务器和客户端已有既有关系时，MCP 现在优先使用预注册客户端；对于动态注册场景，则使用客户端 ID 元数据文档（CIMD）；动态客户端注册（DCR）作为后备方案。DCR 在新实现中已被弃用，并计划在 2027 年夏季之后移除。

该规范还采用了 RFC 9207 的签发方标识。授权服务器会通告 authorization_response_iss_parameter_supported: true，并在成功的授权响应中包含 iss。客户端会将其与启动授权流程前发现的签发方进行比对。这可以防止来自一个签发方的授权响应与来自另一个签发方的响应相混淆。

还有一些不太显眼的变更，填补了生产部署中的空白。MCP 客户端现在会将规范的服务器 URI 作为 RFC 8707 中的 resource 发送到授权和令牌请求中。令牌必须面向该受众签发，并且只能由该受众接受。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、Dynamic Client Registration 以及传统的 HTTP+SSE 传输方式均在此次发布中被弃用，但现有实现拥有明确的迁移窗口期。

这项政策为团队提供了最低限度的升级规划时间，而不是被动应对突如其来的移除。同时，它也给核心协议留出了稳定空间。

新想法可以通过新的扩展框架更快地推进，而不必立即成为核心协议的一部分。MCP Apps 和企业托管授权（Enterprise-Managed Authorization）已经是扩展，而 Tasks 也已迁移过来，为可靠、长期运行的工作提供了一条路径。实现者可以根据需要随时采用这些能力。

一个带有新 SDK 的新 MCP

2025 年 11 月，我们在 Agents SDK 中引入了 createMcpHandler，它构建在 MCP TypeScript SDK 的实验性无状态模式之上。这使得仅使用工具、提示词和资源的 MCP 服务器可以部署到 Cloudflare Worker 上，从而降低复杂性和成本，并简化部署。

我们很高兴看到 createMcpHandler 随着本次发布正式进入官方 MCP TypeScript SDK！

2026 年初，我们还与 MCP 维护者合作，将 MCP TypeScript SDK 从 Node.js 重新平台化到 Web 标准之上，这有助于改善与 Bun、Deno 和 Cloudflare Workers 等替代 JavaScript 运行时的互操作性。我们为 TypeScript SDK 贡献了打包、运行时垫片和分包功能，降低了部署体积，使整个生态系统受益。

客户可以迁移到新规范，同时保持与旧规范的向后兼容。/mcp 端点同时接受新协议和来自 2025 年 Streamable HTTP 客户端的无状态请求，因此大多数客户端无需更改配置即可重新连接。

例如，2 月份我们发布了面向整个 Cloudflare API 的 Code Mode MCP Server，它使用了这种非官方无状态模式和（朗朗上口的）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，并将继续保留在那里。我们也会继续封装上游 handler，以提供面向 Worker 的接口，配备实用的默认设置和比底层 MCP TypeScript SDK 更丰富的交互模式。

下一代 MCP 已投入生产

Sentry 联合创始人兼首席产品官 David Cramer 是 MCP 前景及其早期改进机会的知名发声者。在他早期的真实世界经验中，最新的 MCP 规范兑现了这一承诺，同时回应了早期的批评。

“我们在 Cloudflare 的 SDK 上构建了 Sentry 的 MCP。非常喜欢，”Cramer 告诉我们。“我们在 7-28 规范最终定稿之前就上线了这个新版本，而且没有破坏生产环境。这一点我们也非常喜欢。这个新规范清理了认证和工具方面的一堆杂乱问题，这正是我想要的。只有当管道不再是全部故事时，agents 才会真正变得有用。”

Linear 构建了一款快速、现代的问题跟踪和项目管理工具。他们已采用 MCP，让 agents 能够以简单且安全的方式访问 Linear 数据。

“MCP 是开放标准为何重要的一个明确例证，”Linear 工程主管 Tom Moor 表示。“最新一版规范是一次重大改进，让托管 MCP 服务器变得更容易、更可靠，同时增加了亟需的功能。我仍然认为 MCP 被严重低估了——我们基于该标准构建了一次服务器，它就能与用户想带来的任何 AI 客户端配合使用。Linear 的立场一直是让你的 Linear 数据在你需要的任何地方都可访问，而共享规范让这成为可能，无需构建数百个集成。”

Anthropic 创建了 MCP，并将其捐赠给了 Agentic AI Foundation。对于这个发起该协议（MCP）的团队而言，新规范既是对其发展历程的衡量，也体现了社区如今在多大程度上推动着它继续前行。

“我们将 MCP 捐赠给 Agentic AI Foundation，是为了让它成为整个生态系统开放、厂商中立的底层基础设施。MCP 如今已成为智能体软件的基础。它是应用程序所构建的、用于连接人们日常依赖的工具和数据的层，而这是该协议自发布以来最重要的一次进展。客户端只需极少的工程工作，就能获得显著的性能提升。

安全性遵循与保护互联网其他部分相同的、久经验证的标准。来自整个社区的维护者和贡献者，凭借在企业级规模下积累的真实生产经验，才让这一切成为可能。我们迫不及待地想看到开发者们基于 MCP 构建出什么。” MCP 联合创始人兼首席维护者、Anthropic 技术团队成员 David Soria Parra 表示。

MCP 长存

新的 MCP 规范今天已在 Cloudflare 上同时面向客户端和服务器端提供。你可以在 Cloudflare Worker 中运行无状态的 MCP 服务器，使用 Workers OAuth Provider 进行安全保护，并在智能体中连接到 MCP 客户端。当你的应用确实需要协调状态时，可使用 Cloudflare Durable Objects，并在用户迁移期间，从同一条路由同时服务新的和旧的无状态客户端。

安装最新的 Agents SDK 和 MCP TypeScript 服务器 SDK，按照迁移指南操作，或从 createMcpHandler 文档开始。你也可以连接到 Cloudflare 的 MCP 服务器，这些服务器已支持新规范。

MCP 不再需要依赖有状态的基础设施来完成有用的、交互式的工作。服务器可以像普通的 HTTP 工作负载一样在 Workers 上运行，靠近用户，并具备开发者用于互联网其他部分的规模、安全性和可观测性基础能力。

智能体行业动态

来源：Cloudflare Blog · blog.cloudflare.com

导出 Markdown
返回
精选65打开原文
导出 Markdown

MCP 新规范发布：从有状态转向无状态协议

Cloudflare Blog·2026-08-06 21:00·1小时前·Matt Carey
AI 导读

MCP 2026-07-28 规范发布，协议全面转向无状态，移除握手、Mcp-Session-Id 和协议会话，服务器可在 Cloudflare Workers 上直接运行，无需 Durable Objects 等有状态基础设施。

正文 · AI 翻译

在过去一年半的时间里，模型上下文协议（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（见下文）的路径能够经受生产流量的考验。

BLOG-3384 2.png

引导（Elicitation）不再需要开放的流

MCP 服务器有时在完成请求之前需要更多信息。例如，部署工具在发布到生产环境之前可能需要审批。设计工具可能需要用户选择颜色。计费工具在退款之前可能需要确认。MCP 将这种交互称为引导（elicitation）。

此前，诸如 elicitation/create 之类的服务器发起的请求依赖于开放的流。部署此类服务器需要在流的复杂性、成本和请求超时之间进行权衡。

新协议通过多轮往返请求（Multi Round-Trip Requests，MRTR）重新设计了这一机制。服务器可以返回一个 input_required 结果，描述它需要什么。客户端收集答案，并使用该输入重试操作。原始操作随后即可完成，而双方都无需在这些请求之间保持传输会话。

这与旧的引导实现方式相比是一个破坏性变更。然而，它在运维上实现起来要简单得多，我们相信这将让更多开发者能够利用这一能力来构建丰富的智能体应用。

BLOG-3384 3.png

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 提示。工具目录现在按确定性顺序排列，使客户端能够复用这些目录，同时在重连期间保持上游提示词缓存的稳定。

BLOG-3384 .png

授权机制持续演进

新规范还收紧了 MCP 的授权机制。当服务器和客户端已有既有关系时，MCP 现在优先使用预注册客户端；对于动态注册场景，则使用客户端 ID 元数据文档（CIMD）；动态客户端注册（DCR）作为后备方案。DCR 在新实现中已被弃用，并计划在 2027 年夏季之后移除。

该规范还采用了 RFC 9207 的签发方标识。授权服务器会通告 authorization_response_iss_parameter_supported: true，并在成功的授权响应中包含 iss。客户端会将其与启动授权流程前发现的签发方进行比对。这可以防止来自一个签发方的授权响应与来自另一个签发方的响应相混淆。

还有一些不太显眼的变更，填补了生产部署中的空白。MCP 客户端现在会将规范的服务器 URI 作为 RFC 8707 中的 resource 发送到授权和令牌请求中。令牌必须面向该受众签发，并且只能由该受众接受。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、Dynamic Client Registration 以及传统的 HTTP+SSE 传输方式均在此次发布中被弃用，但现有实现拥有明确的迁移窗口期。

这项政策为团队提供了最低限度的升级规划时间，而不是被动应对突如其来的移除。同时，它也给核心协议留出了稳定空间。

新想法可以通过新的扩展框架更快地推进，而不必立即成为核心协议的一部分。MCP Apps 和企业托管授权（Enterprise-Managed Authorization）已经是扩展，而 Tasks 也已迁移过来，为可靠、长期运行的工作提供了一条路径。实现者可以根据需要随时采用这些能力。

一个带有新 SDK 的新 MCP

2025 年 11 月，我们在 Agents SDK 中引入了 createMcpHandler，它构建在 MCP TypeScript SDK 的实验性无状态模式之上。这使得仅使用工具、提示词和资源的 MCP 服务器可以部署到 Cloudflare Worker 上，从而降低复杂性和成本，并简化部署。

我们很高兴看到 createMcpHandler 随着本次发布正式进入官方 MCP TypeScript SDK！

2026 年初，我们还与 MCP 维护者合作，将 MCP TypeScript SDK 从 Node.js 重新平台化到 Web 标准之上，这有助于改善与 Bun、Deno 和 Cloudflare Workers 等替代 JavaScript 运行时的互操作性。我们为 TypeScript SDK 贡献了打包、运行时垫片和分包功能，降低了部署体积，使整个生态系统受益。

客户可以迁移到新规范，同时保持与旧规范的向后兼容。/mcp 端点同时接受新协议和来自 2025 年 Streamable HTTP 客户端的无状态请求，因此大多数客户端无需更改配置即可重新连接。

例如，2 月份我们发布了面向整个 Cloudflare API 的 Code Mode MCP Server，它使用了这种非官方无状态模式和（朗朗上口的）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，并将继续保留在那里。我们也会继续封装上游 handler，以提供面向 Worker 的接口，配备实用的默认设置和比底层 MCP TypeScript SDK 更丰富的交互模式。

下一代 MCP 已投入生产

Sentry 联合创始人兼首席产品官 David Cramer 是 MCP 前景及其早期改进机会的知名发声者。在他早期的真实世界经验中，最新的 MCP 规范兑现了这一承诺，同时回应了早期的批评。

“我们在 Cloudflare 的 SDK 上构建了 Sentry 的 MCP。非常喜欢，”Cramer 告诉我们。“我们在 7-28 规范最终定稿之前就上线了这个新版本，而且没有破坏生产环境。这一点我们也非常喜欢。这个新规范清理了认证和工具方面的一堆杂乱问题，这正是我想要的。只有当管道不再是全部故事时，agents 才会真正变得有用。”

Linear 构建了一款快速、现代的问题跟踪和项目管理工具。他们已采用 MCP，让 agents 能够以简单且安全的方式访问 Linear 数据。

“MCP 是开放标准为何重要的一个明确例证，”Linear 工程主管 Tom Moor 表示。“最新一版规范是一次重大改进，让托管 MCP 服务器变得更容易、更可靠，同时增加了亟需的功能。我仍然认为 MCP 被严重低估了——我们基于该标准构建了一次服务器，它就能与用户想带来的任何 AI 客户端配合使用。Linear 的立场一直是让你的 Linear 数据在你需要的任何地方都可访问，而共享规范让这成为可能，无需构建数百个集成。”

Anthropic 创建了 MCP，并将其捐赠给了 Agentic AI Foundation。对于这个发起该协议（MCP）的团队而言，新规范既是对其发展历程的衡量，也体现了社区如今在多大程度上推动着它继续前行。

“我们将 MCP 捐赠给 Agentic AI Foundation，是为了让它成为整个生态系统开放、厂商中立的底层基础设施。MCP 如今已成为智能体软件的基础。它是应用程序所构建的、用于连接人们日常依赖的工具和数据的层，而这是该协议自发布以来最重要的一次进展。客户端只需极少的工程工作，就能获得显著的性能提升。

安全性遵循与保护互联网其他部分相同的、久经验证的标准。来自整个社区的维护者和贡献者，凭借在企业级规模下积累的真实生产经验，才让这一切成为可能。我们迫不及待地想看到开发者们基于 MCP 构建出什么。” MCP 联合创始人兼首席维护者、Anthropic 技术团队成员 David Soria Parra 表示。

MCP 长存

新的 MCP 规范今天已在 Cloudflare 上同时面向客户端和服务器端提供。你可以在 Cloudflare Worker 中运行无状态的 MCP 服务器，使用 Workers OAuth Provider 进行安全保护，并在智能体中连接到 MCP 客户端。当你的应用确实需要协调状态时，可使用 Cloudflare Durable Objects，并在用户迁移期间，从同一条路由同时服务新的和旧的无状态客户端。

安装最新的 Agents SDK 和 MCP TypeScript 服务器 SDK，按照迁移指南操作，或从 createMcpHandler 文档开始。你也可以连接到 Cloudflare 的 MCP 服务器，这些服务器已支持新规范。

MCP 不再需要依赖有状态的基础设施来完成有用的、交互式的工作。服务器可以像普通的 HTTP 工作负载一样在 Workers 上运行，靠近用户，并具备开发者用于互联网其他部分的规模、安全性和可观测性基础能力。

来源：Cloudflare Blog· blog.cloudflare.com