MCP hoạt động thế nào năm 2026, giải thích cho người mới

1. MCP lại bùng nổ trong năm 2026

Aishwarya mở đầu bằng một nhận định: MCP lại một lần nữa bùng nổ (blowing up) trong năm 2026. Chị dẫn hai con số (video đăng ngày 15/10/2026): số lượt gọi MCP từ người dùng ChatGPT nghe nói (apparently) đã tăng gấp 98 lần chỉ trong khoảng từ tháng 1 đến tháng 8/2026, và nhiều công ty báo cáo mức tăng hơn 500% lượt sử dụng các MCP server của họ chỉ trong vài tháng trước khi video đăng.

Trong lúc chị nói, màn hình hiện hai bài đăng trên X (theo video đăng ngày 15/10/2026): một bài đăng nói rằng tool call của người dùng ChatGPT đã tăng 98 lần trong năm 2026 và riêng tháng 8 số lượt gọi đã hơn gấp đôi, kèm biểu đồ "MCP tool calls through OpenAI's gateway" đi lên dốc đứng từ tháng 1 tới tháng 8; bài còn lại báo 1 triệu lượt gọi MCP tới một dịch vụ gửi email trong tháng 8/2026 và gọi đó là nhóm sử dụng tăng nhanh nhất của họ.

Aishwarya cho rằng một lý do lớn cho sự quan tâm này là hàng loạt bản cập nhật gần đây (tính đến video đăng ngày 15/10/2026). MCP vào thời điểm đó trông đã rất khác, kể cả khi chỉ so với vài tháng trước. Nếu bạn là người mới, đang rối vì quá nhiều thay đổi dồn dập quanh MCP và không biết nên bắt đầu từ đâu, chị nói đây là video duy nhất bạn cần: video đi từ nền tảng cho tới trạng thái của MCP trong năm 2026.

Trong video đăng ngày 15/10/2026, chị đưa ra một bảng tổng hợp mọi thứ sẽ nói trong video, nói người xem có thể chụp màn hình lại, và bản HD nằm trong GitHub repository của chị. Bảng có năm khối: Why MCP, How MCP works, Local and remote, APIs vs. MCP vs. Skills vs. Plugins, và The four changes in 2026.

Video chia làm bốn phần, hiện trên màn hình như một mục lục: MCP là gì và vì sao nó tồn tại; MCP thực sự chạy thế nào bên dưới; MCP so với API, skill và plugin; và những gì đã thay đổi trong MCP năm 2026.

2. MCP là gì và vì sao nó xuất hiện

Chị bắt đầu bằng định nghĩa, vì nó là nền cho mọi thứ phía sau. MCP, tức Model Context Protocol, về cơ bản là một open standard cho các ứng dụng AI một cách thống nhất để kết nối với tool và dữ liệu bên ngoài. Theo Aishwarya (video đăng ngày 15/10/2026), MCP mang tính open source, nhưng được Anthropic giới thiệu lần đầu vào cuối năm 2024. Trong một khoảng khá dài, vài tháng đầu, nó không thật sự phổ biến.

Thứ tạo đà cho MCP, theo chị (video đăng ngày 15/10/2026), là làn sóng agentic AI vào đầu năm 2025. Chị nhắc lại lời hứa của agent: bạn không còn chỉ chat với một model hay trò chuyện với nó nữa, mà bạn muốn nó thực sự đi làm một phần việc cho mình.

Và phần lớn công việc thật của mọi người lại nằm trong các ứng dụng bên ngoài: email, lịch, CRM, database, GitHub, đủ thứ. Chúng ta dùng rất nhiều tool trong công việc hằng ngày, và agent phải giao tiếp được với các tool hay ứng dụng đó theo một định dạng nào đó. Vì thế, khi agent bắt đầu phổ biến hơn, MCP cũng bắt đầu được chú ý nhiều hơn. Theo Aishwarya (video đăng ngày 15/10/2026), đà đó còn tăng tốc mạnh hơn vào giữa năm 2025, khi những công ty lớn như OpenAI và Google cũng bắt đầu hỗ trợ MCP.

