MCP 2026-07-28: Bỏ Session, Nửa Tỷ Lượt Tải Và Cái Giá Của Stateless

Không Còn Session. Không Còn Handshake. Không Còn Kết Nối Dính.

Ngày 28/07/2026, nhóm phát triển MCP phát hành spec 2026-07-28. Tin chính: toàn bộ cơ chế session — initialize/initialized handshake, Mcp-Session-Id header — chính thức bị loại bỏ. MCP giờ là giao thức request/response thuần túy.

Con số đi kèm khiến thay đổi này đáng chú ý: gần 500 triệu lượt tải SDK mỗi tháng, TypeScript và Python SDK đều đã vượt 1 tỷ lượt tải tổng. Claude Code, Cursor, Windsurf và hàng loạt nền tảng agent khác đang dùng MCP làm lớp kết nối công cụ. Mọi thay đổi ở đây ảnh hưởng tới toàn bộ hệ sinh thái.

Tại Sao Lại Là Lúc Này?

MCP ra đời năm 2024 với thiết kế stateful — mỗi client mở một kết nối dài hạn đến server, duy trì session trong suốt phiên làm việc. Thiết kế này đơn giản cho MVP nhưng trở thành rào cản khi hệ sinh thái lớn dần.

Ba yếu tố hội tụ khiến mô hình phi trạng thái (stateless) trở thành yêu cầu cấp thiết:

Mở rộng (Scale): với nửa tỷ request/tháng, phiên làm việc dính (sticky session) không còn khả thi. Mỗi lần deploy, restart, hay tăng giảm quy mô đều làm đứt session, buộc client phải kết nối lại và khởi tạo lại.
Serverless: ngày càng nhiều MCP server chạy trên Lambda, Cloud Run, Cloudflare Workers — nơi các hàm (function) tồn tại theo mili giây, không theo phiên làm việc.
Đa nhà cung cấp (Multi-provider): khi một agent gọi công cụ từ nhiều MCP server khác nhau, việc duy trì session riêng cho từng nhà cung cấp tạo ra ma trận kết nối phức tạp không cần thiết.

Stateless Hoạt Động Như Thế Nào?

Mỗi request giờ là một đơn vị độc lập, tự mô tả đầy đủ:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

Không cần pre-flight. Server đọc _meta từ chính request đầu tiên. Client có thể tùy chọn gọi server/discover để lấy các khả năng (capabilities) trước, nhưng không bắt buộc.

Hệ quả: một MCP server có thể đứng sau bộ cân bằng tải round-robin đơn giản nhất. Không cần phiên làm việc dính. Không cần Redis dùng chung để đồng bộ trạng thái session. Deploy serverless mà không cần nghĩ đến việc rút kết nối (connection draining).

MRTR: Khi Server Cần "Hỏi Lại" Client

Bỏ session đồng nghĩa với bỏ bidirectional stream — kênh duy nhất để server gửi request ngược về client (ví dụ: "bạn có chắc muốn xoá không?"). Đây là bài toán kỹ thuật không tầm thường.

Giải pháp là Multi Round-Trip Requests (MRTR) (SEP-2322):

Server trả resultType: "input_required" kèm danh sách câu hỏi
Client gửi lại request gốc với inputResponses đã điền

Thay vì một kết nối mở hai chiều, MRTR tạo ra chuỗi request/response độc lập. Mô hình tự quản lý luồng xử lý giữa các lượt gọi công cụ. Cách làm này tận dụng chính hành vi tự nhiên của mô hình ngôn ngữ lớn (LLM): gọi công cụ → nhận kết quả → gọi công cụ tiếp theo.

Định Tuyến Qua Header, Không Qua Body

Yêu cầu (request) giờ mang Mcp-Method và Mcp-Name trong HTTP header (SEP-2243). Tuy nhỏ, nhưng thay đổi này thay đổi hoàn toàn cách vận hành:

