MCP phiên bản 2 sẽ chính thức ra mắt vào ngày 28 tháng 7 năm 2026. Nó loại bỏ mọi quá trình bắt tay (handshake), header Mcp-Session-Id và ba hệ thống con cũ vốn gắn kết Model Context Protocol (MCP) với các máy chủ sticky-session. Giao thức này trở nên hoàn toàn không trạng thái (stateless), vì vậy bất kỳ thực thể (instance) tự động mở rộng (autoscaled) hoặc không máy chủ (serverless) nào cũng có thể xử lý bất kỳ yêu cầu nào mà không cần duy trì trạng thái của máy khách (client state).

Tại sao sự thay đổi này lại quan trọng

MCP v1 buộc máy khách phải bắt đầu một phiên làm việc bằng một bước bắt tay initialize; sau đó máy chủ sẽ gán một Mcp-Session-Id. Mọi lệnh gọi sau đó đều phải mang theo header này, khiến người dùng bị cố định vào một nút (node) backend duy nhất. Các bộ cân bằng tải (load balancers) phải thực thi tính liên kết phiên (session affinity), làm tăng độ trễ và gây khó khăn trong vận hành.

Tính không trạng thái (statelessness) loại bỏ sự khó khăn đó. Toàn bộ ngữ cảnh hiện được lưu trữ trong các trường meta (meta fields) chuyên dụng đi kèm với mỗi lệnh gọi HTTP. Một yêu cầu có thể đến bất kỳ thực thể nào, được xử lý, và thực thể đó có thể bị hủy ngay khi phản hồi được gửi đi. Các đội ngũ sử dụng nền tảng serverless, các cụm điều phối container (container-orchestrated clusters), hoặc bất kỳ môi trường nào khởi tạo và hủy các pod theo nhu cầu hiện có thể điều chỉnh giao thức sao cho phù hợp với hạ tầng của họ.

Những gì sẽ bị loại bỏ

Ba hệ thống con phụ thuộc vào các kết nối liên tục (persistent connections) chính thức bị ngừng hỗ trợ (deprecated):

  • Sampling – Trong v1, máy chủ có thể yêu cầu máy khách tạo văn bản, một mô hình đòi hỏi một phiên làm việc đang mở. v2 yêu cầu máy chủ gọi trực tiếp nhà cung cấp mô hình ngôn ngữ lớn (LLM) hoặc sử dụng mô hình InputRequiredResult, trong đó máy khách cung cấp dữ liệu đầu vào còn thiếu trong một yêu cầu tiếp theo.
  • Roots – Trước đây, máy khách gửi các URI để giới hạn phạm vi truy cập của máy chủ vào các tài nguyên bên ngoài. Cách tiếp cận mới sẽ truyền các URI đó dưới dạng tham số công cụ (tool parameters) hoặc nhúng chúng vào các trường tài nguyên (resource fields) của yêu cầu, loại bỏ bước thương lượng "roots" riêng biệt.
  • Logging – Các header ghi nhật ký (logging) ở cấp độ giao thức sẽ biến mất. Hãy ghi vào stderr để gỡ lỗi cục bộ hoặc áp dụng OpenTelemetry để quan sát hệ thống (observability) trong môi trường production.

Thời gian ngừng hỗ trợ kéo dài một năm. Các tính năng bị ngừng hỗ trợ vẫn sẽ hoạt động trong khoảng thời gian đó, giúp các đội ngũ có thời gian để tái cấu trúc (refactor) trước khi giao thức từ chối chúng.

Những điểm mới ngoài tính không trạng thái

MCP v2 bổ sung hai tiện ích mở rộng chính thức:

  • MCP Apps – Một cách nhẹ nhàng để mô tả các giao diện người dùng được kết xuất từ máy chủ (server-rendered user interfaces) mà giao thức có thể gọi.
  • Tasks – Một mô hình để xử lý các hoạt động chạy lâu (long-running operations) có thể kéo dài qua nhiều chu kỳ yêu cầu-phản hồi.

Cả hai tiện ích mở rộng đều dựa trên mô hình yêu cầu không trạng thái và tránh việc lưu trữ trạng thái phiên ẩn.

Rủi ro và các lưu ý phản biện

Sự thay đổi này không phải là một bản nâng cấp "cắm là chạy" (plug-and-play). Các SDK v2 vẫn đang trong giai đoạn beta và các API công khai của chúng có thể thay đổi trước khi bản phát hành ổn định ra mắt. Đối với các khối lượng công việc production không thể chấp nhận các thay đổi gây lỗi (breaking changes), hãy tiếp tục sử dụng SDK v1 ổn định cho đến khi SDK v2 chính thức hoàn thiện.

Các nhà phát triển cũng cần kiểm tra (audit) mã nguồn hiện có để xem có sử dụng bất kỳ hệ thống con nào trong ba hệ thống bị ngừng hỗ trợ hay không.

Lộ trình di chuyển thực tế

  1. Kiểm tra ngay hôm nay – Quét các dịch vụ của bạn để tìm việc sử dụng handshake, Mcp-Session-Id, các lệnh gọi sampling, roots URIs và logging ở cấp độ giao thức. Xác định các đoạn mã có thể bị lỗi dưới mô hình không trạng thái.
  2. Kiểm thử trên một nút không quan trọng – Khi SDK v2 ổn định được phát hành, hãy khởi tạo một máy chủ sandbox, kết nối nó với một máy khách thử nghiệm và xác minh rằng tất cả các trường meta bắt buộc đều hiện diện và được diễn giải chính xác.
  3. Di chuyển hoàn toàn trước thời hạn – Hoàn tất việc chuyển đổi trên tất cả các nút production trước khi thời gian ân hạn một năm kết thúc để tránh bị từ chối khi đang chạy (runtime rejections).

Những điều cần theo dõi tiếp theo

  • Phát hành SDK ổn định – Các SDK beta sẽ được đóng băng và một gói ổn định có đánh số phiên bản sẽ được xuất bản. Phiên bản đó sẽ là mục tiêu an toàn cho bất kỳ đợt triển khai quan trọng nào.

Quá trình chuyển đổi sẽ yêu cầu thay đổi mã nguồn và một giai đoạn thử nghiệm SDK beta ngắn, nhưng thành quả nhận được là một điểm tích hợp sạch sẽ hơn, có khả năng mở rộng tốt hơn cho bất kỳ ứng dụng nào dựa trên LLM.

Bài học rút ra: Nếu ngăn xếp (stack) của bạn vẫn phụ thuộc vào các bước bắt tay MCP hoặc ba hệ thống con bị ngừng hỗ trợ, hãy bắt đầu kiểm tra ngay bây giờ; thời gian ân hạn một năm là khá dư dả, nhưng chi phí thực sự nằm ở nỗ lực tái cấu trúc, chứ không phải ở thời hạn chót.