3. Đã có API rồi, sao còn cần thêm MCP?

Nói tới đây, chị nêu một câu hỏi hiển nhiên (video đăng ngày 15/10/2026): tích hợp ứng dụng và API đã có từ nhiều năm. Tại sao lại cần đưa thêm cả một lớp MCP? Mọi tool quen thuộc của bạn, Gmail, Stripe, GitHub hay gì đi nữa, đều đã có API. Vậy chuẩn mới này thêm được gì?

Theo Aishwarya (video đăng ngày 15/10/2026), câu trả lời bắt đầu từ chỗ API ban đầu được thiết kế chủ yếu cho developer viết phần mềm. Chị lấy ví dụ: giả sử chị là một engineer đang build một ứng dụng tự động gửi email cho toàn bộ subscriber mỗi khi chị có sự kiện sắp diễn ra, và dùng Gmail API để gửi những email đó. Chị có thể đọc tài liệu API của Gmail, hiểu các thao tác nó cung cấp, hiểu mỗi request cần những thông tin gì, rồi viết phần mềm deterministic tạo ra đúng request.

Giờ hãy nghĩ tới thế giới sau AI, chị nói tiếp (video đăng ngày 15/10/2026). Giả sử chị muốn agent làm việc đó thay mình: chị nói với nó bằng ngôn ngữ tự nhiên, và nó gửi email tới tất cả những ai sẽ tham dự sự kiện. Lúc này agent phải thay thế một phần công việc mà trước đây chị tự làm. Nó cần có context về việc Gmail API làm được gì, có những thao tác nào, và phải đưa những tham số (argument) nào vào một request để gửi được request tới API đó.

Tóm lại, theo chị (video đăng ngày 15/10/2026), API đã cho chúng ta khả năng kết nối tới Gmail, nhưng model vẫn còn thiếu rất nhiều context trước khi có thể dùng API đó một cách đáng tin cậy.

4. Lớp trung gian ai cũng tự build, và chuyện thiếu một chuẩn chung

Vì vậy, theo Aishwarya (video đăng ngày 15/10/2026), khi developer bắt đầu build agent, họ tự build lớp trung gian (middle layer) đó. Bạn đưa ra cho model một bộ tool và về cơ bản nói với nó: đây chính xác là tất cả những hành động bạn có thể làm với Gmail API. Send email có lẽ là một. Read email có lẽ là một cái khác. Và đây chính xác là những tham số bạn cần để tạo request đó.

Chị lấy ví dụ thao tác send email (video đăng ngày 15/10/2026): có lẽ bạn cần email của người gửi, tên người nhận, email người nhận, và về cơ bản là cho model biết cấu trúc của request. Như vậy agent có được context cần thiết. Nó nhìn yêu cầu của người dùng, xác định đúng tool cho việc đó, rồi dựng một request có cấu trúc với đúng tham số.

Trong cách làm đó (video đăng ngày 15/10/2026), phần code deterministic bên dưới sẽ dịch request đó thành một lần gọi Gmail API thật. Kết quả từ Gmail đi ngược lại qua đúng lớp đó để về tới model.

Theo chị (video đăng ngày 15/10/2026), vấn đề nảy sinh khi developer build theo cách này là không có một cách chuẩn nào để build lớp trung gian. Chị nhắc: các ứng dụng AI và framework khác nhau có thể mô tả tool theo cách khác nhau, khám phá (discover) tool theo cách khác nhau và gọi tool theo cách khác nhau. Kết quả trả về cũng khác nhau. Thế là ai cũng tự build phiên bản riêng của cây cầu nối giữa model và API.

