Sáu thay đổi của MCP 2.0

1. Vì sao MCP từng được nói tới nhiều như vậy

Aishwarya mở đầu: MCP là một trong những chủ đề lớn của giới AI engineering trong năm 2025, và trong video đăng ngày 27/10/2026 này chị đi qua sáu thay đổi đang giúp MCP tiếp tục phát triển trong năm 2026.

Trước hết, chị hỏi: vì sao MCP từng được "hype" đến vậy? Theo chị (video đăng ngày 27/10/2026), các ứng dụng AI cần truy cập tool và dữ liệu, còn developer thì muốn có một cách chung để nối chúng lại với nhau. Khi số lượng integration tăng lên, câu hỏi bắt đầu mang tính thực tế hơn: làm sao thật sự phục vụ hàng nghìn request như vậy? Chuyện gì xảy ra khi một kết nối bị rớt? Làm sao để một tool hỏi xin phép một con người?

Theo Aishwarya (video đăng ngày 27/10/2026), tất cả những bài toán đó được MCP giải quyết. Về cơ bản, MCP đưa ra một cách chuẩn để AI agent kết nối với tool và database. Gần đây, theo chị, đã có vài cập nhật lớn về cách MCP vận hành, nên trong video này chị tập trung vào việc mỗi thay đổi giải quyết điều gì và các mảnh ghép đó phối hợp với nhau ra sao.

2. Người trình bày

Aishwarya tự giới thiệu: chị đã làm trong mảng machine learning và AI hơn mười năm (tính đến video đăng ngày 27/10/2026), trong đó có thời gian ở những công ty như Google và Microsoft. Trước đây chị phụ trách developer relations ở một công ty AI. Ở thời điểm quay video, chị đang tập trung xây công ty AI của riêng mình, và chị nói việc dạy là đam mê của chị, đó là lý do chị làm những video như thế này.

3. MCP là gì: host, client, server và ba loại capability

MCP là viết tắt của Model Context Protocol. Theo định nghĩa chị đưa ra trong video đăng ngày 27/10/2026, đây là một bộ quy tắc chung, một protocol, giúp AI agent khám phá và sử dụng những năng lực mới, dù đó là tool hay database.

Chị lấy một ví dụ xuyên suốt cả video: giả sử bạn đang xây một agent trả lời câu hỏi về đơn hàng của khách. Trong mô hình mà chị mô tả (video đăng ngày 27/10/2026):

• AI agent là host (theo cách chia của Aishwarya, video đăng ngày 27/10/2026).
• Bên trong host có một MCP client, lo phần giao tiếp ở phía agent (theo video đăng ngày 27/10/2026).
• Một MCP server cung cấp các capability nối với hệ thống đơn hàng của bạn (theo video đăng ngày 27/10/2026).

Server đó có thể đưa ra một tool để tra cứu một đơn hàng, một resource chứa chính sách đổi trả của bạn, và một prompt template để xử lý một yêu cầu hỗ trợ. Theo Aishwarya (video đăng ngày 27/10/2026), một server không nhất thiết phải cung cấp đủ cả ba, nhưng thứ quan trọng nhất hiển nhiên là tool.

4. Một request đi qua hệ thống: hỏi đơn hàng của tôi đâu

Chị mô tả workflow như sau (video đăng ngày 27/10/2026). Khi một người dùng hỏi đơn hàng của họ đang ở đâu, model có thể yêu cầu tra cứu đơn hàng. Ứng dụng của bạn kiểm tra xem hành động đó có được phép không, gửi nó qua MCP client tới MCP server, rồi phản hồi cuối cùng được trả về cho model. Model dùng kết quả đó để trả lời câu hỏi của người dùng.

Điều MCP làm ở đây, theo Aishwarya (video đăng ngày 27/10/2026), là chuẩn hoá cuộc trao đổi đó. Ứng dụng của bạn vẫn quản lý cuộc hội thoại, context của model và các quyền (permission). Hệ thống đơn hàng bên dưới vẫn là nơi lưu đơn hàng.

Hôm nay chị không đi sâu lại những phần nền tảng này. Thứ thay đổi, theo chị (video đăng ngày 27/10/2026), là cách bạn xây phần giao tiếp bao quanh nó, và đó chính là những cập nhật của video này.

