MCP (Model Context Protocol)
1. Tổng quan
Định nghĩa: MCP (Model Context Protocol) là giao thức mở được đề xuất nhằm giúp các ứng dụng AI dựa trên LLM kết nối theo cách chuẩn hóa với ngữ cảnh như công cụ, dữ liệu và prompt bên ngoài; đây là một “giao diện tích hợp dành cho AI” hoạt động theo cấu trúc Host–Client–Server trên quy ước thông điệp JSON-RPC 2.0.
Khi AI tạo sinh được đưa vào nghiệp vụ thực tế, nút thắt lớn nhất không phải là bản thân hiệu năng mô hình mà là sự thiếu vắng phương thức để mô hình truy cập an toàn vào dữ liệu, hệ thống và công cụ nội bộ doanh nghiệp. LLM không biết thông tin sau thời điểm huấn luyện (đứt gãy tri thức) và bị cô lập khỏi DB, tệp, SaaS, API nội bộ, nên nguyên trạng không thể thực hiện yêu cầu “hãy tóm tắt biên bản họp và tạo ticket trên Jira”. Trước đây, để giải quyết điều này, mỗi ứng dụng tự định nghĩa lược đồ gọi hàm (Function Calling) riêng và hiện thực connector riêng cho từng nguồn dữ liệu, dẫn đến cái gọi là bài toán tích hợp M×N. Tức là để nối M ứng dụng AI với N công cụ, mỗi lần phải tạo mới M×N tích hợp tùy biến, và khi một công cụ thay đổi thì phải sửa mọi ứng dụng sử dụng nó — một địa ngục bảo trì.
MCP giải quyết vấn đề này bằng một “cổng chuẩn” được ví như USB-C. Nhà cung cấp công cụ chỉ cần hiện thực MCP server một lần là mọi ứng dụng AI (Host) hỗ trợ MCP đều có thể tái sử dụng, còn nhà phát triển ứng dụng AI chỉ cần tích hợp MCP client là có thể kết nối ngay tới vô số server trong hệ sinh thái. Kết quả là độ phức tạp tích hợp giảm từ M×N xuống M+N, mức độ gắn kết giữa công cụ và mô hình giảm, cho phép mỗi bên tiến hóa độc lập. Nhờ tính mở này, MCP không phải là sản phẩm của một nhà cung cấp cụ thể mà đang nhanh chóng lan rộng thành tiêu chuẩn tích hợp trên thực tế (de facto) được nhiều IDE, framework agent và trợ lý thương mại cùng áp dụng.
Đặc điểm của MCP được tổng hợp như sau. Thứ nhất, là tiêu chuẩn mở, không phụ thuộc mô hình, không bị ràng buộc vào một LLM hay nhà cung cấp cụ thể. Thứ hai, bảo đảm khả năng tương tác thông qua quy ước thông điệp rõ ràng dựa trên JSON-RPC 2.0 và thương lượng năng lực (capability negotiation). Thứ ba, tiêu chuẩn hóa 3 yếu tố của ngữ cảnh gồm không chỉ công cụ mà cả tài nguyên (dữ liệu) và prompt (mẫu). Thứ tư, tách tầng truyền tải giữa cục bộ (stdio) và từ xa (HTTP), linh hoạt với hình thức triển khai.
2. Cấu trúc tổng thể và các thành phần của MCP
MCP gồm 3 tầng: Host là ứng dụng AI đối diện người dùng, Client duy trì phiên 1:1 với một server bên trong Host, và Server phơi bày công cụ và dữ liệu thực tế. Host tạo nhiều Client để kết nối song song tới các Server khác nhau, và mỗi cặp Client-Server hình thành một ranh giới bảo mật độc lập.
graph TB
subgraph Host["MCP Host (Ứng dụng AI)"]
LLM["LLM / Công cụ suy luận"]
C1["MCP Client 1"]
C2["MCP Client 2"]
C3["MCP Client 3"]
end
S1["MCP Server A<br/>(Hệ thống tệp)"]
S2["MCP Server B<br/>(DB nội bộ)"]
S3["MCP Server C<br/>(SaaS API bên ngoài)"]
LLM --- C1
LLM --- C2
LLM --- C3
C1 <-->|JSON-RPC 2.0| S1
C2 <-->|JSON-RPC 2.0| S2
C3 <-->|JSON-RPC 2.0| S3
S1 --- D1[("Tệp cục bộ")]
S2 --- D2[("RDB")]
S3 --- D3["REST API"]
A. Host — Host là ứng dụng AI mà người dùng cuối tương tác trực tiếp như Claude Desktop, IDE như Cursor, VS Code, hay agent tự hành. Nó điều phối các lời gọi LLM, cung cấp UI phê duyệt quyền (consent) cho người dùng và quản lý vòng đời của nhiều Client từ khi tạo đến khi kết thúc.
Trách nhiệm cốt lõi của Host là đóng vai trò điểm thực thi chính sách bảo mật (Policy Enforcement Point). Vai trò của Host là không để mô hình tùy tiện gọi các công cụ mà server phơi bày, bằng cách xin xác nhận của người dùng trước khi thực thi hoặc chặn theo chính sách. Ví dụ, khi mô hình định gọi công cụ “xóa tệp”, Host yêu cầu người dùng phê duyệt, và nếu không có phê duyệt thì yêu cầu không được chuyển tới server. Cấu trúc đặt server và mô hình bên ngoài ranh giới tin cậy và tập trung kiểm soát vào Host chính là điểm xuất phát của mô hình bảo mật MCP.
B. Client — Client là trung gian được nhúng trong Host, duy trì phiên có trạng thái (stateful) với một Server. Khi khởi tạo kết nối, nó thực hiện thương lượng năng lực (capability negotiation) trao đổi phiên bản giao thức và chức năng được hỗ trợ, khám phá (discovery) danh sách công cụ, tài nguyên, prompt mà server cung cấp, chuyển lời gọi công cụ do mô hình quyết định tới server, rồi xử lý kết quả và thông báo (notification) để trả lại cho mô hình.
Ràng buộc Client và Server bắt buộc tương ứng 1:1 không chỉ là quy tắc hiện thực đơn thuần mà là cơ chế cô lập (isolation). Vì các server có mức độ tin cậy khác nhau không dùng chung một phiên, nên về mặt cấu trúc ngăn được việc server bên ngoài có độ tin cậy thấp truy cập ngữ cảnh hoặc thông tin xác thực của server DB nội bộ. Tuyến phòng thủ đầu tiên nhằm giảm rủi ro người ủy quyền bị nhầm lẫn (confused deputy) phát sinh khi kết hợp nhiều server được hình thành tại đây.
C. Server — Server là tiến trình độc lập đóng gói một chức năng cụ thể và phơi bày qua giao diện chuẩn. Bất cứ thứ gì như hệ thống tệp nội bộ, cơ sở dữ liệu, kho Git, API thanh toán bên ngoài đều có thể được bọc thành server, và server chỉ cần quản lý xác thực và phân quyền của hệ thống mà nó bọc, không cần biết mô hình nào được gắn vào.
Nhờ sự đóng gói này, server được tái sử dụng và triển khai độc lập với ứng dụng AI cụ thể, và dù logic công cụ thay đổi, chỉ cần giữ nguyên giao diện (lược đồ) thì không phải sửa phía tiêu thụ. Server cung cấp cho client năng lực (primitive) thuộc ba phạm trù công cụ, tài nguyên, prompt, và vì sự phân biệt 3 yếu tố này là cốt lõi của thiết kế MCP nên sẽ được trình bày riêng ở phần dưới.
Tổng hợp trách nhiệm và chủ thể kiểm soát theo từng thành phần của MCP thành bảng như sau. Tuy nhiên, bảng chỉ là tóm tắt, còn bản chất nằm ở phần giải thích trong các đoạn trên về lý do mỗi thành phần được tách như vậy.
| Thành phần | Vai trò | Chủ thể kiểm soát | Ví dụ tiêu biểu |
|---|---|---|---|
| Host | Điều phối LLM·Phê duyệt quyền·Quản lý phiên | Người dùng | Claude Desktop, Cursor, agent tự hành |
| Client | Phiên 1:1 với server·Thương lượng năng lực·Chuyển tiếp thông điệp | Host | Mô-đun connector bên trong Host |
| Server | Phơi bày công cụ·Tài nguyên·Prompt | Nhà phát triển server | Server hệ thống tệp/DB/GitHub |
3. 3 primitive chính của server và thủ tục giao tiếp
A. Công cụ (Tools) — do mô hình kiểm soát (model-controlled) — Công cụ là hàm có thể thực thi mà mô hình tự phán đoán để gọi. Mỗi công cụ có tên, mô tả và lược đồ đầu vào (JSON Schema), và mô hình chỉ nhìn vào siêu dữ liệu này để quyết định gọi công cụ nào với tham số nào. Do đó, mô tả bằng ngôn ngữ tự nhiên (description) của công cụ không chỉ là tài liệu đơn thuần mà gần với một đặc tả có thể thực thi ảnh hưởng trực tiếp đến lựa chọn của mô hình.
Công cụ thường đi kèm tác dụng phụ (side effect) làm thay đổi trạng thái như “gửi email”, “thực thi SQL”, “thực thi mã”. Vì vậy MCP khuyến nghị mẫu con người trong vòng lặp (HITL), không để mô hình tự ý xác nhận việc thực thi công cụ mà để Host xin phê duyệt của người dùng ngay trước khi thực thi. Ví dụ, khi phơi bày công cụ create_issue(title, body), có thể thiết kế sao cho mô hình đề xuất tạo issue từ bản tóm tắt cuộc họp, còn việc tạo thực tế chỉ xảy ra khi người dùng nhấn nút phê duyệt. Sự tách biệt này bảo đảm đồng thời sự tiện lợi của tự động hóa và khả năng kiểm soát.
B. Tài nguyên (Resources) — do ứng dụng kiểm soát (application-controlled) — Tài nguyên là dữ liệu được cung cấp cho mô hình như ngữ cảnh để đọc như tệp, bản ghi DB, nhật ký, hình ảnh. Mỗi tài nguyên được định danh bằng URI và không có tác dụng phụ, đó là điểm khác biệt căn bản với công cụ. Nếu công cụ là “hành động” thì tài nguyên là “tri thức”.
Điều quan trọng là việc đưa tài nguyên nào vào ngữ cảnh do ứng dụng (hoặc người dùng) quyết định chứ không phải mô hình. Đây là thiết kế nhằm ngăn chặn việc phơi bày thông tin không cần thiết và làm nhiễm bẩn ngữ cảnh, bằng cách để ứng dụng kiểm soát phạm vi dữ liệu mà mô hình có thể truy cập. Ví dụ, khi người dùng chọn một tài liệu thiết kế cụ thể và đính kèm vào cuộc hội thoại, Host đọc tài nguyên đó từ server và chèn vào prompt, còn các tài liệu không được chọn sẽ không lọt vào tầm nhìn của mô hình. Phương thức này cũng kết hợp tự nhiên với luồng truy xuất-chèn của RAG.
C. Prompt (Prompts) — do người dùng kiểm soát (user-controlled) — Prompt là mẫu và quy trình làm việc có thể tái sử dụng được server định nghĩa sẵn và cung cấp. Chúng được phơi bày cho người dùng dưới dạng lệnh slash hoặc nút bấm, giúp tiêu chuẩn hóa các chỉ dẫn phức tạp và lặp lại. Ví dụ, prompt “review mã” cung cấp mẫu chứa các góc nhìn review (bảo mật, hiệu năng, khả năng đọc) và định dạng đầu ra, hướng tới review có chất lượng đồng nhất mỗi lần.
Như vậy, việc phân chia rõ ràng chủ thể kiểm soát (mô hình/ứng dụng/người dùng) thành 3 yếu tố là thiết kế cốt lõi nâng cao tính an toàn và khả năng dự đoán của MCP. Nguyên tắc hành vi có tác dụng phụ lớn thì mô hình đề xuất nhưng người dùng phê duyệt, phạm vi phơi bày dữ liệu do ứng dụng kiểm soát, quy trình lặp lại do người dùng gọi tường minh đã được nội tại hóa ở cấp giao thức, nên sự cân bằng giữa tính tự chủ và kiểm soát trở thành một phần của tiêu chuẩn chứ không phải tùy ý của từng hiện thực.
Giao tiếp diễn ra trên JSON-RPC 2.0 theo thứ tự khởi tạo → khám phá → thực thi. Chuỗi dưới đây là luồng tiêu biểu của một lời gọi công cụ.
sequenceDiagram
participant U as Người dùng
participant H as Host + Client
participant L as LLM
participant S as MCP Server
U->>H: Yêu cầu("Tra cứu doanh thu tuần này")
H->>S: initialize (thương lượng phiên bản·năng lực)
S-->>H: Phản hồi capabilities
H->>S: tools/list (khám phá công cụ)
S-->>H: Danh sách công cụ + lược đồ
H->>L: Chuyển prompt + công cụ khả dụng
L-->>H: Yêu cầu tools/call("query_sales")
H->>U: Yêu cầu phê duyệt thực thi
U-->>H: Phê duyệt
H->>S: tools/call(query_sales, tham số)
S-->>H: Kết quả thực thi(JSON)
H->>L: Chèn kết quả rồi suy luận lại
L-->>H: Câu trả lời cuối cùng
H-->>U: "Doanh thu tuần này là ..."
Tầng truyền tải (transport) được chọn theo hình thức triển khai. stdio khởi chạy server như tiến trình cục bộ trên cùng máy với Host và giao tiếp qua đầu vào/đầu ra chuẩn, độ trễ thấp và không phơi ra mạng nên phù hợp để truy cập tệp cục bộ và công cụ phát triển. Truyền tải dựa trên HTTP (hỗ trợ streaming) được dùng khi kết nối qua mạng tới server từ xa, và đặc tả gần đây hướng tới lõi phi trạng thái (stateless) để có thể mở rộng trên hạ tầng HTTP thông thường (load balancer, serverless) mà không cần lưu trạng thái riêng. Đặc tính và điểm kiểm soát của hai phương thức truyền tải như sau.
| Phân loại | stdio (cục bộ) | HTTP (từ xa) |
|---|---|---|
| Bố trí | Cùng máy với Host, tiến trình con | Server riêng bên kia mạng |
| Độ trễ/Phơi bày | Thấp / Không phơi ra mạng | Tương đối cao / Điểm tiếp xúc công khai |
| Xác thực | Tin cậy tiến trình cục bộ | Token OAuth 2.1/OIDC |
| Trường hợp phù hợp | Hệ thống tệp·IDE·Terminal | SaaS·API dùng chung nội bộ |
Đối với server từ xa, đặc tả bao gồm hệ thống ủy quyền căn chỉnh theo OAuth 2.1/OIDC, cho phép áp dụng kiểm soát truy cập dựa trên token và luồng thông tin xác thực chuẩn. Đây là nỗ lực hội tụ về tiêu chuẩn vấn đề mỗi server tự hiện thực xác thực và ủy quyền theo cách riêng trong triển khai từ xa, gắn trực tiếp với việc ứng phó lỗ hổng bảo mật của server từ xa sẽ được đề cập ở phần sau.
4. So sánh với các khái niệm tương tự và tình huống áp dụng
MCP thường bị nhầm lẫn với Function Calling, RAG và API truyền thống, nhưng tầng vấn đề mà nó giải quyết là khác. Function Calling là chức năng của mô hình cho phép một mô hình cụ thể xuất ra ý định gọi công cụ dưới dạng có cấu trúc, còn MCP là tầng giao thức tiêu chuẩn hóa cách khám phá, kết nối và thực thi công cụ đó. Tức là MCP không thay thế Function Calling mà tiêu chuẩn hóa chuỗi cung ứng công cụ bên trên nó. RAG là kỹ thuật đưa tài liệu được truy xuất vào prompt để bổ sung tri thức, và bổ trợ cho MCP ở chỗ primitive tài nguyên của MCP có thể trở thành đường cung cấp dữ liệu cho RAG. So với REST API truyền thống, nếu REST là giao diện đa dụng cho con người và chương trình thì MCP là giao diện được thiết kế để LLM tự khám phá và sử dụng công cụ, tích hợp sẵn việc khám phá năng lực và ngữ nghĩa (semantics) của ngữ cảnh — đó là khác biệt quyết định.
| Phân loại | MCP | Function Calling | API truyền thống (REST) |
|---|---|---|---|
| Tầng | Giao thức tích hợp (tiêu chuẩn) | Chức năng gọi công cụ của mô hình | Giao diện dịch vụ đa dụng |
| Khám phá | Khám phá động lúc runtime | Lược đồ định nghĩa trước | Tĩnh dựa trên tài liệu |
| Đối tượng | Agent LLM | Một mô hình đơn lẻ | Con người·Chương trình |
| Khả năng tái sử dụng | M+N (cao) | Định nghĩa riêng theo ứng dụng | Tích hợp riêng theo ứng dụng |
Đặc biệt trong so sánh với REST API, cần chỉ ra thêm một điểm. Dù đã có REST API được xây dựng tốt, nếu ném nguyên trạng cho LLM thì mô hình phải mỗi lần diễn giải hàng chục endpoint và ý nghĩa tham số từ prompt, đồng thời xác thực, phân trang và xử lý lỗi mỗi nơi một kiểu nên độ tin cậy giảm. MCP server đóng vai trò “adapter” tái cấu trúc REST API này thành một số ít công cụ có ý nghĩa, dễ hiểu đối với mô hình và tiêu chuẩn hóa quy ước khám phá, xác thực và lỗi. Tức là hiểu chính xác nhất là MCP không thay thế API hiện có mà đặt thêm một tầng thân thiện với LLM lên trên.
Hàm ý thực tiễn mà sự khác biệt này tạo ra là “tái sử dụng server đã xây một lần”. Ví dụ, khi một tổ chức xây dựng một MCP server phơi bày tài liệu quy định nội bộ, nhà phát triển dùng trong trợ lý IDE, người lập kế hoạch dùng trong chatbot desktop, đội vận hành dùng trong agent tự động hóa — cùng một server nguyên vẹn. Các tình huống áp dụng cụ thể tiêu biểu gồm (1) trong phát triển phần mềm, agent IDE kết nối tới các MCP server GitHub, hệ thống tệp, terminal để thực hiện từ tra cứu issue đến sửa mã và chạy kiểm thử, (2) trong tìm kiếm tri thức doanh nghiệp, bọc wiki nội bộ, ticket, DB thành các server riêng để một trợ lý có thể truy vấn chéo nhiều nguồn tri thức, (3) trong tự động hóa nghiệp vụ, kết hợp các server lịch, messenger, CRM để cấu thành quy trình nhiều bước “đặt lịch họp với khách hàng và ghi bản tóm tắt vào CRM”. Cả ba tình huống đều chia sẻ lợi ích là server được tái sử dụng độc lập nên chi phí tích hợp dừng ở mức tuyến tính (M+N).
5. Chuyên sâu: Xu hướng mới nhất, mối đe dọa bảo mật và ứng phó tiêu chuẩn
Kể từ khi được công bố vào cuối năm 2024, đặc tả MCP được sửa đổi nhanh chóng, liên tục bổ sung các yếu tố cần thiết cho vận hành doanh nghiệp như ủy quyền server từ xa (căn chỉnh OAuth 2.1), truyền tải HTTP hỗ trợ streaming, lõi phi trạng thái, UI do server kết xuất (MCP Apps) và mở rộng tác vụ dài hạn (Tasks). Tuy nhiên, vì đặc tả đang tiến hóa sôi động, nên xác nhận đặc tả chính thức trước khi áp dụng các chức năng chi tiết của một phiên bản cụ thể.
Về mặt hệ sinh thái, nhiều server tham chiếu đa dạng như hệ thống tệp, Git, cơ sở dữ liệu, tìm kiếm đã được công bố, và khi registry để đăng ký và tìm kiếm server cùng hỗ trợ client của nhiều IDE, framework agent tăng lên, trải nghiệm sử dụng “gắn công cụ như cài đặt server” đang dần định hình. Điều này có tiềm năng tái hiện trong lĩnh vực tích hợp công cụ hiệu ứng mạng tương tự như việc trình quản lý gói trước đây đã làm bùng nổ việc tái sử dụng thư viện. Tuy nhiên, việc các server chưa được kiểm chứng có thể dễ dàng lưu hành dẫn ngay tới vấn đề bảo mật.
Điểm đáng chú ý là bảo mật. Kết nối công cụ được tiêu chuẩn hóa tạo ra bề mặt tấn công (attack surface) mới tương xứng với sự tiện lợi. Các mối đe dọa chính được giới học thuật và ngành nêu ra như sau.
- Chèn mô tả công cụ (tool poisoning / prompt injection): Tấn công trong đó server cài chỉ thị độc hại vào mô tả công cụ hoặc giá trị trả về để chiếm quyền điều khiển hành vi của mô hình. Vì mô hình tin nguyên vẹn mô tả, một công cụ trông bình thường bên ngoài có thể dẫn dụ rò rỉ dữ liệu bên trong.
- Quyền hạn quá mức và người ủy quyền bị nhầm lẫn (confused deputy): Trong quá trình mô hình kết hợp năng lực của nhiều server, phát sinh leo thang đặc quyền ngoài ý muốn hoặc rò rỉ dữ liệu chéo server. Phương thức tiêu biểu là server có độ tin cậy thấp dẫn dụ để chặn bắt kết quả của server khác.
- Lỗ hổng xác thực và quản lý token của server từ xa: Trong các MCP server từ xa đã triển khai thực tế, đã quan sát được các trường hợp xác thực yếu, lộ token và phạm vi (scope) quá rộng. Khi token bị đánh cắp, toàn bộ backend mà server bọc bị phơi nhiễm rủi ro.
Các biện pháp ứng phó được khuyến nghị gồm phê duyệt của người dùng tại Host (HITL), giới hạn phạm vi công cụ và tài nguyên theo nguyên tắc đặc quyền tối thiểu, danh sách trắng server tin cậy thông qua xác minh chữ ký và nguồn gốc, ghi nhật ký kiểm toán, tối thiểu hóa vòng đời và phạm vi token dựa trên OAuth. Tức là MCP chỉ cung cấp “tiêu chuẩn kết nối”, còn sự an toàn phụ thuộc vào thiết kế kiểm soát theo tinh thần zero trust của Host và người vận hành server.
6. Các điểm cần cân nhắc và hàm ý (góc nhìn Kỹ sư chuyên nghiệp)
- Chiến lược áp dụng tiêu chuẩn: MCP có giá trị triển khai lớn vì là tiêu chuẩn mở giảm phụ thuộc nhà cung cấp, nhưng do đặc tả đang tiến hóa, tổ chức cần xác định chính sách tương thích phiên bản và tương thích ngược, đồng thời có danh mục server tiêu chuẩn nội bộ và gateway để lan tỏa một cách có kiểm soát.
- Đánh đổi giữa bảo mật và quản trị: Năng suất của việc tự động kết nối công cụ xung đột với việc mở rộng bề mặt tấn công. Cần lấy đặc quyền tối thiểu, phê duyệt của người dùng, xác minh độ tin cậy của server, kiểm toán làm mặc định, và thiết kế điểm cân bằng giữa tiện lợi và an toàn phù hợp với khẩu vị rủi ro của tổ chức, chẳng hạn bắt buộc cổng phê duyệt cho công cụ nhạy cảm.
- Kết hợp với công nghệ liên kết: MCP phát huy hiệu quả tối đa khi kết hợp với RAG (cung cấp tài nguyên), framework agent (điều phối công cụ), API gateway (xác thực, giới hạn tốc độ), khả năng quan sát (truy vết lời gọi). Cần định vị nó không phải là công nghệ độc lập mà là tầng kết nối của kiến trúc nền tảng AI.
- Triển vọng và ứng phó: Khi tích hợp công cụ và dữ liệu được tiêu chuẩn hóa, năng lực cạnh tranh sẽ dịch chuyển từ “có kết nối hay không” sang bảo đảm và vận hành được bao nhiêu server chất lượng (tri thức lĩnh vực, kiểm soát). Tổ chức cần tài sản hóa dữ liệu và nghiệp vụ nội bộ thành MCP server, và chủ động chuẩn bị registry cùng hệ thống chứng nhận chất lượng/bảo mật server.
- Góc nhìn áp dụng cho khu vực công và doanh nghiệp tại Hàn Quốc: Trong môi trường tách mạng và bảo vệ thông tin cá nhân, các yêu cầu về chuyển dữ liệu ra nước ngoài, quản lý token và ghi nhật ký của server từ xa có thể xung đột với quy định (Luật Bảo vệ thông tin cá nhân, CSAP v.v.), nên cần xem xét đồng thời việc ưu tiên áp dụng server stdio on-premise và kiểm soát việc đưa dữ liệu ra ngoài.
Tài liệu tham khảo
- Model Context Protocol, Architecture overview — https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture
- Model Context Protocol Blog, "The 2026-07-28 Specification" — https://blog.modelcontextprotocol.io/posts/2026-07-28/
- CodiLime, "Model Context Protocol (MCP) explained" — https://codilime.com/blog/model-context-protocol-explained/
- MCPSecBench: A Systematic Security Benchmark for Model Context Protocols (arXiv:2508.13220) — https://arxiv.org/pdf/2508.13220
Tóm tắt một câu: MCP là giao thức mở “USB-C cho AI” kết nối chuẩn hóa ứng dụng LLM với công cụ, dữ liệu và prompt bên ngoài bằng cấu trúc Host–Client–Server và JSON-RPC 2.0, giảm bài toán tích hợp M×N thành M+N, và sự an toàn của nó phụ thuộc vào thiết kế kiểm soát của Host và server như đặc quyền tối thiểu và phê duyệt của người dùng.