MCP server là gì? Cách hoạt động, kết nối và rủi ro

Model Context Protocol (MCP) server, hay MCP server, là một lớp trừu tượng (abstraction layer) trung gian được thiết kế để chuẩn hóa giao tiếp giữa các mô hình ngôn ngữ lớn (LLM) và các hệ thống dữ liệu hoặc công cụ bên ngoài.

Thay vì phải nuôi hàng loạt tích hợp tùy chỉnh (custom integrations) cho từng cặp ứng dụng và nguồn dữ liệu, bạn chỉ dựng một giao diện hợp đồng (interface contract) duy nhất rồi cắm mọi thứ vào đó.

Thứ MCP server muốn dẹp là các rào cản dữ liệu (information silos): tài liệu nằm một nơi, mã nguồn nằm một nơi, còn mô hình đứng ngoài nhìn vào, không với tới được nơi nào cả.

Bằng cách cung cấp một giao diện kết nối nhất quán, MCP server chuyển đổi AI từ một hệ thống tạo văn bản thụ động thành một tác nhân (AI agent) có khả năng thực thi hành động, truy vấn tài nguyên và tương tác trực tiếp với các quy trình kỹ thuật phức tạp trong thời gian thực.

Một lưu ý nhỏ trước khi đi tiếp, vì nó xuất hiện xuyên suốt bài: MCP không đánh số phiên bản kiểu 1.0 hay 2.0, mà đặt tên mỗi bản đặc tả kỹ thuật (specification) theo đúng ngày bản đó phát hành. Bản 2026-07-28, do nhóm phát triển Model Context Protocol công bố, là bản mới nhất tính đến lúc bài này lên trang, và mọi mô tả kỹ thuật bên dưới đều bám theo nó.

Minh hoạ MCP server như một đầu nối tiêu chuẩn duy nhất giữa mô hình AI và nhiều hệ thống dữ liệu, công cụ bên ngoài

MCP server là gì và vì sao cần tới nó

Anthropic giới thiệu Model Context Protocol (MCP) vào tháng 11/2024 để dọn một mớ việc lặp đi lặp lại khi xây trình kết nối dữ liệu cho AI. Trước MCP, muốn cho một mô hình ngôn ngữ lớn (LLM) đọc được Slack, GitHub hay cơ sở dữ liệu nội bộ, kỹ sư phải viết một lớp trung gian (middleware) riêng cho từng nền tảng, và lớp nào cũng na ná lớp nào. MCP server cắt vòng lặp đó bằng cách chuẩn hóa cách trao đổi ngữ cảnh (context) và công cụ (tools) qua một giao thức chung.

So sánh mô hình tích hợp cũ với nhiều đoạn middleware riêng cho từng nền tảng và mô hình mới dùng chung một giao diện MCP duy nhất

Trong kiến trúc host-client-server của MCP, Host (ví dụ: Claude Desktop, hoặc trình soạn thảo lập trình IDE) khởi tạo các client để thiết lập kết nối tới các MCP server, còn server đóng vai bên cung cấp tài nguyên và khả năng thực thi cho mô hình. Các bộ công cụ phát triển (SDK) cho TypeScript và Python đã vượt mốc 1 tỷ lượt tải xuống, nên dù bạn thích hay không, MCP giờ đã là tầng hạ tầng khó thay thế cho các hệ thống AI dạng tác nhân (agentic).

Một server cung cấp gì: tools, resources và prompts

Công cụ (Tools) là các hàm thực thi (executable functions) cho phép mô hình chủ động ra tay: đổi trạng thái hệ thống hoặc gọi một API động. Mỗi công cụ được định nghĩa qua một lược đồ (schema) chặt chẽ, mô tả tham số đầu vào và kiểu dữ liệu đầu ra để mô hình gọi lệnh cho đúng. Điểm đáng nhớ trong thiết kế là quyền kiểm soát Tools thuộc về mô hình (Model-controlled): dựa trên logic suy luận và yêu cầu của người dùng, chính mô hình quyết định lúc nào gọi công cụ nào. Nghe thì tiện, nhưng đây cũng là chỗ mọi rủi ro trong bài này bắt đầu.

Ba thành phần một MCP server cung cấp gồm tools do mô hình điều khiển, resources do ứng dụng điều khiển và prompts do người dùng điều khiển

Tài nguyên (Resources) là các nguồn dữ liệu tĩnh hoặc động cung cấp ngữ cảnh đọc cho mô hình, hoạt động thụ động và do ứng dụng điều khiển (Application-controlled). Resources có thể là nội dung tệp tin, nhật ký hệ thống hoặc tài liệu API, dưới dạng Tài nguyên trực tiếp (Direct Resources) với địa chỉ URI cố định, hoặc Bản mẫu tài nguyên (Resource Templates) cho phép truy vấn linh hoạt hơn. Khác với Tools, ở đây ứng dụng mới là bên quyết định tài nguyên nào được nạp vào cửa sổ ngữ cảnh, còn logic suy luận của mô hình không chen vào.