Và đó chính là vấn đề MCP muốn giải. Theo Aishwarya (video đăng ngày 15/10/2026), MCP chuẩn hoá lớp này để các ứng dụng AI có một cách chung để khám phá các năng lực (capability) bên ngoài, hiểu cách dùng chúng, rồi nhận kết quả về.

5. Mặt còn lại: security và authorization

Chị muốn người xem ghi nhớ thêm một mặt khác của vấn đề (video đăng ngày 15/10/2026): gánh nặng về security và authorization. Các API bên dưới có thể đã hỗ trợ sẵn OAuth, API key và những cơ chế xác thực khác. Nhưng phần tích hợp AI vẫn phải nối các credential và quyền đó vào agent thì mới có một trải nghiệm an toàn.

Theo Aishwarya (video đăng ngày 15/10/2026), MCP ngày càng chuẩn hoá cả một phần của việc kết nối đó, nên mỗi bản tích hợp không phải tự phát minh lại toàn bộ luồng authorization một cách độc lập.

6. Ba khái niệm: host, client và server

Biết vì sao cần MCP rồi, trong phần tiếp theo của video đăng ngày 15/10/2026 chị đi sâu hơn vào cách MCP thực sự chạy bên dưới. MCP dùng thứ gọi là kiến trúc client-server, và có ba thuật ngữ bạn cần biết và hiểu.

Thứ nhất là host. Đây là ứng dụng AI lớn hơn mà người dùng thật sự tương tác. Chị kể ví dụ (video đăng ngày 15/10/2026): Claude Code, Codex, Cursor hay những harness kiểu như vậy, hoặc đơn giản là app ChatGPT. Chị lưu ý host là một ứng dụng làm nhiều việc hơn hẳn MCP, chẳng hạn quản lý model, quản lý context, quyền, và mọi thứ như thế. MCP chỉ là một phần nhỏ của trải nghiệm đó.

Thứ hai, bên trong host có một MCP client, về cơ bản là phần của ứng dụng lớn kia chuyên xử lý mọi kết nối MCP. Theo mô tả của Aishwarya (video đăng ngày 15/10/2026), nó biết cách giao tiếp với các ứng dụng bên ngoài như Gmail, Stripe, GitHub, tất cả những thứ đang nói tới. Nó cũng hiểu các ứng dụng đó cung cấp những thao tác nào, gửi request đi và nhận response về. Nó là thực thể nằm trong host và lo toàn bộ phần giao tiếp.

Thứ ba là thứ mà client giao tiếp cùng: MCP server. Theo định nghĩa của chị (video đăng ngày 15/10/2026), MCP server là thứ phơi ra (expose) các năng lực của một ứng dụng bên ngoài theo quy ước và chuẩn của MCP, và cũng lo phần giao tiếp với client.

7. Đi trọn ví dụ: Codex gửi email cho người đăng ký sự kiện

Nếu từng ấy chữ một lúc là quá nhiều, chị đề nghị (video đăng ngày 15/10/2026) đi qua một ví dụ, chính là ví dụ đang dùng: gửi email cho tất cả những người đã đăng ký sự kiện. Bạn mở Codex và nói: gửi email cho tất cả những ai đã đăng ký sự kiện ngày mai.

Trong ví dụ này (video đăng ngày 15/10/2026), Codex là host, và bên trong Codex, MCP client của nó được kết nối tới Gmail MCP server. Gmail MCP server cho biết có những tool nào, mỗi tool làm gì và cần những tham số nào. Codex đưa thông tin đó cho model AI bên trong nó; model nhìn yêu cầu của bạn, xác định cần những tool nào để xử lý, và tạo ra request cần gửi tới Gmail MCP server. Toàn bộ phần giao tiếp này do MCP client đảm nhận.

