Máy chủ MCP là gì? MCP và MCP UI hoạt động thế nào năm 2026

Ngày 1 tháng 4 năm 2025, Invariant Labs công bố một công cụ tên là add. Nó nhận hai con số và trả về tổng. Nhưng phần mô tả của nó còn chứa một khối được đánh dấu IMPORTANT, vô hình trên giao diện của ứng dụng khách, yêu cầu mô hình đọc ~/.cursor/mcp.json và ~/.ssh/id_rsa rồi chuyển cả hai tệp ra ngoài qua một tham số thừa. Mô hình làm theo. Người dùng chỉ thấy một phép cộng.

Theo tôi biết, màn trình diễn đó là phần nhập môn hữu ích nhất về máy chủ MCP, vì nó cho thấy cả hai mặt cùng lúc. Giao thức hoạt động đúng như thiết kế: một ứng dụng khách AI khám phá một công cụ, đọc mô tả của nó và gọi nó. Thứ chưa ai xây dựng là mô hình niềm tin.

Máy chủ MCP là gì

Máy chủ MCP là một chương trình cung cấp công cụ, dữ liệu và prompt cho các ứng dụng AI thông qua Model Context Protocol (MCP). Tài liệu chính thức định nghĩa MCP là “một tiêu chuẩn mã nguồn mở để kết nối ứng dụng AI với các hệ thống bên ngoài.” Một ứng dụng khách AI như Claude, ChatGPT, Visual Studio Code hay Cursor kết nối với máy chủ, hỏi xem nó cung cấp gì, rồi thay mặt người dùng gọi các khả năng đó.

Anthropic công bố MCP ngày 25 tháng 11 năm 2024 cùng sáu máy chủ dựng sẵn: Google Drive, Slack, GitHub, Git, Postgres và Puppeteer. OpenAI áp dụng nó vào tháng 3 năm 2025. Google DeepMind theo sau vào tháng 4. Tháng 12 năm 2025, Anthropic trao giao thức này cho Agentic AI Foundation, một quỹ chuyên biệt trực thuộc Linux Foundation do Anthropic, Block và OpenAI đồng sáng lập.

Vấn đề là số kết nối tăng theo cấp số nhân. Trước MCP, mỗi ứng dụng AI muốn dùng GitHub phải tự viết trình kết nối, còn mỗi nhà cung cấp phải tạo kết nối cho từng ứng dụng AI. Mười mô hình và mười công cụ có thể cần tới một trăm tích hợp. MCP giảm con số đó xuống hai mươi: mỗi ứng dụng khách triển khai giao thức một lần, mỗi hệ thống cung cấp một máy chủ.

Hãy hình dung nó như container vận tải của thế giới tích hợp AI. Trước khi có container, mọi cảng đều bốc dỡ mọi kiện hàng bằng tay, với cần cẩu riêng và đội bốc xếp riêng. Container chuẩn hóa chiếc thùng, nhờ đó bất kỳ con tàu, cần cẩu hay xe tải nào cũng chở được bất kỳ hàng hóa nào. Nó không chuẩn hóa thứ nằm trong thùng, và nó chưa bao giờ kiểm tra hàng bên trong. MCP là cùng một thỏa thuận như vậy. Hãy nhớ nửa sau này; nó sẽ quay lại ở phần bảo mật.

Máy chủ MCP hoạt động thế nào

Đặc tả hiện hành, phiên bản 2026-07-28, dùng các thông điệp JSON-RPC 2.0 giữa ba vai trò. Phần mô tả của chính đặc tả chỉ dài ba dòng: host là “các ứng dụng LLM khởi tạo kết nối”, client là “các bộ kết nối bên trong ứng dụng host”, và server là “các dịch vụ cung cấp ngữ cảnh và khả năng.”

Host, client, server

