MCP công bố chuẩn mới: Chuyển đổi toàn diện sang giao thức không trạng thái

Trong hơn một năm rưỡi qua, Model Context Protocol (MCP) đã trở thành tiêu chuẩn phổ quát cho cách các tác nhân (agents) tương tác với các dịch vụ bên ngoài.

Tuy nhiên, một trong những chỉ trích chính đối với MCP là giao thức này yêu cầu kết nối có trạng thái (stateful) giữa Client và Server. Điều này xuất phát từ nguồn gốc của MCP và phương thức truyền tải STDIO đầu tiên, vốn được thiết kế cho các ứng dụng cục bộ. Khi các MCP Server chuyển sang chạy từ xa, nó đã chuyển đổi kết nối có trạng thái vốn hoạt động rất tốt ở cục bộ sang hạ tầng web. Việc xây dựng một MCP Server vận hành tốt đồng nghĩa với việc phải quản lý định tuyến yêu cầu đến các phiên làm việc cố định (sticky sessions), duy trì các luồng mở, phát lại tin nhắn và nhìn chung là tốn nhiều chi phí vận hành và phức tạp hơn so với một máy chủ web truyền thống. Giờ đây, mọi thứ đã thay đổi.

Đặc tả MCP 2026-07-28 mới nhất đã được phát hành vào tuần trước, cùng với các SDK cập nhật cho TypeScript, Python, Go và C#. MCP hiện là một giao thức hoàn toàn không trạng thái (stateless). Đặc tả, mô hình tương tác và các SDK đều đã được viết lại để tận dụng giao thức mới này và đơn giản hóa việc sử dụng. Điều này có nghĩa là các MCP server hiện có thể chạy chỉ trong một Worker mà không cần hạ tầng có trạng thái, đồng thời khách hàng được hưởng lợi từ sự đơn giản trong vận hành và giảm chi phí nhờ ít thành phần chuyển động hơn.

Một MCP mới

Tại Cloudflare, hành trình của chúng tôi với MCP bắt đầu ngay từ những ngày đầu tiên. Vào tháng 3 năm 2025, chúng tôi đã phát hành primitive McpAgent để xây dựng các MCP server với Cloudflare Agents SDK. Hai tháng sau, chúng tôi đã tổ chức một buổi MCP Demo Day, giới thiệu các khách hàng như Asana, Atlassian, Block, Intercom, Linear, PayPal, Sentry, Stripe và Webflow đang triển khai các MCP Server của riêng họ cùng với 13 MCP server dành riêng cho sản phẩm của Cloudflare. Một năm trước, chúng tôi đã phát hành MCP Server Portals để giúp các doanh nghiệp áp dụng MCP một cách an toàn trong tổ chức của họ.

Cloudflare Durable Objects có vị thế độc nhất để trở thành nơi lưu trữ tốt nhất cho các ứng dụng mới này. Đây là các máy chủ có trạng thái kết hợp giữa tính toán, lưu trữ giao dịch bền vững (thông qua SQLite nhúng) và điều phối thời gian thực. Chúng tự động mở rộng theo nhu cầu, chuyển sang chế độ ngủ khi không sử dụng và duy trì kết nối có trạng thái cần thiết cho MCP trong tương tác giữa Tác nhân và Con người (Agent-to-Human).

McpAgent kết hợp với gói Workers OAuth Provider là nơi tốt nhất để lưu trữ các MCP server từ xa. Tuy nhiên, rõ ràng là MCP có thể trở nên đơn giản hơn, hiệu quả hơn và dễ lưu trữ hơn, trong khi vẫn giữ lại tất cả các khả năng mà chúng ta đã yêu thích.

Bản phát hành đặc tả MCP 2026-07-28 này là thành quả của nhiều tháng làm việc bởi toàn bộ đội ngũ MCP và những người duy trì SDK. Trong bài viết này, chúng tôi sẽ phác thảo những thay đổi về giao thức quan trọng nhất đối với các nhà phát triển, chia sẻ lời chứng thực từ các khách hàng đang chạy nó trong môi trường thực tế (production) và giải thích cách bắt đầu xây dựng với đặc tả mới.

MCP hiện đã không trạng thái (stateless)

Các phương thức truyền tải MCP trước đây bắt đầu bằng việc trao đổi initialize và initialized để khởi tạo một phiên làm việc. Một server có thể gán tiêu đề Mcp-Session-Id và mọi yêu cầu tiếp theo đều phải tìm trạng thái liên quan đến phiên đó. Trên thực tế, điều này có nghĩa là hạ tầng tự động mở rộng (autoscaling) phải duy trì các phiên đang hoạt động, các bản triển khai phải rút cạn (drain) hoặc di chuyển chúng, và việc mất một instance đang hoạt động có thể buộc các client phải kết nối lại hoặc dẫn đến các phiên bị lỗi. Các nền tảng serverless có thể chạy MCP server, nhưng chỉ bằng cách thêm sự điều phối cho một phiên giao thức mà hầu hết các tương tác thậm chí không cần đến.