Trước đây	Spec mới
Gateway phải phân tích cú pháp JSON body để biết phương thức	Đọc header là đủ
Giới hạn tần suất (rate limiting) phải xử lý ở tầng ứng dụng	Giới hạn tần suất ở biên (edge), dựa trên header
Khắc phục sự cố phải kiểm tra body	Log header + trace ID đủ để tìm lỗi

Kết hợp với cache hints (ttlMs, cacheScope) trên các list response (SEP-2549), client có thể lưu tạm (cache) danh mục công cụ và danh sách prompt — giảm đến 30-40% lượt gửi nhận không cần thiết cho những lần gọi lặp lại.

Xác Thực Và Ủy Quyền: Sửa Những Lỗ Hổng Tốn Nhiều Thời Gian Nhất

Xác thực và ủy quyền (Auth) là phần mất nhiều công sức tích hợp nhất với MCP. Ba thay đổi đáng chú ý:

Xác nhận issuer theo RFC 9207 (SEP-2468): máy chủ phải trả iss, client phải xác nhận. Chặn lỗi "nhầm" máy chủ ủy quyền (authorization server) — một lỗ hổng từng khiến URL chuyển hướng bị chuyển nhầm sang kẻ tấn công.
CIMD thay DCR: Đăng ký client động (Dynamic Client Registration) bị loại bỏ dần. Client ID Metadata Documents là hướng đi mới. Lý do: DCR không hoạt động tốt với CLI và ứng dụng desktop do vấn đề redirect_uri trên localhost.
Thông tin xác thực gắn với issuer (SEP-2352): không thể dùng chung thông tin xác thực (credential) giữa các máy chủ ủy quyền.

Cái Cũ Ra Đi, Cái Mới Ở Lại

Tasks chính thức thành phần mở rộng (extension) io.modelcontextprotocol/tasks (SEP-2663), với cơ chế dạng polling tasks/get và tasks/update.
Roots, Sampling, Logging bị loại bỏ dần (SEP-2577).
HTTP+SSE transport (giao thức truyền tải) cũng bị loại bỏ dần.

Tất cả có lộ trình chuyển đổi (offramp) 12 tháng. Đây là chính sách loại bỏ dần chính thức đầu tiên của MCP — một tín hiệu cho thấy giao thức đã trưởng thành và nghiêm túc với khả năng tương thích ngược (backward compatibility).

Lập Trình Viên Cần Làm Gì?

Cả 4 SDK chính (TypeScript, Python, Go, C#) đã có hướng dẫn chuyển đổi (migration guide). Nếu bạn đang chạy MCP server:

Kiểm tra sự phụ thuộc vào session: tìm các từ khóa Mcp-Session-Id, initialize trong mã nguồn (codebase)
Dùng MRTR thay cho elicitation (thu thập thông tin): nếu máy chủ gọi elicitation/create hay sampling/createMessage, cần viết lại
Chuyển đổi Auth: thay đổi DCR → CIMD, thêm xác nhận iss
Bật cache hints: tận dụng ttlMs để giảm lượt gửi nhận
Lộ trình (Timeline): các tính năng cũ còn 12 tháng hỗ trợ — không cần vội nhưng đừng quên

Góc Nhìn

Mô hình phi trạng thái không miễn phí. Máy chủ mất khả năng chủ động gửi thông báo (push notification). Những trường hợp sử dụng (use case) cần thời gian thực (như truyền phát đầu ra công cụ, theo dõi tiến trình tác vụ chạy lâu) sẽ phải dựa vào polling hoặc cơ chế ngoài giao thức MCP.

Nhưng cái giá đó xứng đáng. MCP không còn là giao thức (protocol) cho các bản thử nghiệm — nó đang trở thành hạ tầng vận hành. Khi một giao thức chọn đánh đổi tính năng để lấy khả năng mở rộng (scale), nó đang chuẩn bị cho thứ lớn hơn nhiều.

Bài viết được hỗ trợ bởi AI (Amy 🌸). Nội dung đã được kiểm duyệt bởi tác giả.