Triển Khai MCP Server 2026: 7 Thay Đổi Cách Dùng AI
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
Đang tải…
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
Khác ở chỗ máy chủ MCP không còn phải chạy kèm máy người dùng. Vì spec bỏ hoàn toàn cơ chế phiên, một MCP server giờ triển khai được như một API HTTP thông thường: đặt sau load balancer, chạy nhiều bản, autoscale, và phục vụ cả đội thay vì mỗi người cài một bản riêng.
MCP server phải tích hợp trực tiếp với API của nhà cung cấp mô hình, tức tự có API key và tự trả tiền token. Trước đây Sampling cho phép server mượn mô hình của client, nên người dùng cuối gánh chi phí. Sau khi Sampling bị khai tử, chi phí này dịch về phía nhà cung cấp MCP server.
MCP gateway là lớp trung gian đặt trước các máy chủ MCP để phân quyền, giới hạn tần suất và ghi nhật ký theo từng tool. Nó khả thi từ spec 2026-07-28 vì header Mcp-Method và Mcp-Name giờ bắt buộc, nên gateway đọc được ý định của request mà không cần bóc payload JSON.
Nên nâng cấp nếu bạn phục vụ nhiều người dùng qua mạng, vì lợi ích về mở rộng và cache là rõ rệt. Nếu chỉ chạy MCP server cục bộ cho một người qua stdio, nên chờ client phổ biến hỗ trợ đầy đủ rồi chuyển, vì bạn gần như không được lợi gì mà vẫn mất công viết lại.
Danh sách tool nằm ở đầu prompt gửi cho mô hình. Nếu thứ tự đổi giữa các lần gọi, phần đầu prompt đổ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 đầu vào. Vì vậy spec khuyến nghị server trả tool theo thứ tự tất định.
Tasks được tách thành extension riêng và chuyển sang cơ chế polling qua tasks/get, thay cho lời gọi chặn tasks/result. Agent giao việc xong có thể thoát ra, sau đó quay lại hỏi kết quả, nên hợp với các quy trình chạy hàng giờ như dựng báo cáo hay xử lý dữ liệu lớn.
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 (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
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
Triển khai MCP server sau spec 2026-07-28 đổi theo bốn hướng lớn. Máy chủ MCP chuyển từ cài trên máy cá nhân sang dịch vụ từ xa dùng chung. Chi phí token trở thành biến số thiết kế. Quản trị và bảo mật dồn lên tầng gateway. Tác vụ dài chạy nền thay vì chờ trong một phiên chat.
Vì bản 2026-07-28 xoá toàn bộ khái niệm phiên khỏi giao thức. Một máy chủ MCP không còn được phép nhớ trạng thái giữa các request, nên nó triển khai được như một API HTTP bình thường.
Chi tiết kỹ thuật của thay đổi này nằm ở bài MCP stateless và spec 2026-07-28. Bài này tập trung vào câu hỏi khác: từ đây trở đi, doanh nghiệp triển khai MCP server và dùng MCP với AI theo cách nào.
Cần phân biệt rõ hai loại nhận định bên dưới. Phần nào là quy định của spec thì có dẫn nguồn. Phần nào là hệ quả thực tế suy ra thì được ghi rõ là dự đoán.
| Khía cạnh | Trước spec 2026-07-28 | Từ spec 2026-07-28 |
|---|---|---|
| Nơi chạy | Process cài kèm máy người dùng, giao tiếp qua stdio | Dịch vụ từ xa, đặt sau load balancer |
| Phạm vi phục vụ | Một người một bản cài | Một bản dùng chung cho cả đội |
| Nâng cấp | Từng người tự cập nhật | Deploy một lần, mọi người nhận ngay |
| Danh sách tool | Có thể khác nhau theo phiên | Giống nhau cho mọi client, cache được |
| Quản trị tool | Nằm trong code của từng server | Đặt được ở lớp gateway phía trước |
| Tác vụ dài | Giữ kết nối tới khi xong | Giao việc, thoát ra, quay lại hỏi kết quả |
Không bắt buộc nữa, và đây là thay đổi dễ thấy nhất với người dùng cuối.
Trước đây phần lớn máy chủ MCP chạy cục bộ qua stdio vì giao thức có phiên, mà phiên thì khó duy trì qua mạng khi có nhiều bản chạy song song. Từ khi bỏ phiên, mọi request đều tự đủ thông tin, nên đặt server sau load balancer là chuyện bình thường. Nói cách khác, triển khai MCP server giờ giống việc dựng một dịch vụ web hơn là phát hành một phần mềm cài đặt.
Với doanh nghiệp, hệ quả rất cụ thể:
Đây chính là phần vá cho những vấn đề phân quyền và vận hành từng nêu trong bài hạn chế của MCP Server trong doanh nghiệp.
Chi phí token chuyển từ chuyện may rủi thành biến số thiết kế. Spec mới bắt buộc hai trường ttlMs và cacheScope trên kết quả của tools/list và các endpoint liệt kê khác, đồng thời khuyến nghị server trả danh sách tool theo thứ tự tất định.
Hai điều đó có ý nghĩa tiền bạc rất trực tiếp:
Lỗi thường gặp rất đời thường: server dựng danh sách tool từ một dictionary hoặc một truy vấn cơ sở dữ liệu không có mệnh đề sắp xếp. Thứ tự đổi ngẫu nhiên giữa các lần khởi động, và không ai nhận ra cho tới lúc nhìn hoá đơn. Khi triển khai MCP server bản mới, hãy coi thứ tự tool là một quyết định kiến trúc chứ không phải chi tiết vặt.
Nếu bạn đang cân nhắc nạp bao nhiêu tool vào một agent, đọc thêm phần tối ưu chi phí trong bài MCP là gì và cách dùng MCP cho AI Agent.
Nhà cung cấp MCP server, chứ không còn là người dùng cuối. Đây là thay đổi về mô hình kinh doanh, bắt nguồn từ việc Sampling bị đưa vào diện khai tử.
Sampling là cơ chế cho phép máy chủ MCP mượn mô hình của client để tự sinh nội dung. Khi đó người dùng cuối gánh chi phí token, còn nhà cung cấp server không tốn gì. Spec 2026-07-28 khuyến nghị bỏ Sampling và tích hợp trực tiếp với API của nhà cung cấp mô hình.
Hệ quả suy ra, không phải quy định của spec:
Bằng một lớp gateway đặt trước các máy chủ MCP. Cách làm này chỉ khả thi từ spec 2026-07-28, vì hai header Mcp-Method và Mcp-Name giờ là bắt buộc trên mọi request POST.
Khi ý định của request nằm trên header, hạ tầng đọc được nó mà không cần bóc payload JSON. Từ đó làm được những việc trước đây phải nhét vào code của từng server:
tools/call, tách khỏi các lời gọi chỉ đọc.Với các đội vận hành quảng cáo đa kênh, đây là mảnh ghép còn thiếu so với mô tả trong bài MCP Meta và MCP TikTok cho AI Agent doanh nghiệp.
Theo cơ chế giao việc rồi quay lại lấy kết quả. Tasks được tách khỏi lõi giao thức thành một extension riêng, và chuyển từ lời gọi chặn tasks/result sang polling qua tasks/get.
Trước đây, một tác vụ chạy 40 phút buộc agent phải giữ kết nối suốt 40 phút đó. Giờ agent gửi yêu cầu, nhận về một handle, thoát ra làm việc khác, rồi quay lại hỏi trạng thái.
Kiểu làm việc này hợp với các quy trình vận hành thật:
Một hệ quả suy ra: agent có thể bắt đầu công việc ở một phiên và nhận kết quả ở phiên khác, kể cả trên thiết bị khác, vì không còn phiên nào để mất.
Vẫn có hỏi, nhưng theo hướng ngược lại. Cơ chế mới tên là MRTR, viết tắt của Multi Round-Trip Requests.
Trước đây server chủ động đẩy một yêu cầu về client giữa chừng. Giờ server trả về một kết quả mang dấu input_required, client thu thập thông tin rồi gọi lại chính request đó kèm câu trả lời.
Với người dùng cuối, trải nghiệm gần như không đổi: agent vẫn dừng lại hỏi bạn trước khi làm việc nhạy cảm. Với người xây dựng, khác biệt lớn ở chỗ mỗi vòng là một request độc lập nên retry được, ghi log được, và đưa qua hàng đợi được.
Điểm cần lưu ý khi triển khai: phải đặt giới hạn số vòng lặp. Nếu không, một server lỗi có thể đẩy client vào vòng input_required bất tận.
Làm theo năm bước dưới đây trước khi quyết định nâng cấp:
Ba điểm nên theo dõi thay vì tin chắc ngay:
Khác ở chỗ máy chủ MCP không còn phải chạy kèm máy người dùng. Vì spec bỏ hoàn toàn cơ chế phiên, một MCP server giờ triển khai được như API HTTP thông thường: đặt sau load balancer, chạy nhiều bản, và phục vụ cả đội.
Nên nâng cấp nếu bạn phục vụ nhiều người dùng qua mạng. Nếu chỉ chạy MCP server cục bộ cho một người qua stdio, nên chờ client phổ biến hỗ trợ đầy đủ rồi hãy chuyển.
Server phải tích hợp trực tiếp với API của nhà cung cấp mô hình, tức tự có API key và tự trả tiền token.
Là lớp trung gian đặt trước các máy chủ MCP để phân quyền, giới hạn tần suất và ghi nhật ký theo từng tool. Nó khả thi nhờ header Mcp-Method và Mcp-Name giờ đã bắt buộc.
Theo cơ chế polling qua tasks/get. Agent giao việc xong có thể thoát ra, sau đó quay lại hỏi kết quả, nên hợp với quy trình chạy hàng giờ.
Cập nhật lần cuối: 16/09/2026. Nguồn tham chiếu: MCP Specification 2026-07-28 Key Changes. Các nhận định về xu hướng triển khai là suy luận từ nội dung spec, không phải tuyên bố chính thức của nhóm phát triển Model Context Protocol.