5. Thay đổi 1: mỗi request trở nên stateless

Thay đổi đầu tiên chị nêu (video đăng ngày 27/10/2026): bản thân request đã trở thành stateless, trong khi trước đây nó là stateful. Nói theo cách đơn giản nhất, stateless nghĩa là mỗi request tự nó đã hiểu được, không cần nhìn vào cả một session.

Ở phiên bản MCP trước, theo Aishwarya (video đăng ngày 27/10/2026), client bắt đầu bằng một bước bắt tay khởi tạo (initialization handshake): hai bên tự giới thiệu và trao đổi thông tin về phiên bản protocol cùng các tính năng mà mỗi bên hỗ trợ. Ở phiên bản đó, server từ xa còn có thể giữ một protocol session qua nhiều request, nghĩa là các request sau có thể phụ thuộc vào thứ đã được thiết lập từ trước.

Ở phiên bản mới, chị nói (video đăng ngày 27/10/2026), mỗi request mang theo phiên bản protocol và các capability mà client hỗ trợ. Server hiểu được request mà không cần nhớ một lần giới thiệu nào trước đó.

Đối chiếu với trang Key Changes chính thức (đọc ngày 29/10/2026): trang này không dùng tên "MCP 2.0" mà gọi đây là bản đặc tả ngày 28/07/2026 (mã 2026-07-28), và "MCP 2.0" là cách gọi của video. Trang ghi rõ bản này bỏ bước bắt tay initialize/notifications/initialized; mỗi request mang phiên bản protocol và capability của client trong trường _meta, và nếu lệch phiên bản thì trả về UnsupportedProtocolVersionError.

Chị lấy một hình ảnh đời thường (video đăng ngày 27/10/2026): hãy nghĩ tới việc nộp một phiếu công việc (work order). Nếu phiếu nào cũng ghi đủ thông tin cần để xử lý, thì bất kỳ đồng nghiệp nào đang rảnh cũng có thể nhận làm. Bạn không phải đi tìm đúng người đồng nghiệp còn nhớ bạn từ lần nói chuyện đầu tiên. Đó là khác biệt giữa stateful và stateless.

Với một deployment từ xa, chị giải thích (video đăng ngày 27/10/2026), điều này quan trọng khi bạn chạy nhiều bản sao của server để gánh thêm traffic: request đến có thể rơi vào bất kỳ bản sao nào mà không phụ thuộc vào việc bản sao nào đã xử lý lần giới thiệu trước đó.

6. Stateless không có nghĩa là hay quên

Nhưng ứng dụng của bạn hoàn toàn vẫn có thể giữ state, chị nhấn mạnh (video đăng ngày 27/10/2026). Ở phía agent, agent vẫn nhớ được cuộc hội thoại, và database của bạn vẫn nhớ đơn hàng của khách.

Nếu workflow cần tiếp tục một công việc đã bắt đầu, theo Aishwarya (video đăng ngày 27/10/2026), server có thể trả về một tham chiếu (reference) tới đúng công việc đó, và client gửi lại tham chiếu ấy về sau. Trang Key Changes (đọc ngày 29/10/2026) mô tả điều này là các server cần state xuyên nhiều lần gọi thì dùng những handle tường minh do server tạo ra, truyền đi như tham số bình thường của tool.

Client vẫn có thể khám phá xem server cung cấp những gì, chị nói (video đăng ngày 27/10/2026); nó chỉ không cần lần giới thiệu kia để mở một session mới trước khi làm bất cứ việc gì khác. Trang Key Changes (đọc ngày 29/10/2026) ghi thêm một RPC mới là server/discover, mà server bắt buộc phải có để công bố các phiên bản protocol, capability và danh tính của mình.

Vậy, theo chị (video đăng ngày 27/10/2026), stateless không có nghĩa là hay quên. Về cơ bản, nó nghĩa là thông tin cần để hiểu một request đi cùng chính request đó, còn cuộc hội thoại và các công việc đang chạy được quản lý riêng.

7. Thay đổi 2: Multi Round-Trip Request (MRTR)

Thay đổi thứ hai, theo Aishwarya (video đăng ngày 27/10/2026), là cách một server hỏi client thêm thông tin. Giả sử agent của bạn gọi một tool để chuẩn bị hoàn tiền cho một khách hàng, nhưng server cần biết lý do trước khi có thể làm tiếp.