Host là ứng dụng bạn gõ vào: Claude Desktop, một IDE, hoặc tác nhân AI của riêng bạn. Bên trong host, mỗi kết nối tới một máy chủ có một client riêng. Máy chủ nằm ở phía bên kia và làm việc với hệ thống thật, dù đó là cơ sở dữ liệu Postgres, GitHub API hay một thư mục trên ổ đĩa của bạn. Host quyết định mô hình được thấy gì và người dùng phải phê duyệt gì. Máy chủ quyết định hệ thống bên dưới sẽ làm gì.

1. Host Claude Desktop · một IDE · tác nhân AI của bạn

   cho mô hình thấy công cụ, xin người dùng đồng ý

2. Client một client cho mỗi kết nối máy chủ

   giao tiếp JSON-RPC qua stdio hoặc Streamable HTTP

3. Máy chủ MCP công cụ · tài nguyên · prompt

   mô tả những gì nó cung cấp và thực thi các lệnh gọi

4. Hệ thống bên dưới cơ sở dữ liệu · SaaS API · tệp cục bộ

   làm phần việc thật

Công cụ, tài nguyên và prompt

Một máy chủ có thể cung cấp ba loại thứ:

• Công cụ là các hàm mà mô hình có thể thực thi: create_issue, query_orders, send_email. Mỗi công cụ có tên, mô tả và một JSON Schema cho đầu vào.
• Tài nguyên là ngữ cảnh và dữ liệu để người dùng hoặc mô hình đọc: một tệp, một lược đồ cơ sở dữ liệu, một bản ghi.
• Prompt là các thông điệp và quy trình dạng mẫu mà người dùng có thể chọn, chẳng hạn “tóm tắt pull request này”.

Công cụ nhận được nhiều chú ý nhất vì chúng hành động. Đó cũng là lý do chúng gánh phần lớn rủi ro.

Từng bước một lệnh gọi công cụ

Bản sửa đổi 2026-07-28 khiến MCP trở thành không trạng thái (stateless). Không còn bước bắt tay initialize; mọi yêu cầu đều mang phiên bản giao thức và khả năng của client trong trường _meta, và máy chủ phải triển khai phương thức server/discover để client có thể hỏi ngay từ đầu chúng hỗ trợ những gì. Giờ đây một lệnh gọi công cụ diễn ra như sau:

1. Người dùng yêu cầu: tạo ticket cho lỗi này

2. Bước 1

   Khám phá

   • Client có thể gọi server/discover để lấy phiên bản và khả năng
3. Bước 2

   Liệt kê công cụ

   • tools/list trả về tên, mô tả và lược đồ đầu vào
4. Bước 3

   Mô hình chọn công cụ

   • Host chuyển định nghĩa công cụ cho mô hình
5. Bước 4

   Người dùng đồng ý

   • Đặc tả nói host phải có sự đồng ý rõ ràng trước khi gọi bất kỳ công cụ nào
6. Bước 5

   Gọi

   • tools/call kèm đối số, phiên bản giao thức nằm trong _meta

7. Thiếu đầu vào? Máy chủ trả về input_required; client thử lại kèm câu trả lời

   Bước 6

   Kết quả

8. Kết quả quay về mô hình dưới dạng ngữ cảnh

Bước 6 là điểm mới trong bản sửa đổi này. Máy chủ cần thêm thông tin không còn gửi ngược yêu cầu của riêng nó về client nữa. Nó trả về một kết quả được đánh dấu input_required, client thu thập câu trả lời rồi thử lại lệnh gọi ban đầu. Đặc tả gọi đây là mẫu Multi Round-Trip Request.

Phương thức truyền tải: stdio và Streamable HTTP

Đặc tả định nghĩa hai phương thức truyền tải tiêu chuẩn:

• stdio: client khởi chạy máy chủ như một tiến trình con và trao đổi JSON-RPC phân tách bằng dòng mới qua đầu vào và đầu ra chuẩn. Phần lớn máy chủ cục bộ chạy theo cách này, nghĩa là máy chủ chạy trên máy của bạn với quyền của bạn.
• Streamable HTTP: mỗi thông điệp là một HTTP POST tới một endpoint duy nhất, và phản hồi quay về dưới dạng một đối tượng JSON hoặc một luồng sự kiện gắn với yêu cầu đó. Các máy chủ từ xa, được lưu trữ sẵn, chạy theo cách này.