Lời nhắc (Prompts) là các bản mẫu tương tác được tham số hóa, dùng để chuẩn hóa những luồng công việc (workflows) lặp lại. Prompts hoàn toàn do người dùng kiểm soát (User-controlled) qua các lệnh gọi tường minh như lệnh slash, nên một tác vụ rối rắm được rút xuống thành vài bước nhập liệu có cấu trúc. Nhờ Prompts mà mô hình vẫn bám đúng chỉ dẫn đặc thù của hệ thống, kể cả khi người dùng cuối hỏi mỗi lần một kiểu.

Server cục bộ và server từ xa: stdio và Streamable HTTP

Mọi giao tiếp trong MCP đều chạy trên JSON-RPC 2.0. Để vận chuyển các thông điệp đó, MCP hỗ trợ nhiều phương thức vận chuyển (transports) khác nhau, tùy vào chỗ MCP server thực sự chạy (runtime).

Sơ đồ so sánh server cục bộ chạy qua stdio như một tiến trình con với server từ xa giao tiếp qua Streamable HTTP

Với server chạy cục bộ, stdio là phương thức vận chuyển tiêu chuẩn: client khởi chạy server như một tiến trình con (child process) rồi trao đổi dữ liệu qua luồng nhập/xuất tiêu chuẩn. Đây là cơ chế gọn nhất cho công cụ phát triển cá nhân hoặc các tích hợp cần đụng thẳng vào hệ thống tệp cục bộ với độ trễ thấp nhất, và cũng là cách gần như ai cũng chạy MCP server đầu tiên của mình.

Với kiến trúc phân tán, Streamable HTTP mới là lựa chọn cho server từ xa. Cơ chế này gửi tin nhắn qua HTTP POST và nhận phản hồi qua luồng SSE (Server-Sent Events — máy chủ tự đẩy dữ liệu về phía client) hoặc một đối tượng JSON. Trong bản đặc tả 2026-07-28, Streamable HTTP chỉ dùng một điểm truy cập (endpoint) duy nhất cho mọi yêu cầu, đồng thời ánh xạ các trường trong thân tin nhắn (body) lên HTTP header (như Mcp-Method), để gateway hoặc bộ cân bằng tải định tuyến được mà khỏi phải giải mã toàn bộ nội dung JSON.

Bản đặc tả 2026-07-28 đã thay đổi những gì

Bản cập nhật ngày 28/07/2026 tái cấu trúc MCP thành một giao thức phi trạng thái (Stateless) hoàn toàn, đổi lấy khả năng mở rộng. Thay đổi nặng ký nhất là việc bỏ hẳn bước bắt tay initialize / initialized cùng header Mcp-Session-Id. Giờ mỗi request là một đơn vị độc lập và tự mô tả (self-describing), nên bất kỳ bản chạy (instance) nào phía sau bộ cân bằng tải chia lượt luân phiên (round-robin) cũng xử lý được, không cần chia sẻ trạng thái phiên (session state).

Sơ đồ chuyển từ giao thức có trạng thái với bước bắt tay phiên sang giao thức phi trạng thái nơi mỗi request tự mô tả và đi tới bất kỳ instance nào

Yêu cầu đa vòng (Multi Round-Trip Requests - MRTR) là thứ lấp vào chỗ trống mà các dòng dữ liệu hai chiều duy trì liên tục (bidirectional streams) để lại. MRTR cho phép server hỏi thêm thông tin hoặc xin xác nhận của người dùng ngay giữa cuộc gọi (trả về resultType: "input_required"), rồi client gọi lại với dữ liệu bổ sung. Ngoài ra còn có gợi ý TTL (Time-To-Live — thời gian dữ liệu còn hiệu lực) cho danh sách công cụ và tài nguyên, nhờ đó client làm được bộ nhớ đệm (caching), bớt truy vấn lặp và giữ cho cửa sổ ngữ cảnh đỡ phình.

Tìm và tin một MCP server: registry chính thức

MCP Registry là kho lưu trữ siêu dữ liệu (metadata) tập trung, có Anthropic, GitHub và Microsoft đứng sau. Để truy được nguồn gốc và tính xác thực (provenance), hệ thống dùng xác thực không gian tên (Namespace authentication) qua DNS (hệ thống tên miền) hoặc GitHub. Các server được định danh theo định dạng DNS ngược (ví dụ: io.github.username/server hoặc com.example/server), tức là nhà phát triển phải chứng minh được mình sở hữu cái tên đó.

Số liệu khảo sát hệ sinh thái tháng 7/2026 kém đẹp hơn danh sách đăng ký nhiều:

Tổng số 18.849 server đã đăng ký, trong đó server từ xa chiếm 49,9% (9.312 server).
Tính sẵn sàng: khoảng 17,2% server từ xa hiện ở trạng thái "chết", tức là gọi vào không thèm trả lời.
Xếp hạng chất lượng: chỉ 53,1% đạt hạng A, còn 29,2% nằm ở hạng D hoặc F vì lỗi giao thức hoặc thiếu mô tả công cụ.