Trước đây, chị kể (video đăng ngày 27/10/2026), server có thể gửi một request riêng ngược về client trong khi vẫn đang xử lý thao tác gốc, tức về cơ bản là giữ thao tác gốc đó lại. Điều này đòi hỏi client phải nhận và trả lời được một request đi theo chiều ngược lại.

Giờ đây, theo video đăng ngày 27/10/2026, server có thể trả lời chính lời gọi ban đầu bằng câu: tôi cần thêm thông tin trước khi hoàn tất. Client đi lấy câu trả lời, rồi gửi lại request ban đầu, lần này kèm câu trả lời đó. Server khi ấy có thể hoàn tất thao tác, hoặc hỏi tiếp một mảnh thông tin còn thiếu khác.

Cách này được gọi là MRTR, tức Multi Round-Trip Request. Ý hữu ích ở đây, theo chị (video đăng ngày 27/10/2026), là một thao tác logic có thể gồm nhiều lượt trao đổi. Trang Key Changes (đọc ngày 29/10/2026) mô tả cùng ý: server trả về một InputRequiredResult (resultType: "input_required"), và client gửi inputResponses khi thử lại request gốc; MRTR thay cho cách cũ là server tự gửi request như elicitation/create hay sampling/createMessage.

8. Human in the loop, và đừng hoàn tiền hai lần

Với ứng dụng, chị nói (video đăng ngày 27/10/2026), một response không phải lúc nào cũng có nghĩa là việc đã xong. Đôi khi nó có nghĩa là bước tiếp theo thuộc về một con người. Đó là chỗ human in the loop bước vào.

Và đừng để model tự bịa ra một sự chấp thuận của con người, Aishwarya dặn (video đăng ngày 27/10/2026). Nếu server cần người dùng xác nhận, ứng dụng của bạn phải luôn đi tới một con người thật và lấy thông tin đó.

Cũng theo chị (video đăng ngày 27/10/2026): chỉ vì bạn đặt một câu hỏi rồi tiếp tục sau đó, hệ thống không được phát hành cùng một khoản hoàn tiền hai lần. "Điều đó hiển nhiên, đúng không?", chị nói.

9. Thay đổi 3: progress update và change notification

Cập nhật thứ ba mà Aishwarya nêu (video đăng ngày 27/10/2026) là notification và streaming: cả hai đều đã thay đổi. Chúng có phần liên quan, nhưng thật ra giải quyết hai bài toán khác nhau.

• Progress update cho bạn biết về một request đang chạy. Ví dụ: "tôi đã xử lý 40 trên 100 bản ghi mà bạn nhờ kiểm tra" (ví dụ của Aishwarya, video đăng ngày 27/10/2026).
• Change notification cho bạn biết điều gì đó về server hoặc các resource của nó. Ví dụ: chính sách đổi trả vừa thay đổi, hoặc có một tool mới (ví dụ trong video đăng ngày 27/10/2026).

Ở phiên bản MCP mới, theo chị (video đăng ngày 27/10/2026), progress update vẫn gắn với đúng request mà nó mô tả. Với những thay đổi rộng hơn, ứng dụng đăng ký nhận đúng loại cập nhật nó muốn, và những cập nhật ấy đến riêng. Nhờ vậy ứng dụng phân biệt được tin tức về server với tiến độ của request hiện tại.

Trang Key Changes (đọc ngày 29/10/2026) ghi cụ thể: subscriptions/listen thay cho endpoint HTTP GET và resources/subscribe, client chọn từng loại thông báo muốn nhận, còn các notification gắn với request như notifications/progress vẫn chạy trên stream phản hồi của chính request đó.

10. Streaming, và chuyện gì xảy ra khi kết nối bị đứt

Streaming, theo Aishwarya (video đăng ngày 27/10/2026), nghĩa là các cập nhật có thể đến trong lúc một kết nối vẫn mở. Điều này vẫn chạy được với request stateless: mỗi request vẫn tự đủ thông tin, kể cả khi phản hồi của nó mất thời gian.