Phương thức HTTP+SSE cũ đã chính thức bị ngừng khuyến nghị. Bản sửa đổi 2026-07-28 cũng bỏ phiên làm việc ở cấp giao thức và header Mcp-Session-Id; máy chủ cần giữ trạng thái qua nhiều lệnh gọi giờ phải tự tạo một handle và nhận lại nó như một đối số công cụ bình thường.

Ủy quyền

Ủy quyền trong MCP là tùy chọn, và chỉ áp dụng cho HTTP. Với stdio, đặc tả nói máy chủ nên lấy thông tin xác thực từ môi trường. Với HTTP, một máy chủ MCP được bảo vệ đóng vai trò máy chủ tài nguyên OAuth 2.1. Nó phải công bố OAuth Protected Resource Metadata (RFC 9728) để client tìm được máy chủ ủy quyền của nó. Client phải nêu chính xác token dành cho máy chủ nào (chỉ báo tài nguyên theo RFC 8707). Máy chủ phải từ chối mọi token không được cấp cho chính nó, và hướng dẫn bảo mật gọi tên “token passthrough”, tức chuyển nguyên token của client tới một API phía sau, là điều bị cấm rõ ràng.

Quy tắc cuối cùng đó quan trọng hơn vẻ ngoài của nó. Một máy chủ chuyển tiếp bất cứ token nào nó nhận được sẽ biến thành proxy cho bất kỳ ai đang cầm token.

MCP UI bổ sung điều gì: máy chủ trả về giao diện

Câu trả lời dạng văn bản hết tác dụng ngay khi người dùng cần so sánh bốn mươi dòng, chỉnh một biểu mẫu mười hai trường hoặc phê duyệt từng thay đổi trong một lô. “MCP UI” là cái tên người ta tìm kiếm cho lời giải: máy chủ trả về một giao diện tương tác, hiển thị ngay trong ứng dụng khách AI, cạnh cuộc trò chuyện.

Cần mô tả tình trạng thật chính xác. Ý tưởng bắt đầu từ MCP-UI, một dự án cộng đồng. OpenAI xây dựng cơ chế tương tự trong Apps SDK. Dự án MCP đề xuất tiêu chuẩn chung cùng hai bên vào ngày 21 tháng 11 năm 2025, rồi công bố MCP Apps ngày 26 tháng 1 năm 2026 như phần mở rộng MCP chính thức đầu tiên. Các gói MCP-UI hiện triển khai đặc tả này và tiếp tục là nơi cộng đồng thử nghiệm cải tiến.

Vậy MCP UI ngày nay có nghĩa là MCP Apps. Nó chính thức, và nó là phần mở rộng, không phải giao thức lõi. Phần mở rộng là tùy chọn bật: cả client lẫn máy chủ đều phải hỗ trợ, và tài liệu nói thẳng rằng “mức hỗ trợ của host khác nhau tùy client.” Tài liệu MCP Apps liệt kê các host hỗ trợ gồm Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam và Archestra.AI. Một máy chủ có công cụ trả về UI vẫn phải hoạt động được với client chỉ hiển thị văn bản.

Về cơ chế, nó tái sử dụng chính các thành phần của MCP:

1. Mô tả của một công cụ chứa _meta.ui.resourceUri trỏ tới một tài nguyên ui://.
2. Host tải tài nguyên đó, một trang HTML kèm script, và có thể tải trước trước khi công cụ được gọi.
3. Host hiển thị nó trong một iframe sandbox không thể đọc trang cha, cookie hay bộ nhớ lưu trữ của trang cha.
4. Ứng dụng và host trao đổi qua postMessage bằng một phương ngữ JSON-RPC của MCP. Ứng dụng có thể yêu cầu gọi công cụ, và host quyết định cho phép những lệnh gọi nào.