Gần một phần ba số server đăng ký nằm ở hạng D hoặc F, nên có tên trong registry chẳng nói lên điều gì về chất lượng. Khi chọn server cho môi trường production, hãy đọc các bảng xếp hạng này trước đã. Bản thân registry cũng chỉ lưu siêu dữ liệu trỏ tới mã nguồn, còn việc quét bảo mật mã thực thi được đẩy xuống các kho gói (package registry) bên dưới như npm hay Docker Hub.

Rủi ro bảo mật khi chạy một MCP server

Khi AI trở thành một tác nhân thực thi, bề mặt tấn công rộng ra theo: tiêm chỉ thị gián tiếp (indirect prompt injection), nhiễm độc công cụ (tool poisoning) và lây lan tấn công (lateral movement). Khó chịu nhất là SSRF (Server-Side Request Forgery) trong lúc khám phá metadata của OAuth (chuẩn cấp quyền truy cập). Kẻ tấn công thao túng các URL metadata để lừa client gọi vào những dải IP nội bộ (private IP ranges) hoặc các điểm truy cập nhạy cảm như dịch vụ metadata của máy chủ đám mây (cloud metadata services, ví dụ: 169.254.169.254), rồi lấy sạch thông tin định danh instance.

Sơ đồ bề mặt tấn công của một MCP server gồm mô tả công cụ bị nhiễm độc, vấn đề confused deputy và tấn công SSRF

Nếu cả bài này chỉ có một mục đáng đọc kỹ, tôi chọn mục này, vì những sự cố dưới đây đều đã xảy ra thật:

Tháng 11/2025, một lỗ hổng thực thi mã từ xa tại Git MCP server của Anthropic, do bỏ qua kiểm tra đường dẫn và tiêm tham số.
Tháng 11/2025, rò rỉ dữ liệu WhatsApp vì mô tả công cụ bị nhiễm độc, thao túng cách tác nhân dùng một tích hợp hoàn toàn hợp lệ.
Tháng 09/2025, gói npm postmark-mcp lặng lẽ thêm BCC vào mọi email gửi đi để đánh cắp dữ liệu.

Bên cạnh đó, vấn đề "Confused Deputy" vẫn luôn nằm sẵn ở đó: server thực thi hành động bằng đặc quyền của chính nó, chứ không phải đặc quyền bị giới hạn của người dùng đang yêu cầu.

Cái giá của việc kết nối quá nhiều server

Nạp quá nhiều định nghĩa công cụ vào cửa sổ ngữ cảnh sẽ ngốn token và kéo dài độ trễ, mà bạn trả tiền cho cả hai. Để né chuyện đó, kiến trúc hiện đại chuyển sang Chế độ mã (Code Mode): thay vì để mô hình gọi trực tiếp từng công cụ, mô hình viết một kịch bản thực thi (execution script) rồi nói chuyện với MCP server như với một API cục bộ, trong môi trường sandbox (môi trường chạy cách ly).

So sánh việc nạp toàn bộ định nghĩa công cụ vào cửa sổ ngữ cảnh với cách chạy mã trong sandbox và chỉ trả kết quả cuối về cho mô hình

Cách này giảm tới 98,7% lượng token tiêu thụ, từ 150.000 token xuống còn 2.000 token trong kịch bản được đo. Con số nghe như trò ảo thuật, nhưng lý do rất tầm thường: dữ liệu trung gian thôi "ping-pong" qua lại cửa sổ ngữ cảnh của mô hình (ví dụ: tải file từ Drive rồi đẩy sang Salesforce), vì toàn bộ khâu xử lý diễn ra ngay trong môi trường thực thi và chỉ kết quả cuối cùng mới trả về cho mô hình. Nó vừa rẻ hơn, vừa giữ được dữ liệu nhạy cảm nằm ngoài ngữ cảnh của mô hình.

Khi nào bạn thực sự cần một MCP server

Bạn cần MCP server khi hệ thống AI phải hành động xuyên qua các nền tảng dữ liệu phân mảnh (CRM, Email, Slack) mới xong được việc. Còn nếu nhu cầu chỉ dừng ở sinh văn bản, dựng thêm lớp hạ tầng này là tiêu tiền cho vui. Khi bắt tay vào viết server đầu tiên, hướng dẫn tạo MCP server bằng Python đi qua trọn vòng đời từ khai báo công cụ tới kết nối vào Claude Desktop.

Trước khi đưa vào vận hành, có bốn nguyên tắc tôi coi là bắt buộc: cấp quyền hẹp nhất có thể cho từng công cụ (least privilege); bắt con người duyệt các hành động nhạy cảm như chuyển tiền hay xóa dữ liệu; chạy server trong sandbox hoặc container để giới hạn tầm với của nó; và chặn các dải IP nội bộ để kiểm soát SSRF. Bốn việc đó làm mất một buổi chiều, ít hơn nhiều so với thời gian dọn hậu quả của một trong ba sự cố phía trên.