Tiếp theo, trong ví dụ của chị (video đăng ngày 15/10/2026), Gmail MCP server nhận request MCP đã chuẩn hoá và dịch nó sang đúng thứ mà API thật của Gmail cần. API thực hiện hành động, gửi response về, và kết quả đi ngược lại qua MCP server và client để về tới Codex. Chị gọi đó là hai chặng (two hops): từ server về client, rồi từ client về host, và host hiển thị kết quả cho người dùng.

Điểm mấu chốt, theo chị (video đăng ngày 15/10/2026), là MCP với tư cách một protocol cho chúng ta một cách chuẩn hoá để làm tất cả những việc này mà không phải build các thành phần tuỳ biến.

8. Lifecycle gốc của MCP: bốn ý cần nhớ

Chị muốn người xem nhớ thêm một điều, vì nó sẽ quay lại khi nói về các thay đổi của MCP năm 2026. Lifecycle gốc của MCP có bốn ý: initialization, discovery, request và response, và session. Chị đi qua từng ý.

Initialization. Theo mô tả của chị (video đăng ngày 15/10/2026), MCP client và server về cơ bản tự giới thiệu với nhau, thống nhất đang nói chuyện bằng phiên bản MCP nào, và trao đổi thông tin về những gì mỗi bên hỗ trợ.

Discovery. Sau đó, theo chị (video đăng ngày 15/10/2026), là pha khám phá: client hỏi server xem thực sự nó phơi ra những gì. Trong ví dụ Gmail, server có thể trả về các tool để tìm kiếm, để đọc, v.v., kèm mô tả mỗi tool làm gì và cần tham số nào.

Request và response. Theo chị (video đăng ngày 15/10/2026), chỉ sau màn bắt tay (handshake) này thì request và response thật sự mới bắt đầu. Model AI quyết định cần năng lực nào, client gửi request có cấu trúc đó sang MCP server, và MCP server làm xong việc rồi trả lại dưới dạng một kết quả có cấu trúc.

Session. Cuối cùng, theo chị (video đăng ngày 15/10/2026), MCP server có thể tạo một session trong lúc initialization và đưa cho client một session ID. Chị đề nghị hình dung session ID là cách server biết một request đến từ đâu và thuộc về tương tác đang diễn ra nào. Khi client có các lượt trao đổi tiếp theo, nó kèm session ID đó để server gắn chúng vào cùng một session.

Tóm lại, theo video đăng ngày 15/10/2026, lifecycle MCP gốc gồm initialization, discovery, request và response, và một session ID cho các request tiếp theo.

9. API, MCP và skill là các tầng của cùng một hệ thống

MCP cũng hay bị nhầm với vài thuật ngữ khác trong AI, nên chị làm rõ trước khi đi tiếp: MCP so với API, so với skill, so với plugin. Chị nói (video đăng ngày 15/10/2026) bạn có thể coi tất cả là các tầng (layer) trong cùng một hệ thống: API nằm dưới cùng, MCP nằm trên nó, skill ở trên nữa, còn plugin là một gói có thể chứa nhiều skill và MCP server.

API. Nếu một hệ thống AI cần tương tác với một ứng dụng bên ngoài, tầng dưới cùng vẫn là API. Theo Aishwarya (video đăng ngày 15/10/2026), MCP không thay thế API. MCP nằm trên API và cho hệ thống AI một cách chuẩn hoá để khám phá và dùng các năng lực của ứng dụng đó. MCP server có thể dịch qua lại giữa request MCP chuẩn hoá ở một phía và bất cứ thứ gì API của ứng dụng cần ở phía kia.

Skill. Theo Aishwarya (video đăng ngày 15/10/2026), tầng phía trên là nơi hệ sinh thái skill nằm. Nói thật đơn giản, một skill chứa kiến thức dùng lại được về cách một việc cụ thể nên được làm. Chị kể nó có thể chứa hướng dẫn, quy trình, ví dụ, script hay bất kỳ context nào khác giúp agent làm theo một workflow lặp lại được.