Cái giá là có thật. Giờ bạn đang đưa một giao diện web vào bên trong ứng dụng của người khác, với chính sách bảo mật nội dung bạn phải tự khai báo, quy tắc hiển thị bạn không kiểm soát, và một phương án văn bản dự phòng cho mọi host bỏ qua nó. Cái được là việc phê duyệt không còn là một bản ghi trò chuyện. Danh sách các trường hợp phù hợp mà chính tài liệu đưa ra kết thúc bằng “phê duyệt báo cáo chi phí, xem xét thay đổi mã nguồn hoặc phân loại sự cố”, và đó là trọng tâm thật sự: MCP UI mạnh nhất ở việc ra quyết định, không phải trang trí.

Ví dụ Tajo chỉ đọc

Bề mặt Alto MCP của Tajo có query_contacts để tìm liên hệ đã lưu trong không gian làm việc được kết nối. Hãy tìm một liên hệ hiện có theo email rồi kiểm tra ID, trạng thái đồng ý nhận email và thời điểm ghi nhận gần nhất. Công cụ riêng get_contact_topic_status đọc các chủ đề mà liên hệ đó đã đăng ký.

Đây là thao tác đọc trong không gian làm việc. Chúng không lấy ảnh chụp dữ liệu mới từ nhà cung cấp, chạy đồng bộ hay gửi tin nhắn. Chúng cũng không chứng minh mọi trình kết nối nhà cung cấp đã hoạt động. Hãy điều tra dữ liệu thiếu hoặc cũ tại nguồn. Kết quả trống không chứng minh người đó không có trong Brevo.

Dùng tài liệu Tajo MCP để kết nối ứng dụng khách được hỗ trợ và kiểm tra công cụ thực sự có sẵn trong không gian làm việc được cấp quyền của bạn. Bảng tương tác có thể giúp việc xem xét dễ hơn nếu ứng dụng chủ hỗ trợ MCP Apps; kết quả dạng văn bản vẫn cần giải thích kết quả.

Gọi công cụ không đồng nghĩa với đồng bộ lâu dài

Đồng bộ định kỳ còn cần lịch chạy, định danh bản ghi ổn định, tiến độ được lưu, quyết định thử lại và hồ sơ các lần ghi hoàn tất. Ứng dụng thực thi chịu trách nhiệm về những phần đó. MCP chuẩn hóa quyền truy cập công cụ; chỉ liệt kê công cụ không tạo ra các quy tắc nghiệp vụ này.

Sau khi hết thời gian chờ, thao tác đọc thường có thể lặp lại. Một lần gửi hay thanh toán có thể đã xảy ra. Hãy giữ hồ sơ thực thi và đối chiếu kết quả trước khi thử lại. Độ tin cậy của mô hình không cấp phép cho hành động hoặc khiến việc lặp lại trở nên an toàn.

Để xem thao tác ghi liên hệ ở đích, hãy đọc hướng dẫn API Brevo. Khi nào trường đã tính cần luồng đồng bộ được duy trì riêng được giải thích trong reverse ETL.

Hóa đơn bảo mật đi kèm giao thức

Lời phản bác đáng được nêu đầy đủ: “MCP đưa cho một mô hình xác suất danh sách các hàm có thể xóa dữ liệu và gửi email, rồi tin vào văn bản do người lạ viết để mô tả chúng. Đó không phải tiêu chuẩn tích hợp. Đó là một cuộc tấn công chuỗi cung ứng có kèm đặc tả.” Phần lớn điều đó là đúng. Chính đặc tả cũng đồng ý với tiền đề này. Phần bảo mật của nó nói rằng công cụ “tương đương với thực thi mã tùy ý và phải được xử lý thận trọng thích đáng,” rằng mô tả công cụ “nên được coi là không đáng tin, trừ khi lấy từ một máy chủ đáng tin cậy,” và rằng MCP “không thể thực thi các nguyên tắc bảo mật này ở cấp giao thức.”