Giao thức mới loại bỏ quá trình bắt tay (handshake) bắt buộc, tiêu đề Mcp-Session-Id và các phiên giao thức khỏi luồng yêu cầu cốt lõi. Mỗi yêu cầu mang theo phiên bản giao thức, danh tính client và các khả năng (capabilities) của client mà nó cần. Một client muốn kiểm tra server trước khi thực hiện yêu cầu khác có thể gọi server/discover, nhưng đây là tùy chọn.

Chi tiết đơn giản đó thay đổi cách một MCP server có thể được triển khai. Một yêu cầu có thể đến server, gọi một công cụ (tool), lời nhắc (prompt) hoặc tài nguyên (resource) và chỉ cần trả về kết quả. Không có phiên giao thức nào cần lưu trữ. Điều này loại bỏ một phần lớn sự phức tạp của MCP, trong khi vẫn bảo toàn tất cả các chức năng được mong đợi, giúp các MCP server dễ triển khai, mở rộng và bảo trì hơn theo thời gian.

Do đó, đặc tả mới này cũng loại bỏ nhu cầu về McpAgent. Mặc dù Durable Objects vẫn là primitive phù hợp khi bản thân ứng dụng cần trạng thái, nhưng chính MCP không còn yêu cầu Durable Object để giao tiếp theo giao thức này nữa. Các server có thể mở rộng nhanh hơn trên hạ tầng theo phạm vi yêu cầu (request scoped) như Cloudflare Workers.

Agents SDK của Cloudflare đã hỗ trợ đặc tả mới ngay từ ngày đầu tiên. Khách hàng và đối tác đã sử dụng bản phát hành thử nghiệm (release candidate) trên Cloudflare trước khi đặc tả được hoàn thiện, mang lại cho chúng tôi sự tự tin rằng lộ trình di chuyển từ McpAgent sang createMcpHandler mới (xem bên dưới) hoạt động tốt với lưu lượng truy cập thực tế.

Elicitation không còn cần một luồng mở

Một MCP server đôi khi cần thêm thông tin trước khi có thể hoàn thành một yêu cầu. Ví dụ, một công cụ triển khai có thể cần sự phê duyệt trước khi phát hành lên môi trường production. Một công cụ thiết kế có thể cần người dùng chọn màu sắc. Một công cụ thanh toán có thể cần xác nhận trước khi hoàn tiền. MCP gọi tương tác này là elicitation (khơi gợi thông tin).

Trước đây, các yêu cầu do server khởi tạo như elicitation/create phụ thuộc vào một luồng mở. Việc triển khai một server như vậy đòi hỏi phải cân bằng sự phức tạp xung quanh các luồng, chi phí và thời gian chờ yêu cầu (request timeouts).

Giao thức mới làm lại điều này với Multi Round-Trip Requests (MRTR). Một server có thể trả về kết quả input_required mô tả những gì nó cần. Client thu thập câu trả lời và thử lại thao tác với dữ liệu đầu vào đó. Thao tác ban đầu sau đó có thể hoàn tất mà không cần bên nào phải duy trì phiên truyền tải giữa các yêu cầu đó.

Đây là một thay đổi mang tính đột phá so với cách thực hiện elicitation cũ. Tuy nhiên, nó đơn giản hơn nhiều về mặt vận hành để triển khai và chúng tôi tin rằng nó sẽ cho phép nhiều nhà phát triển tận dụng khả năng này để xây dựng các ứng dụng tác nhân phong phú.

Hạ tầng HTTP hiểu được MCP

Các yêu cầu MCP là các thông điệp JSON-RPC được gửi qua HTTP, nhưng thông tin về yêu cầu trước đây chỉ nằm bên trong phần thân JSON. Một gateway phải phân tích phần thân đó để biết liệu một yêu cầu có gọi tools/list, gọi một công cụ hay đọc một tài nguyên hay không.

Đặc tả mới yêu cầu các tiêu đề Mcp-Method và Mcp-Name trên các yêu cầu HTTP có thể truyền phát (Streamable). Ví dụ, một lệnh gọi công cụ có thể trông như thế này:

Một gateway, bộ giới hạn tốc độ (rate limiter) hoặc Web Application Firewall hiện có thể đưa ra quyết định từ các tiêu đề mà không cần phân tích cú pháp JSON tùy ý. Người vận hành có thể áp dụng các quy tắc khác nhau cho các phương thức khác nhau hoặc ghi lại các chỉ số ở cấp độ công cụ bằng cách sử dụng chính các primitive HTTP mà họ đã sử dụng ở những nơi khác.

Đặc tả cũng thêm các gợi ý ttlMs và cacheScope vào kết quả từ tools/list, prompts/list, resources/list và resources/read. Các danh mục công cụ được sắp xếp theo cách xác định, cho phép các client tái sử dụng chúng trong khi vẫn giữ cho bộ nhớ đệm prompt ở thượng nguồn ổn định sau mỗi lần kết nối lại.