Chị quay lại ví dụ email vì nó tạo một mạch liền (video đăng ngày 15/10/2026): giả sử bạn gửi email nhắc lịch sự kiện. Bạn có thể build một skill "event reminder" dạy agent cách công ty bạn viết email, cụ thể là email nhắc lịch. Có thể mọi email nhắc lịch đều cần link sự kiện, tên, địa điểm, những gì người tham dự nên chuẩn bị, và một giọng thương hiệu (brand voice) nhất định. Skill đó dạy agent việc này nên được làm thế nào.

Khi agent thật sự cần gửi email, theo chị (video đăng ngày 15/10/2026), nó có thể dùng năng lực gửi mail mà Gmail MCP server phơi ra. Và bên dưới MCP server đó là API của Gmail. Vậy nên hoàn toàn có thể skill đang dùng MCP server, còn MCP server thì gọi API.

10. Plugin: một đơn vị đóng gói, không phải chuẩn cạnh tranh

Cuối cùng là plugin. Chị nói đây phần lớn là thứ bạn đã nghe nếu làm việc trong hệ sinh thái OpenAI, vì những tool như Codex và ChatGPT có khái niệm plugin (theo video đăng ngày 15/10/2026). Plugin không thật sự là một chuẩn cạnh tranh, nó chỉ là một đơn vị đóng gói (packaging unit).

Theo Aishwarya (video đăng ngày 15/10/2026), khi OpenAI ra mắt plugin marketplace vào tháng 4/2026, họ có khoảng hơn 90 plugin. Tất cả về cơ bản là các gói skill có thể dùng thêm MCP server, và được cung cấp dưới dạng một gói cài một lần. Chị lấy ví dụ: nếu bạn cài plugin Gmail trong Codex, về cơ bản đó là Gmail MCP server cộng với kiến thức workflow xung quanh nó, gói lại để bạn cài một thứ thay vì tự nối một loạt thứ khác nhau.

Trên màn hình lúc đó là trang Plugins của ChatGPT, với dòng "Connect plugins to let ChatGPT work across your tools", danh sách plugin phổ biến (Gmail, Google Drive, Supabase, Health, GitHub, Outlook Email) và kết quả tìm kiếm khi gõ "product" (theo video đăng ngày 15/10/2026). Chị nói OpenAI cũng có plugin cho các use case data science, product management, product design, và nhiều thứ khác; tất cả đều là những gói chứa cả skill lẫn MCP server.

Mô hình tư duy đơn giản chị muốn người xem giữ lại (video đăng ngày 15/10/2026): API là cách phần mềm tương tác với ứng dụng bên ngoài. MCP là tầng kết nối được chuẩn hoá, cho hệ thống AI khám phá và dùng các năng lực đó. Skill là tầng workflow, dạy agent một việc cụ thể nên được làm thế nào. Và plugin, nếu bạn từng nghe từ này và thấy rối: trong bối cảnh AI, plugin là một gói giao cho bạn nhiều skill và workflow, có thể dùng hoặc không dùng MCP server.

11. Thay đổi thứ nhất của 2026: MCP trở thành stateless

Rồi chị chuyển sang phần chị gọi là thú vị nhất của video: những gì đã thay đổi trong năm 2026 ở toàn bộ mảng MCP. Theo Aishwarya (video đăng ngày 15/10/2026), thay đổi lớn đầu tiên là MCP trở thành stateless.

Nghĩa thực sự của nó là gì? Trong video đăng ngày 15/10/2026, chị nhắc lại bốn mảnh của lifecycle vừa học: initialization, discovery, request và response, và chuyện session ID. Client và server khởi tạo kết nối, server có thể tạo một session, và các request sau mang theo session ID để server biết chúng thuộc cùng một tương tác đang diễn ra. Đó là bản tóm tắt ngắn (TL;DR).