Thay đổi về độ tin cậy nằm ở chuyện xảy ra khi kết nối bị đứt. Theo quy tắc mới mà chị mô tả (video đăng ngày 27/10/2026), ứng dụng không thể nối lại phản hồi bị ngắt từ message cuối cùng nó nhận được; nó cần gửi một request mới. Server nên dừng công việc bị ngắt khi có thể, nhưng một hành động có thể đã hoàn tất rồi. Trang Key Changes (đọc ngày 29/10/2026) ghi đúng ý này: bỏ khả năng nối lại stream SSE (header Last-Event-ID), stream phản hồi bị đứt thì mất request đang chạy, và client phải gửi lại thành một request mới với request ID mới.

Một phản hồi bị mất không chứng minh rằng khoản hoàn tiền đã thất bại, chị nói (video đăng ngày 27/10/2026). Trước khi AI agent quay lại thử lần nữa, ứng dụng cần xác định điều gì đã thực sự xảy ra. Khoản hoàn tiền đã đi qua chưa? Ứng dụng có nhận ra được đó là cùng một thao tác để tránh lặp lại không? Bởi vì, theo chị, gửi thêm một request nữa tự nó không trả lời được những câu hỏi đó.

Theo Aishwarya (video đăng ngày 27/10/2026), sự phân biệt này quan trọng bất cứ khi nào agent thay đổi một thứ nằm ngoài cuộc hội thoại. Việc khôi phục phải tính tới điều đã thực sự xảy ra trong chính hệ thống đơn hàng đó.

11. Thay đổi 4: extension tuỳ chọn, bắt đầu với tasks

Thay đổi thứ tư, theo Aishwarya (video đăng ngày 27/10/2026), là MCP đưa những capability chuyên biệt vào các extension tuỳ chọn. Phần lõi giữ chung cho mọi bên; client và server khai báo rõ ràng mình hỗ trợ những phần bổ sung nào. Trang Key Changes (đọc ngày 29/10/2026) ghi thêm trường extensions vào ClientCapabilities và ServerCapabilities cho việc này.

Long-running task là một ví dụ hữu ích (video đăng ngày 27/10/2026). Giả sử task của bạn tạo một báo cáo hỗ trợ khách hàng dài. Giữ một request mở trong vài phút khiến công việc đó dễ dính timeout của kết nối. Với tasks, theo chị, server có thể trả về một tham chiếu công việc bền vững (durable job reference). Ứng dụng kiểm tra trạng thái công việc sau, và lấy kết quả khi nó sẵn sàng. Nếu client bị ngắt kết nối, nó có thể quay lại đúng công việc đó, miễn là server vẫn còn giữ nó.

Hãy nghĩ tới số biên nhận khi gửi đồ đi sửa, chị ví von (video đăng ngày 27/10/2026). Bạn giữ con số đó và hỏi về món đồ sau. Bạn không mang lại cùng món đồ ra quầy mỗi lần muốn hỏi thăm. Đó là thứ tasks được làm ra để giải quyết.

Theo Aishwarya (video đăng ngày 27/10/2026), tasks đã tồn tại ở dạng experimental từ trước, và thay đổi gần đây là chuyển và thiết kế lại chúng thành một extension. Vì vậy task cũng có thể tạm dừng để chờ thông tin rồi tiếp tục khi câu trả lời tới, mà không phải tạo một job mới. Trang Key Changes (đọc ngày 29/10/2026) xác nhận tasks được đưa khỏi protocol lõi thành extension chính thức io.modelcontextprotocol/tasks, dùng tasks/get để polling và tasks/update để client gửi input; trang Extensions Overview (đọc ngày 29/10/2026) xếp MCP Tasks ở giai đoạn "Beta, to Core".

12. MCP Apps và Skills: hai extension cho hai mục đích khác

Hai extension khác phục vụ những mục đích khác nhau, Aishwarya nói tiếp (video đăng ngày 27/10/2026).

MCP Apps, theo chị được giới thiệu trước đó trong năm 2026 (video đăng ngày 27/10/2026), cho phép những ứng dụng có hỗ trợ hiển thị giao diện tương tác. Báo cáo hỗ trợ khách hàng của bạn có thể hiện ra thành một biểu đồ mà bạn khám phá được ngay bên trong cuộc hội thoại đó.