Ủy quyền (Authorization) tiếp tục phát triển

Đặc tả mới cũng thắt chặt việc ủy quyền của MCP. MCP hiện ưu tiên các client đã đăng ký trước khi server và client đã có mối quan hệ, sau đó đến Client ID Metadata Documents (CIMD) cho các đăng ký động, với Dynamic Client Registration (DCR) là phương án dự phòng. DCR đã bị loại bỏ (deprecated) đối với các triển khai mới và dự kiến sẽ bị xóa sau mùa hè năm 2027.

Đặc tả cũng áp dụng nhận dạng nhà phát hành theo RFC 9207. Một máy chủ ủy quyền sẽ quảng bá authorization_response_iss_parameter_supported: true và bao gồm iss trong các phản hồi ủy quyền thành công. Client so sánh nó với nhà phát hành đã được khám phá trước khi bắt đầu luồng ủy quyền. Điều này ngăn chặn việc phản hồi ủy quyền từ nhà phát hành này bị nhầm lẫn với phản hồi từ nhà phát hành khác.

Có một vài thay đổi ít được chú ý hơn giúp lấp đầy các khoảng trống trong các bản triển khai thực tế. Các MCP client hiện gửi URI server chuẩn làm tài nguyên RFC 8707 trong các yêu cầu ủy quyền và token. Các token phải được cấp cho và chỉ được chấp nhận bởi đối tượng đó. Workers OAuth Provider thực hiện tất cả các yêu cầu này cho các MCP server trên Workers. Chỉ cần bao bọc các hàm xử lý của bạn như sau:

Vòng đời cho một tiêu chuẩn đang hoàn thiện

Các thay đổi kỹ thuật chỉ là một phần của bản phát hành này. MCP 2026-07-28 cũng giới thiệu một vòng đời tính năng chính thức.

Các tính năng được phân loại là Active (Đang hoạt động), Deprecated (Đã lỗi thời) hoặc Removed (Đã xóa). Một tính năng đã lỗi thời phải duy trì khả dụng trong ít nhất 12 tháng trước khi có thể bị xóa. Roots, Sampling, Logging, Dynamic Client Registration và phương thức truyền tải HTTP+SSE cũ đã bị lỗi thời trong bản phát hành này, nhưng các triển khai hiện có có một khoảng thời gian di chuyển được xác định.

Chính sách này cung cấp cho các nhóm một khoảng thời gian tối thiểu để lập kế hoạch nâng cấp thay vì phải phản ứng với việc xóa bỏ đột ngột. Nó cũng tạo không gian cho giao thức cốt lõi ổn định.

Các ý tưởng mới có thể di chuyển nhanh hơn thông qua khung mở rộng mới mà không cần ngay lập tức trở thành một phần của giao thức cốt lõi. MCP Apps và Enterprise-Managed Authorization đã là các phần mở rộng, trong khi Tasks đã được chuyển sang để cung cấp lộ trình cho các công việc đáng tin cậy, chạy dài hạn. Người triển khai có thể áp dụng các khả năng đó khi cần.

Một MCP mới với các SDK mới

Vào tháng 11 năm 2025, chúng tôi đã giới thiệu createMcpHandler vào Agents SDK của mình, được xây dựng trên chế độ không trạng thái thử nghiệm trong MCP TypeScript SDK. Điều này cho phép các MCP server chỉ sử dụng công cụ, lời nhắc và tài nguyên được triển khai lên Cloudflare Worker để giảm độ phức tạp, chi phí và triển khai dễ dàng hơn.

Chúng tôi rất vui khi thấy createMcpHandler được đưa vào MCP TypeScript SDK chính thức với bản phát hành này!

Vào đầu năm 2026, chúng tôi cũng đã làm việc với những người duy trì MCP để chuyển đổi MCP TypeScript SDK từ Node.js sang Web Standards, giúp cải thiện khả năng tương tác với các môi trường chạy JavaScript thay thế như Bun, Deno và Cloudflare Workers. Chúng tôi đã đóng góp các gói bundling, runtime shims và các gói tách biệt trong TypeScript SDK, giúp giảm kích thước triển khai và mang lại lợi ích cho toàn bộ hệ sinh thái.

Khách hàng có thể di chuyển sang đặc tả mới trong khi vẫn giữ khả năng tương thích ngược với các đặc tả cũ hơn. Điểm cuối /mcp chấp nhận cả giao thức mới và các yêu cầu không trạng thái từ các client HTTP có thể truyền phát năm 2025, vì vậy hầu hết các client có thể kết nối lại mà không cần thay đổi cấu hình.

Ví dụ, vào tháng 2, chúng tôi đã phát hành Code Mode MCP Server cho toàn bộ API của Cloudflare bằng cách sử dụng chế độ không trạng thái không chính thức này và WebStandardsStreamableHTTPServerTransport (một cái tên khá bắt tai). Kể từ đó, nó đã mở rộng lên hàng nghìn yêu cầu mỗi giây và phục vụ hàng tỷ lệnh gọi công cụ.