Nhưng theo Aishwarya (video đăng ngày 15/10/2026), chuyện bắt đầu xảy ra khi có những MCP server phổ biến. Chị lấy ví dụ Gmail MCP server, có lẽ đang nhận hàng trăm nghìn request. Sẽ không có chuyện một server xử lý mọi request. Các công ty về cơ bản sẽ có nhiều bản sao, nhiều instance server cùng gánh tải. Giả sử request đầu tiên của người dùng tới server 1. Server đó biết state gắn với session ấy; state ở đây là những gì đã xảy ra và đã làm tới đâu. Rồi request tiếp theo của cùng người dùng lại rơi vào server 7, và server 7 không có state mà server cũ đang giữ.

Có hai cách lách cơ bản. Một là luôn route client đó quay về đúng server cũ. Hai là bảo đảm mọi instance server có cùng một session state dùng chung. Theo chị (video đăng ngày 15/10/2026), cả hai đều thêm độ phức tạp cho hạ tầng, vì chính protocol kỳ vọng server phải nhớ tương tác đang diễn ra.

Vì thế, theo Aishwarya (video đăng ngày 15/10/2026), một trong những thay đổi lớn nhất diễn ra vào tháng 7/2026 là bỏ hẳn yêu cầu đó. Cả bước initialization về cơ bản đã biến mất, khái niệm session ID cũng biến mất. Mỗi request MCP giờ tự chứa đủ thông tin, và điều đó nằm ở cấp protocol. Thay vì tự giới thiệu một lần rồi trông chờ server nhớ thông tin ấy về sau, client đưa thông tin đó vào mọi request. Chị nói thay đổi nhỏ này làm MCP dễ scale hơn rất nhiều.

Bài blog chính thức của MCP về bản đặc tả 2026-07-28 (đăng 28/07/2026, đọc ngày 24/10/2026) ghi đúng điều này: bước trao đổi initialize / initialized và header Mcp-Session-Id đã bị bỏ; mỗi request mang theo phiên bản protocol, thông tin client và capability của client; và có thêm một lời gọi server/discover không bắt buộc cho client nào muốn biết capability của server trước.

12. Multi round-trip requests: khi server cần hỏi lại giữa chừng

Nhưng thay đổi đó cũng tạo ra một vấn đề mà chị thấy khá thú vị, và theo chị (video đăng ngày 15/10/2026) bản đặc tả lúc đó cũng đã giải luôn: nếu server bắt đầu xử lý request rồi nhận ra nó cần thêm gì đó từ client mới làm xong được thì sao?

Trong ví dụ email: bạn yêu cầu gửi email cho mọi người đã đăng ký một sự kiện, nhưng trước khi gửi đi hàng trăm email, server muốn bạn xác nhận hành động đó. Nếu không còn session ID liên tục nữa, làm sao nó dừng lại để hỏi thêm input?

Theo Aishwarya (video đăng ngày 15/10/2026), đó là chỗ multi round-trip requests (MRTR) được đưa vào để giải. Chị nhấn mạnh đây không phải một callback kiểu server tự liên lạc lại về sau. Request đầu tiên thực ra đã xong và đóng lại. Thứ server gửi về là một loại response đặc biệt: thay vì kết quả bình thường, nó được gắn cờ "input required". Cờ đó báo cho client biết việc chưa xong và cần thêm input từ người dùng.

Cùng với cờ đó, theo chị (video đăng ngày 15/10/2026), server gửi về một mẩu request state nhỏ, về cơ bản là ghi chú của chính server cho mình: chuyện gì đã xảy ra và nó đang cần gì. Nhờ vậy, kể cả khi request kế tiếp đổi server, từ server 1 sang server 10 hay 15 hay bất kỳ cái nào, server mới vẫn có đủ context.