Skills extension, theo chị đã được chốt vào tháng 9 (video đăng ngày 27/10/2026), cho phép server của bạn cung cấp hướng dẫn workflow cùng các file hỗ trợ đi kèm. Chị phân biệt: tool là thứ tra cứu một đơn hàng, còn skill là thứ giải thích cách điều tra một lô hàng bị trễ bằng nhiều tool cùng lúc.

Những capability này cần được hỗ trợ ở cả ứng dụng phía agent lẫn server, chị lưu ý (video đăng ngày 27/10/2026). Riêng phần hỗ trợ skill thì vẫn đang được triển khai dần. Vì vậy, kết nối một MCP server không tự động đem lại cho bạn tất cả những tính năng này; trải nghiệm có được thực sự phụ thuộc vào những extension mà cả hai phía cùng hỗ trợ.

Đối chiếu với tài liệu chính thức (đọc ngày 29/10/2026): trang Extensions Overview xếp MCP Apps ở giai đoạn Stable và mô tả nó cho phép MCP server hiển thị phần tử UI tương tác (biểu đồ, form, trình phát video) ngay trong cuộc hội thoại. Cũng trang này xếp Skills over MCP ở giai đoạn Beta; còn trang Skills ghi SEP-2640 (Skills Extension) đã ở trạng thái Final và việc hỗ trợ trong SDK và host vẫn đang được triển khai. Trang này không ghi tháng chốt, nên mốc tháng 9 là theo lời Aishwarya.

13. Thay đổi 5: caching có quy tắc

Cập nhật thứ năm, theo Aishwarya (video đăng ngày 27/10/2026), là MCP trở nên thực tế hơn về hiệu quả. Ứng dụng của bạn cần biết server cung cấp những tool nào. Nếu danh sách đó không đổi, việc lấy lại nó cho mỗi lần tương tác chỉ tốn thêm công mà không mang lại thông tin hữu ích nào.

Đặc tả mới, chị nói (video đăng ngày 27/10/2026), đưa ra hướng dẫn rõ ràng về việc tái sử dụng cho một số loại response. Server cho biết thông tin đó có thể được coi là còn mới trong bao lâu, và có được dùng chung cho nhiều bên gọi hay không. Chị giải thích thêm: giữ thông tin đó lại để dùng sau, lưu nó trong bộ nhớ ở một mức nào đó để có thể quay lại lấy cùng thông tin ấy, quá trình đó gọi là caching.

Trang Key Changes (đọc ngày 29/10/2026) ghi cụ thể: kết quả của tools/list, prompts/list, resources/list, resources/read và resources/templates/list bắt buộc có hai trường ttlMs (gợi ý độ mới, tính bằng mili giây) và cacheScope ("public" hoặc "private", quyết định trung gian dùng chung có được cache response hay không).

Một danh sách tool dùng chung có thể tái sử dụng cho nhiều người dùng khác nhau, theo Aishwarya (video đăng ngày 27/10/2026). Nhưng một hồ sơ khách hàng riêng tư thì khác: việc tái sử dụng nó vẫn phải nằm trong đúng ngữ cảnh truy cập đã được cấp quyền. Nếu không, một cải tiến về hiệu quả có thể làm lộ thông tin của một người cho người khác không có quyền xem.

Nếu server thông báo chính sách đổi trả đã được cập nhật, chị nói (video đăng ngày 27/10/2026), ứng dụng nên coi bản cũ của mình là đã lỗi thời và đi dùng bản mới. Trong tình huống đó, nó không nên dùng response đã cache.

Điều này hữu ích, theo Aishwarya (video đăng ngày 27/10/2026), khi một AI agent kết nối với nhiều dịch vụ khác nhau. Với caching, agent tránh được việc lặp đi lặp lại thu thập thông tin không đổi, mà vẫn phản ứng được với thay đổi. Lợi ích thực sự phụ thuộc vào việc biết cái gì dùng lại được, khi nào nó trở nên cũ, và ai được phép xem nó.

14. Thay đổi 6: authorization chính xác hơn về bên cấp quyền

Cập nhật thứ sáu, chị nói (video đăng ngày 27/10/2026), là authorization trở nên chính xác hơn về việc ai đang cấp quyền truy cập. Khi một ứng dụng truy cập một dịch vụ được bảo vệ, một hệ thống khác có thể là bên phát hành credential cho phép nó vào. Theo chị, quy tắc MCP cập nhật siết chặt việc kiểm tra bên phát hành đó, và ngăn ứng dụng coi credential do một hệ thống authorization phát hành là có thể dùng thay cho credential của một hệ thống khác.