Đây là hồ sơ cho tới nay:

• Tool poisoning (đầu độc công cụ). Công bố tháng 4 năm 2025 của Invariant Labs, chính là công cụ add ở trên. Cùng bài viết đó còn mô tả rug pull, khi máy chủ thay đổi mô tả công cụ sau khi bạn đã phê duyệt, và shadowing, khi một máy chủ độc hại viết lại hành vi của mô hình đối với một máy chủ đáng tin khác.
• Máy chủ cục bộ bị xâm nhập. Tháng 7 năm 2025, JFrog công bố CVE-2025-6514 trong mcp-remote các phiên bản 0.0.5 tới 0.1.15, lỗ hổng cho phép một máy chủ độc hại chạy lệnh trên máy người dùng. Cũng mùa hè đó, CVE-2025-49596 ảnh hưởng tới chính MCP Inspector của Anthropic, công cụ được phát hành mà mặc định không có xác thực.
• Phình phạm vi quyền. Các thực hành bảo mật tốt nhất chính thức gọi tên kiểu lỗi này: token được cấp files:* hoặc admin:* ngay từ đầu vì máy chủ liệt kê mọi phạm vi và client yêu cầu tất cả.
• Lo ngại từ cơ quan nhà nước. Tháng 5 năm 2026, Cơ quan An ninh Quốc gia Hoa Kỳ (NSA) cho biết “sự lan rộng nhanh chóng” của MCP “đã vượt trước sự phát triển của mô hình bảo mật của nó.”

Lời phản bác sai ở kết luận. Giải pháp chưa bao giờ là ngừng kết nối mô hình với hệ thống; các đội đã làm việc đó từ trước, bằng cách dán API key thô vào prompt và script, hoàn toàn không có nhật ký kiểm toán. Giải pháp là đối xử với máy chủ MCP như mọi phụ thuộc có đặc quyền khác:

• Chỉ cài máy chủ từ những nguồn mà bạn sẵn sàng giao cùng thông tin xác thực đó ngay cả bên ngoài MCP.
• Ưu tiên máy chủ từ xa dùng OAuth và phạm vi hẹp thay vì tệp nhị phân cục bộ giữ khóa dài hạn.
• Bắt buộc con người phê duyệt mọi thao tác ghi, và ghi lại ai đã phê duyệt điều gì.
• Ghim phiên bản máy chủ, và xem xét lại khi mô tả của một công cụ thay đổi.
• Mở ra các công cụ bám sát tác vụ, không phải toàn bộ API; mô hình không thể lạm dụng một endpoint xóa chưa từng được mở ra.

Giao thức đã chuẩn hóa chiếc thùng. Kiểm tra hàng bên trong vẫn là việc của bạn.

Tự xây máy chủ MCP hay dùng máy chủ có sẵn

Các thư mục công khai như mcp.so tập hợp máy chủ do cộng đồng xây dựng, và nhiều nhà cung cấp SaaS phát hành máy chủ của riêng họ. Ví dụ, Brevo cung cấp một máy chủ MCP còn được tách thành các máy chủ riêng lẻ, nên có thể cho một tác nhân AI quyền với danh bạ mà không có quyền với chiến dịch. Quyết định này ít phụ thuộc vào công sức mà phụ thuộc nhiều hơn vào việc ai nên làm chủ hình dạng của các công cụ.

Tác nhân AI của bạn nên dùng máy chủ MCP nào?

1. Nhà cung cấp phát hành máy chủ đáp ứng được tác vụ

   Dùng máy chủ của nhà cung cấp

   Nó bám theo API và được nhà cung cấp bảo trì.

2. Một hệ thống, nhưng bạn cần ít thao tác hơn hoặc an toàn hơn

   Dùng nó, nhưng thu hẹp phạm vi

   Cấp phạm vi tối thiểu và chỉ mở những nhóm công cụ tác nhân cần.