Như vậy, theo Aishwarya (video đăng ngày 15/10/2026), MCP đã rời bỏ cách giữ một session protocol liên tục để chuyển sang các request độc lập, mà vẫn có cách xử lý những tương tác cần nhiều hơn một lượt. Bảng tổng hợp của chị ghi gọn: "MRTR: request missing input, then retry with inputResponses + requestState". Bài blog của MCP về bản 2026-07-28 (đọc ngày 24/10/2026) mô tả tương tự: server trả về resultType: "input_required" cùng các yêu cầu cần trả lời, và client gọi lại lời gọi gốc với câu trả lời đính kèm trong inputResponses.

13. Thay đổi thứ hai: MCP tasks cho việc chạy dài

Thay đổi lớn thứ hai là ý tưởng MCP tasks, và theo chị (video đăng ngày 15/10/2026), nó đến từ việc chính agent đã thay đổi trong năm qua. Khi MCP mới được thiết kế, nhiều tương tác của agent trông gần với tool call bình thường: rất ngắn, ví dụ tìm một thứ, đọc một thứ hay chỉ gửi một thứ, và câu trả lời về khá nhanh.

Nhưng trong năm 2026, theo Aishwarya (video đăng ngày 15/10/2026), phạm vi của agent đã lớn hơn nhiều. Chúng nhận những phần việc dài hơn: phân tích các codebase lớn, xử lý hàng nghìn cuộc hội thoại với khách hàng, chạy một workflow deep research, hoặc về cơ bản bất cứ việc gì có thể mất vài phút, thậm chí vài giờ. Và bạn thật sự không muốn các request MCP này mở suốt thời gian đó để chờ việc xong.

Đó là lý do có MCP task: server có thể quyết định một request gửi tới có nên được xử lý như một task hay không. Thay vì trả kết quả cuối ngay, nó trao lại một task handle, và client dùng handle đó để kiểm tra lại theo những khoảng thời gian đều đặn. Bảng tổng hợp của chị (video đăng ngày 15/10/2026) ghi thêm: "Return a durable task handle. Poll tasks/get for progress and results. Provide missing input via tasks/update", và "Minutes or hours of work can continue without keeping one request open".

14. Thay đổi thứ ba: security và authorization chặt hơn

Thay đổi lớn thứ ba, theo Aishwarya (video đăng ngày 15/10/2026), là security và authorization trong protocol gần đây đã mạnh hơn nhiều. Khi MCP được dùng rộng hơn, người ta bắt đầu nối agent vào email, code, CRM, database và rất nhiều hệ thống khác chứa thông tin nhạy cảm hay riêng tư. Vì thế danh tính (identity), credential và quyền bắt đầu quan trọng hơn trước rất nhiều.

Chị nói bản đặc tả tháng 7/2026 đã siết chặt mô hình authorization (theo video đăng ngày 15/10/2026). Ví dụ, client giờ có cách mạnh hơn nhiều để kiểm tra authorization server nào thực sự đã cấp một credential, và credential cũng bị gắn với chính bên đã cấp ra nó. MCP cũng rời bỏ cách để client tự đăng ký động (dynamically register) với từng authorization server, chuyển sang client metadata document, cho các hệ thống authorization một cách dễ đoán hơn nhiều để nhận diện client. Bài blog bản 2026-07-28 (đọc ngày 24/10/2026) gọi tên các thay đổi này là kiểm tra issuer theo RFC 9207, credential gắn với issuer, và chính thức deprecate Dynamic Client Registration (DCR) để chuyển sang Client ID Metadata Documents (CIMD).

MCP vốn đã có khái niệm enterprise managed authorization, nhưng theo chị (video đăng ngày 15/10/2026) nó đã ổn định hơn nhiều trong năm 2026. Ý tưởng là nếu một công ty có, chẳng hạn, hàng nghìn nhân viên, công ty có thể định ra một bộ MCP server được duyệt và giám sát tập trung, thay vì để từng người dùng tự duyệt một loạt server. Toàn bộ việc thẩm định (vetting) làm ở cấp công ty.