Trang Key Changes (đọc ngày 29/10/2026) ghi hai mục tương ứng: client bắt buộc kiểm tra tham số iss (nếu có) khớp với issuer đã ghi nhận trước khi đổi authorization code, và credential của client gắn với authorization server đã phát hành nó, không được dùng lại với một authorization server khác.

Với ví dụ support agent, theo Aishwarya (video đăng ngày 27/10/2026), điều này quan trọng ngay từ trước khi agent đọc đơn hàng của một khách: ứng dụng cần xác lập rằng quyền truy cập của nó đến từ một authority mong đợi.

Với doanh nghiệp, chị nói (video đăng ngày 27/10/2026), một extension riêng là enterprise-managed authorization cho phép hệ thống đăng nhập sẵn có của tổ chức tham gia quản lý quyền truy cập đó. Khi được hỗ trợ, nhân viên có thể dùng quyền do công ty quản lý thay vì phải tự cấp quyền riêng cho từng dịch vụ được kết nối. Trang Extensions Overview (đọc ngày 29/10/2026) xếp Enterprise-Managed Authorization ở giai đoạn Stable.

Nhưng chị nhắc (video đăng ngày 27/10/2026): không điều nào ở trên thay thế được các bước kiểm tra quyền nằm trong tool và trong agent harness của bạn. Được phép kết nối tới một server hỗ trợ khách hàng không tự động có nghĩa là được phép hoàn tiền cho mọi đơn hàng.

15. Đi theo một request: báo cáo đơn hàng bị trễ

Để các khái niệm thấm hơn, Aishwarya đi theo một request qua toàn bộ hệ thống (kịch bản minh hoạ trong video đăng ngày 27/10/2026). Giả sử bạn nhờ support agent chuẩn bị một báo cáo về các đơn hàng bị trễ.

Trong kịch bản đó (video đăng ngày 27/10/2026), ứng dụng agent đã biết MCP server cung cấp những tool nào và có thể dùng lại thông tin ấy khi nó còn mới. Ngay cả khi đó, quyền đọc hồ sơ khách hàng của bạn vẫn được kiểm tra ở mọi lần.

Báo cáo cần một khoảng ngày, nên server hỏi đúng mảnh thông tin còn thiếu đó. Theo kịch bản của Aishwarya (video đăng ngày 27/10/2026), agent mang câu hỏi đó về cho bạn, người dùng, chứ không tự đoán ý bạn. Bạn chọn "tháng trước", và request tiếp tục với câu trả lời của bạn. Request đó mang theo thông tin cần để hiểu nó, nên không phụ thuộc vào việc phải tới lại đúng bản sao server như lần trước.

16. Các thay đổi ghép lại với nhau thế nào

Báo cáo sẽ mất vài phút. Theo kịch bản trong video đăng ngày 27/10/2026, nếu cả hai phía hỗ trợ tasks, server đưa cho ứng dụng một job reference. Ứng dụng kiểm tra được tiến độ job trong lúc công việc vẫn chạy. Rồi bạn đóng ứng dụng.

Khi bạn quay lại, ứng dụng có thể dùng reference đã lưu để kiểm tra đúng báo cáo đó, miễn là server vẫn còn giữ job (kịch bản trong video đăng ngày 27/10/2026). Nó không cần bắt đầu một báo cáo khác chỉ vì kết nối đã kết thúc. Và nếu MCP Apps cũng được hỗ trợ, báo cáo hoàn tất có thể hiện ra thành một biểu đồ tương tác.

Mỗi extension mới, theo Aishwarya (video đăng ngày 27/10/2026), về cơ bản là thêm một capability lên trên phần nền tảng dùng chung có từ trước, và đó chính là cách các thay đổi này ghép lại với nhau. MCP vẫn là một cách dùng chung để các ứng dụng agent chạm tới tool và dữ liệu bên ngoài.

Độ tin cậy, chị kết luận (video đăng ngày 27/10/2026), vẫn phụ thuộc vào cách ứng dụng agent và server xử lý workflow bao quanh tất cả những lượt trao đổi khác nhau này.