MCP Stateless: Spec 2026-07-28 Thay Đổi Những Gì?
Spec MCP 2026-07-28 xoá toàn bộ cơ chế phiên và đưa Model Context Protocol về mô hình stateless. Bảng đối chiếu cũ - mới, lý do đằng sau và checklist migrate 8 bước.
9 phút đọc
Đang tải…
Spec MCP 2026-07-28 xoá toàn bộ cơ chế phiên và đưa Model Context Protocol về mô hình stateless. Bảng đối chiếu cũ - mới, lý do đằng sau và checklist migrate 8 bước.
9 phút đọc
MCP stateless là nguyên tắc thiết kế trong đó máy chủ MCP không lưu bất kỳ trạng thái nào giữa hai lời gọi. Mọi thông tin cần thiết - phiên bản giao thức, năng lực client, danh tính - đều nằm trong chính request đó, ở trường _meta. Nguyên tắc này được áp dụng từ bản spec 2026-07-28.
Có. Bản này phá vỡ gần như mọi implementation hiện có: initialize, Mcp-Session-Id, ping, logging/setLevel, resources/subscribe, Last-Event-ID và toàn bộ luồng server gọi ngược client đều bị xoá hoặc thay thế. Không có đường nâng cấp tự động; server/discover chỉ là phép thăm dò để chạy song song hai phiên bản.
MRTR gồm ba bước. Server trả về kết quả có resultType là input_required kèm trường inputRequests. Client thu thập thông tin được yêu cầu. Client gọi lại chính request gốc kèm trường inputResponses. Nhờ vậy client luôn là bên khởi xướng và mọi vòng đều là một request HTTP độc lập.
Vì session buộc server phải nhớ ngữ cảnh của từng kết nối. Đứng sau load balancer, request thứ hai có thể rơi vào instance khác không biết gì về thoả thuận trước đó, nên phải dùng sticky session hoặc shared store. Bỏ session giúp server MCP deploy được như một API HTTP thông thường.
Còn dùng được nhưng đã bị đánh dấu deprecated và sẽ bị xoá sau cửa sổ tối thiểu 12 tháng. Thay thế được khuyến nghị: truyền thư mục hoặc file qua tham số tool, resource URI hay cấu hình server thay cho Roots; gọi thẳng API của nhà cung cấp mô hình thay cho Sampling.
Vì danh sách tool nằm ở đầu prompt gửi cho mô hình ngôn ngữ. Nếu thứ tự thay đổi giữa các lần gọi, phần đầu prompt cũng đổi theo và prompt cache bị vỡ, khiến mỗi lượt gọi phải trả tiền cho toàn bộ token. Spec 2026-07-28 khuyến nghị server trả tool theo thứ tự tất định.
MCP (Model Context Protocol) là gì? Tìm hiểu cách kết nối MCP với AI Agent hiệu quả, tối ưu chi phí token và hiệu năng hệ thống vận hành.
8 phút đọc
Tìm hiểu các hạn chế của MCP Server trong doanh nghiệp về bảo mật, phân quyền, hiệu năng và giải pháp triển khai an toàn cho hệ thống AI Agent.
9 phút đọc
Khám phá MCP Meta và MCP TikTok giúp AI Agent tự động hóa vận hành quảng cáo, thương mại điện tử và tối ưu chi phí cho doanh nghiệp.
7 phút đọc
Khám phá hạn chế kết nối 1-1 của MCP Meta khi quản lý đa tài khoản Facebook Ads và giải pháp tối ưu AI Automation hiệu quả cho doanh nghiệp. Xem ngay!
8 phút đọc
OpenAI vừa công bố báo cáo về việc một mô hình nội bộ tự chèn mệnh lệnh kiểu jailbreak vào bản tóm tắt nén của chính nó. Chi tiết ba ví dụ, con số điều tra và điều người dùng AI cần rút ra.
10 phút đọc
Spec MCP 2026-07-28 không chỉ đổi kỹ thuật mà đổi cả cách doanh nghiệp triển khai MCP server: hạ tầng, chi phí token, ai trả tiền cho AI, và cách quản trị tool.
10 phút đọc
MCP stateless là mô hình mới của Model Context Protocol, áp dụng từ bản spec 2026-07-28. Máy chủ MCP không còn được phép nhớ trạng thái giữa các request. Toàn bộ lớp phiên gồm initialize, Mcp-Session-Id và ping bị xoá. Mỗi request tự mang phiên bản giao thức cùng năng lực của client trong trường _meta.
MCP stateless là nguyên tắc thiết kế trong đó máy chủ MCP không lưu bất kỳ trạng thái nào giữa hai lời gọi. Mọi thứ server cần để xử lý một request đều nằm trong chính request đó.
Trước đây MCP hoạt động theo mô hình có phiên. Client gọi initialize, hai bên thống nhất phiên bản và năng lực, server cấp một Mcp-Session-Id, rồi mọi lời gọi sau đều dựa vào phiên ấy. Log level, subscription, khả năng nối lại stream, thậm chí danh sách tool cũng có thể khác nhau tuỳ phiên.
Bản 2026-07-28 xoá sạch lớp đó. Nếu bạn chưa quen với giao thức này, nên đọc trước bài MCP là gì và cách dùng MCP cho AI Agent.
Bản spec công bố ngày 28/07/2026, thay thế bản 2025-11-25. Theo changelog chính thức của Model Context Protocol, bản này gồm 9 thay đổi lớn, 12 thay đổi nhỏ và 4 nhóm tính năng bị đưa vào diện khai tử.
Bảng đối chiếu nhanh:
| Cơ chế cũ (2025-11-25) | Thay bằng (2026-07-28) | Mức ảnh hưởng |
|---|---|---|
initialize + notifications/initialized | Metadata trong _meta của từng request | Phá vỡ |
Header Mcp-Session-Id | Handle do server phát hành, truyền qua tham số tool | Phá vỡ |
ping | Xoá, liveness do tầng HTTP lo | Phá vỡ |
logging/setLevel | io.modelcontextprotocol/logLevel theo từng request | Phá vỡ |
HTTP GET + resources/subscribe | subscriptions/listen | Phá vỡ |
Last-Event-ID để nối lại stream | Xoá, client phải gọi lại từ đầu | Phá vỡ |
| Server gọi ngược client | Multi Round-Trip Requests (MRTR) | Phá vỡ |
tasks/result blocking, tasks/list | Extension tasks, polling qua tasks/get |
Ngoài ra còn một RPC mới bắt buộc: server/discover. Server phải công bố các phiên bản giao thức hỗ trợ, năng lực và danh tính của mình. Client có thể gọi nó trước mọi request khác.
Vì phiên chính là thứ khiến máy chủ MCP không mở rộng được. Handshake buộc server nhớ rằng kết nối X đã chốt phiên bản Y. Đặt sau một load balancer, request thứ hai có thể rơi vào instance khác hoàn toàn không biết gì về thoả thuận đó.
Ba lợi ích đổi lại:
tools/list trả cùng kết quả cho mọi client, nó mới có nghĩa để cache, kể cả ở CDN dùng chung.Đây cũng là lời đáp cho nhiều vấn đề vận hành từng được nêu trong bài hạn chế của MCP Server trong doanh nghiệp.
Danh sách biến mất hoàn toàn khỏi bản 2026-07-28:
initialize và notifications/initializedMcp-Session-Idpinglogging/setLevelresources/subscribe và resources/unsubscribeLast-Event-ID cùng SSE event IDtasks/list và tasks/resultnotifications/roots/list_changednotifications/elicitation/completeDanh sách xuất hiện mới:
server/discoversubscriptions/listenresultType, inputRequests, inputResponses, requestStatettlMs và cacheScopeMcp-Method, Mcp-Name và x-mcp-headertasks/updateextensions trong capabilitiesMRTR (Multi Round-Trip Requests) là cách mới để máy chủ MCP xin thêm thông tin từ client mà không cần gọi ngược. Trước đây server chủ động gửi request về client qua roots/list, sampling/createMessage hoặc elicitation/create, đòi hỏi một kênh hai chiều mở sẵn.
Quy trình MRTR gồm ba bước:
resultType: "input_required", kèm trường inputRequests mô tả thứ nó cần.inputResponses.Nhờ vậy client luôn là bên khởi xướng. Mỗi vòng là một request HTTP độc lập nên retry được, ghi log được và đưa qua queue được.
Đi kèm MRTR là trường resultType bắt buộc trên mọi kết quả, nhận giá trị complete hoặc input_required. Kết quả từ server đời cũ không có trường này thì client phải mặc định coi là complete. Đó chính là cầu tương thích ngược.
Vì đây là phần thưởng trực tiếp của việc bỏ phiên. Spec mới bắt buộc hai trường ttlMs và cacheScope trên kết quả của tools/list, prompts/list, resources/list, resources/read và resources/templates/list. Giá trị cacheScope là public hoặc private, quyết định các lớp trung gian dùng chung có được cache hay không.
Một chi tiết nhỏ nhưng ảnh hưởng tới chi phí thật: spec khuyến nghị server trả danh sách tool theo thứ tự tất định. Danh sách tool nằm ở đầu prompt gửi cho mô hình. Đảo thứ tự tool là đổi phần đầu prompt, làm vỡ prompt cache và khiến mỗi lượt gọi phải trả tiền cho toàn bộ token.
Về header, Mcp-Method và Mcp-Name giờ bắt buộc trên mọi POST của Streamable HTTP. Điều này cho phép giới hạn tần suất riêng cho tools/call, định tuyến tools/list về lớp cache, hay chặn một tool nguy hiểm ngay ở tầng WAF.
Bản 2026-07-28 lần đầu đưa ra chính sách vòng đời chính thức với ba trạng thái Active, Deprecated và Removed, cùng cửa sổ tối thiểu 12 tháng trước khi xoá.
| Tính năng bị deprecated | Hướng thay thế được khuyến nghị |
|---|---|
| Roots | Truyền thư mục hoặc file qua tham số tool, resource URI, hoặc cấu hình server |
| Sampling | Gọi thẳng API của nhà cung cấp mô hình |
| Logging | Ghi ra stderr với stdio, hoặc dùng OpenTelemetry |
| Transport HTTP+SSE | Chuyển sang Streamable HTTP |
includeContext giá trị thisServer và allServers | Bỏ trống trường, hoặc dùng none |
| Dynamic Client Registration theo RFC 7591 | Client ID Metadata Documents |
Riêng phần xác thực còn siết thêm. Authorization server nên trả tham số iss theo RFC 9207, và client bắt buộc kiểm tra iss trước khi đổi authorization code. Credential phải được lưu theo issuer, không được dùng lại với authorization server khác. Đây là biện pháp chống tấn công kiểu IdP mixup, vốn rất dễ xảy ra khi một client nói chuyện với nhiều máy chủ MCP cùng lúc.
Làm theo thứ tự dưới đây, vì mỗi bước mở khoá cho bước sau:
initialize và Mcp-Session-Id. Chuyển sang đọc _meta của từng request. Làm trước tiên vì mọi thứ còn lại đều giả định server đã stateless.server/discover. Đây là RPC bắt buộc và là cách duy nhất để client đời mới nhận ra server bạn đã lên phiên bản nào.InputRequiredResult. Sửa client thành vòng lặp retry có giới hạn số vòng.resultType, ttlMs, cacheScope vào kết quả. Đồng thời sắp xếp danh sách tool cho tất định.Mcp-Method và Mcp-Name vào mọi POST. Đánh số lại mã lỗi, đổi lỗi resource not found từ -32002 sang -32602Gần như toàn bộ độ phức tạp bị đẩy từ server sang client. Bốn điểm cần tính trước:
requestState.Kết luận thực tế rất rõ. Nếu bạn chạy máy chủ MCP cho một người dùng trên máy cá nhân, bạn mất nhiều hơn được. Nếu bạn vận hành MCP cho hàng nghìn người dùng sau một load balancer, đây đúng là bản spec bạn đã chờ. Với các đội đang khai thác MCP cho quảng cáo và thương mại điện tử, xem thêm bài MCP Meta và MCP TikTok cho AI Agent doanh nghiệp.
MCP stateless là nguyên tắc thiết kế trong đó máy chủ MCP không lưu bất kỳ trạng thái nào giữa hai lời gọi. Mọi thông tin cần thiết đều nằm trong chính request đó, ở trường _meta. Nguyên tắc này áp dụng từ bản spec 2026-07-28.
Có. Bản này phá vỡ gần như mọi implementation hiện có. Không có đường nâng cấp tự động. server/discover chỉ là phép thăm dò để bạn chạy song song hai phiên bản trong giai đoạn chuyển tiếp.
Còn dùng được nhưng đã bị đánh dấu deprecated và sẽ bị xoá sau cửa sổ tối thiểu 12 tháng. Không nên viết code mới dựa vào chúng.
Vì danh sách tool nằm ở đầu prompt gửi cho mô hình. Thứ tự thay đổi làm vỡ prompt cache, khiến mỗi lượt gọi phải trả tiền cho toàn bộ token.
Rủi ro lớn nhất là tool có tác dụng phụ chạy hai lần. Khi stream đứt, client phải phát lại request mới hoàn toàn, nên mọi tool ghi dữ liệu cần có idempotency key.
Cập nhật lần cuối: 16/09/2026. Nguồn tham chiếu: MCP Specification 2026-07-28 Key Changes và diff đầy đủ trên GitHub.
| Phá vỡ |
| Không có cơ chế cache | ttlMs và cacheScope bắt buộc | Mới |
| Method nằm trong body JSON-RPC | Header Mcp-Method và Mcp-Name | Mới |
elicitationIdiss, lưu credential theo issuer, lên kế hoạch chuyển từ DCR sang Client ID Metadata Documents.Last-Event-ID. Thêm idempotency key cho các tool có tác dụng phụ.