Chị nói thêm (video đăng ngày 15/10/2026) rằng các cơ chế authorization này khá hay, tốt hơn nhiều so với các phiên bản cũ, nhưng chúng không giải quyết như phép màu mọi vấn đề security của bạn; chúng làm protocol vững hơn nhiều và khiến kẻ xấu khó lọt vào hơn.

15. Thay đổi thứ tư: MCP sẵn sàng cho production hơn

Thay đổi thứ tư và cuối cùng, theo Aishwarya (video đăng ngày 15/10/2026), là MCP đã sẵn sàng cho production hơn nhiều trong vài tháng qua. Đây không phải một bản cập nhật lớn duy nhất mà là một loạt cập nhật khác nhau; chị chọn nói về ba cái phổ biến.

Extension. Theo chị, tính đến video đăng ngày 15/10/2026, MCP có một hệ thống extension chính thức. Thay vì nhét mọi năng lực mới thẳng vào protocol lõi, developer có thể đặt các năng lực tuỳ chọn ra riêng và build theo cách module. Mọi thứ đã nói tới giờ, MCP tasks, MCP apps và enterprise managed authorization, đều nằm dưới dạng extension. Và không phải server hay client nào cũng phải hỗ trợ mọi tính năng có thể có. Bảng tổng hợp của chị cũng ghi "Extensions need support from both client and server".

MCP apps. Theo Aishwarya (video đăng ngày 15/10/2026), MCP giờ hỗ trợ được những giao diện phong phú hơn thay vì lúc nào cũng chỉ trả về text hay dữ liệu. Ví dụ, một server có thể trả về một giao diện tương tác mà host có hỗ trợ sẽ hiển thị được. Một MCP server analytics có thể trả về một dashboard, một workflow có thể trả về một form, hay một tool CRM có thể trả về một màn hình khách hàng tương tác. Nó không còn chỉ là text hay dữ liệu. Bài blog MCP Apps của MCP (đăng 26/01/2026, đọc ngày 24/10/2026) gọi đây là extension MCP chính thức đầu tiên.

Caching. Cập nhật thứ ba mang tính vận hành hơn: caching và xử lý request dễ hơn. Theo chị (video đăng ngày 15/10/2026), danh sách tool và các response dạng danh sách khác giờ có thể kèm thông tin caching, để client không phải tải lại cùng một catalog hết lần này tới lần khác. Bảng tổng hợp của chị còn ghi thêm một mục ở khối này: "Minimum 12-month deprecation window".

16. Nhìn từ trên cao: 2025 so với 2026

Đó là toàn bộ các cập nhật. Giờ chị đề nghị lùi lại và nhìn từ độ cao 10.000 feet. Theo Aishwarya (video đăng ngày 15/10/2026), điểm chung xuyên suốt bốn thay đổi là tư duy đằng sau các bản cập nhật MCP trong năm 2026 hoàn toàn khác.

Theo chị (video đăng ngày 15/10/2026), năm 2025 MCP chỉ là một cách chuẩn để kết nối với tool và ứng dụng bên ngoài. Nó còn rất sớm, và ý tưởng chỉ là cung cấp chức năng cho mọi người.

Còn trong năm 2026, theo chị (video đăng ngày 15/10/2026), trọng tâm đã chuyển sang câu hỏi chuyện gì xảy ra khi tất cả những kết nối đó bắt đầu diễn ra, diễn ra ở quy mô lớn và trong những ứng dụng kiểu production, nơi agent làm những phần việc dài hơn, làm việc với dữ liệu nhạy cảm hơn nhiều, và các công ty thật sự phụ thuộc vào việc nó chạy ổn định để vận hành công việc của họ.

Chị hy vọng video đã trả lời hết các câu hỏi về MCP và người xem giờ hiểu rõ hơn cách nó hoạt động. Chị hẹn gặp lại ở video sau với những phần đào sâu tương tự, và chúc mọi người mọi điều tốt đẹp.