3. Dữ liệu nội bộ hoặc hệ thống chưa có máy chủ

   Xây một máy chủ nhỏ

   Vài công cụ bám sát tác vụ trên API của chính bạn, với cơ chế xác thực của chính bạn.

4. Tác vụ trải qua hai hệ thống trở lên

   Xây hoặc áp dụng một lớp có quản trị

   Một bộ công cụ, quy tắc đồng ý và lịch sử kiểm toán chung cho tất cả hệ thống.

Xây một máy chủ cơ bản là phần dễ. Với SDK chính thức, một máy chủ stdio chạy được với một công cụ chỉ mất một buổi chiều. Cái giá đến sau: OAuth cho phiên bản HTTP, các thay đổi ngừng khuyến nghị (bản sửa đổi 2026-07-28 đã ngừng khuyến nghị Roots, Sampling và Logging, cùng Dynamic Client Registration), và công việc liên tục là viết mô tả công cụ sao cho mô hình đọc đúng. Bọc API theo kiểu mỗi endpoint một công cụ là sai lầm phổ biến nhất. Mỗi mô tả công cụ là văn bản mà mô hình phải đọc và cân nhắc, nên một danh sách ngắn các công cụ bám sát tác vụ tốt hơn toàn bộ bề mặt API.

MCP, API, tích hợp và iPaaS

MCP không thay thế API. Gần như mọi máy chủ MCP đều là lớp bọc quanh một API. API vẫn là nơi công việc diễn ra, với giới hạn tần suất, mô hình dữ liệu và những điểm kỳ quặc riêng. Điều MCP thay đổi là ai có thể gọi nó: một mô hình, vào lúc chạy, chọn lệnh gọi dựa trên mô tả thay vì một lập trình viên viết cứng từ trước.

Sự khác biệt đó vạch ra ranh giới rõ ràng với hai thứ khác hay bị nhầm lẫn với MCP:

• Tích hợp và iPaaS (các nền tảng chính được so sánh tại đây) di chuyển dữ liệu theo lịch hoặc theo trình kích hoạt, một cách tất định, dù có ai đang trò chuyện hay không. Một lượt đồng bộ hằng đêm 40.000 đơn hàng vào CRM không nên phụ thuộc vào việc một mô hình quyết định thực hiện 40.000 lệnh gọi công cụ.
• Reverse ETL đẩy dữ liệu đã mô hình hóa từ kho dữ liệu trở lại các công cụ vận hành. Reverse ETL là gì và khi nào phù hợp là một chủ đề riêng, và nó là một đường ống dữ liệu, không phải một cuộc trò chuyện.
• MCP dành cho những lúc một người hoặc một tác nhân AI cần hỏi, kiểm tra hoặc hành động xuyên qua các hệ thống đó, theo nhu cầu.

Sai lầm xảy ra theo cả hai chiều. Có đội xây máy chủ MCP để đồng bộ hàng loạt, và họ nhận về những đường ống chậm, đắt và không lặp lại được. Có đội xây tích hợp cẩn thận rồi đưa cho trợ lý AI một API key thô để truy vấn chúng, và họ nhận về một cửa sau không ai quản trị.

Với một tích hợp được hỗ trợ, tác vụ lâu dài và công cụ kiểm tra tác vụ nên dùng chung ranh giới quyền hạn rõ ràng. Hãy xác minh trình kết nối, hành động được phép và kết quả đã ghi cho luồng cụ thể. Tài liệu tích hợp phân biệt hướng dẫn thiết lập với những luồng vẫn cần bằng chứng vận hành. MCP có thể cung cấp các công cụ đã được phê duyệt riêng; danh sách công cụ không chứng minh đồng bộ định kỳ hoặc mọi biện pháp kiểm soát đã hoạt động.

Trong 22 tháng, MCP đi từ sáu máy chủ tham chiếu tới một dự án của Linux Foundation mà Claude, ChatGPT, VS Code và Cursor đều sử dụng. Kết nối một mô hình với một hệ thống giờ là phần rẻ. Quyết định nó được phép làm gì ở đó mới là công việc thật.