MCP Là Gì?

Level: L7 — MCP, API & Connectors (Bài 1/11 theo thứ tự sản xuất — · Đối tượng: Người đã học bài 65-67 (cơ chế API/Webhook/Tool Calling),

1. Mục tiêu học tập

Sau bài này, bạn có thể:

Giải thích MCP là gì và vấn đề cụ thể nó giải quyết — không nhầm với “1 API bất kỳ” hay “1 tính năng riêng của Claude.”
Liệt kê 6 “primitive” (đơn vị năng lực) MCP định nghĩa, chia 2 chiều.
Áp dụng 4 nguyên tắc an toàn cấp giao thức khi đánh giá 1 MCP server mới.
Biết vì sao không nên trích 1 con số “bao nhiêu MCP server đang có” mà không ghi ngày kiểm chứng.

2. Khái niệm cốt lõi

Bước 1 — Concept (vấn đề cần giải quyết, trước khi nói tới MCP): mỗi mô hình AI dù mạnh tới đâu vẫn bị cô lập khỏi dữ liệu thật, vì mỗi nguồn dữ liệu (Google Drive, Slack, 1 database nội bộ…) đòi hỏi 1 cách tích hợp riêng — hệ thống legacy càng làm việc này phức tạp hơn [S27]. Đây là bài toán N×M: N ứng dụng AI × M nguồn dữ liệu, mỗi cặp cần 1 cách tích hợp riêng nếu không có chuẩn chung.

Bước 2 — Open standard (MCP là gì, ở mức khái niệm, không gắn 1 vendor): Model Context Protocol (MCP) là 1 giao thức mở, chuẩn hóa cách các ứng dụng LLM tích hợp với nguồn dữ liệu và công cụ bên ngoài [S26]. Về mặt kỹ thuật, MCP dùng định dạng thông điệp JSON-RPC 2.0 và duy trì kết nối có trạng thái (stateful) giữa các bên tham gia [S26]. MCP thay thế cách làm tích hợp rời rạc, tùy biến theo từng cặp ứng dụng– nguồn dữ liệu, bằng 1 chuẩn mở duy nhất [S27] — biến bài toán N×M thành bài toán N+M (mỗi bên chỉ cần tuân theo chuẩn 1 lần).

Quan trọng — MCP không thuộc về 1 công ty: dù do Anthropic khởi xướng, MCP là chuẩn mở, không thuộc về 1 sản phẩm hay công ty duy nhất [S26]. Đây là lý do danh sách “MCP server nào đang có” luôn thay đổi — hệ quả tự nhiên của việc bất kỳ ai cũng có thể xây server theo chuẩn này (xem mục 16).

3. Tại sao nội dung này quan trọng

Toàn bộ phần còn lại của Level 7 (69-75: ứng dụng MCP, kết nối thật, xác thực, bảo mật) đứng trên nền của khái niệm này. Nếu không hiểu đúng MCP là 1 giao thức (protocol), bạn dễ nhầm nó với “1 API bất kỳ” hoặc “1 tính năng của Claude” — trong khi thực chất đây là chuẩn mở, giải quyết đúng bài toán N×M đã nêu ở mục 2.

4. Cơ chế hoạt động

Bước 3 — Architecture (kiến trúc MCP định nghĩa, vẫn ở mức khái niệm phổ quát): MCP định nghĩa 3 vai trò tham gia giao tiếp [S26]:

Host — ứng dụng LLM khởi tạo kết nối.
Client — thành phần connector nằm bên trong host, quản lý kết nối tới 1 server cụ thể.
Server — dịch vụ cung cấp context và năng lực cho client.

Giao tiếp giữa các vai trò xoay quanh 6 primitive, chia 2 chiều [S26]:

Server cấp cho Client:

Resources — dữ liệu/context (ví dụ: nội dung 1 tài liệu).
Prompts — mẫu tin nhắn/workflow dựng sẵn.
Tools — hàm mà model có thể thực thi (cơ chế thực thi đã học chi tiết ở bài 67 — MCP không phát minh lại cơ chế đó, chỉ chuẩn hóa cách khai báo nó).

Client cấp cho Server:

Sampling — cho phép server khởi xướng 1 hành vi “agentic” (yêu cầu client gọi lại LLM).
Roots — ranh giới URI/filesystem mà server được phép thao tác.
Elicitation — cho phép server hỏi thêm thông tin từ người dùng.

Bước 4 — Real implementation (1 phiên MCP thật vận hành ra sao, vẫn vendor-neutral):

Capability negotiation — host/client và server thống nhất năng lực nào dùng trong phiên này.
Thiết lập kết nối stateful — khác 1 API call đơn lẻ rồi đóng (bài 65), MCP giữ trạng thái xuyên suốt phiên làm việc.
Server expose primitive của nó — công bố Resources/Prompts/Tools.
Client dùng primitive khi cần — gọi Tools để thực thi (dùng đúng cơ chế tool calling đã học bài 67), đọc Resources, và (nếu được phép) dùng Sampling/Roots/Elicitation.

5. Mental model

Tiếp nối ẩn dụ “nhà hàng” (bài 55) và “mạng lưới nhà cung cấp” (mở đầu Level 7): nếu bài 65 dạy “tờ đơn đặt hàng chuẩn” tới 1 nhà cung cấp cụ thể, MCP là mẫu đơn đặt hàng chung mà MỌI nhà cung cấp tham gia mạng lưới đều hiểu — bạn không cần học N kiểu đặt hàng khác nhau cho N nhà cung cấp, chỉ cần học đúng 1 mẫu.

Chính đặc tả MCP cũng đưa ra 1 phép so sánh hữu ích: MCP “lấy cảm hứng từ Language Server Protocol (LSP)” — giao thức đã chuẩn hóa cách các IDE hỗ trợ nhiều ngôn ngữ lập trình khác nhau mà không cần mỗi IDE tự viết lại tích hợp cho từng ngôn ngữ [S26]. MCP làm cho thế giới AI application điều mà LSP đã làm cho thế giới IDE.

6. Hướng dẫn từng bước

Checklist “đọc hiểu 1 MCP server mới” (tổng hợp của người viết, không trích nguyên văn):

Server này expose Resources gì? (dữ liệu/context nào đọc được)
Server này expose Tools gì? (hành động nào agent có thể thực thi)
Server này có expose Prompts dựng sẵn không?
Server này có yêu cầu Sampling không? (có thể tự khởi xướng gọi LLM)
Roots giới hạn phạm vi nào? (được phép chạm tới những gì)
Mô tả tool đến từ nguồn đáng tin cậy, hay đang tin mù quáng annotation do chính server tự khai báo? (xem mục 14)

7. Ví dụ thực tế

Bước 5 — Vendor example (ví dụ gắn sản phẩm cụ thể, đặt sau khi khái niệm đã vững, đúng thứ tự đã khóa):

(Ví dụ dưới đây phản ánh bối cảnh khi MCP công bố, tháng 11/2024 — dùng để hiểu động lực ra đời, KHÔNG mô tả hệ sinh thái hiện tại, vốn lớn hơn nhiều — xem mục 16.) Khi công bố, Anthropic dẫn chứng: Block và Apollo tích hợp MCP; các công cụ như Zed, Replit, Codeium, Sourcegraph dùng MCP để agent coding lấy context từ codebase. Đi kèm là pre-built server mẫu cho Google Drive, Slack, GitHub, Postgres, Puppeteer [S27]. Claude Desktop và Claude Code (đã dùng ở bài 57, L6) là ví dụ 1 host cụ thể hỗ trợ MCP — không phải MCP chỉ tồn tại trong hệ sinh thái Claude.

8. Prompt/template/workflow

Checklist ở mục 6 chính là công cụ tái sử dụng chính của bài này — dùng lại mỗi khi gặp 1 MCP server mới, xuyên suốt các bài 69-73.

9. Visual hoặc diagram cần thiết

Hình 7.4 — Kiến trúc MCP: Host-Client-Server và 6 primitive trao đổi 2 chiều.

10. Bài tập thực hành

Chọn 1 MCP server bất kỳ bạn có thể tiếp cận (ví dụ: 1 server có sẵn trong Claude Code, hoặc 1 connector trong danh mục Claude Connectors).
Xác định: server đó expose Resources, Tools, và/hoặc Prompts gì?
Nó có dùng Sampling/Roots/Elicitation không?
Dựa trên mục 14, bạn có nên cấp quyền ghi (write) ngay từ đầu không, hay nên bắt đầu ở chế độ chỉ đọc?

11. Checklist

Giải thích được MCP là gì mà không nhầm nó với "1 API" hay "1 tính năng riêng của Claude."
Liệt kê được 3 vai trò (host/client/server) và 6 primitive.
Hiểu vì sao MCP được ví như "LSP của thế giới AI."
Biết 4 nguyên tắc an toàn cấp giao thức, áp dụng được khi gặp 1 MCP server mới.
Biết vì sao không nên trích 1 con số ecosystem cụ thể mà không ghi ngày kiểm chứng.

12. Lỗi thường gặp

(Suy luận từ nguyên tắc [S26, S27], không phải danh sách lỗi đã quan sát độc lập.)

Nhầm MCP với “1 API bất kỳ”. MCP là giao thức chuẩn hóa, không phải 1 API cụ thể — khác biệt này quyết định vì sao MCP mở rộng được qua nhiều nhà cung cấp thay vì khóa vào 1 vendor.
Tin tưởng mặc định mô tả (annotation) của 1 tool lạ. Đặc tả MCP nói rõ: annotation mô tả hành vi tool nên bị coi là không đáng tin trừ khi đến từ server đã được xác minh [S26].
Dùng số liệu ecosystem của năm 2024 (early adopter, danh sách pre-built server ở mục 7) như hiện trạng ngày nay.

13. Giới hạn & khi nào KHÔNG nên áp dụng

MCP không phải giải pháp cho mọi tích hợp. Nếu 1 tích hợp không cần AI/agent tham gia quyết định (ví dụ: đồng bộ dữ liệu định kỳ giữa 2 hệ thống nội bộ theo lịch cố định), 1 API tích hợp truyền thống (bài 65) vẫn là lựa chọn hợp lý — không cần “MCP hóa” mọi kết nối.
Bản thân giao thức không tự động đảm bảo an toàn. Đặc tả nói rõ: “MCP itself cannot enforce these security principles at the protocol level” — tuân thủ 4 nguyên tắc ở mục 14 phụ thuộc hoàn toàn vào cách implementor triển khai [S26].
Bài này không đào sâu vai trò Host/Client/Server qua ví dụ thật đa dạng — đó là bài 69.

14. An toàn & quản trị (Safety/Governance)

Đặc tả MCP quy định 4 nguyên tắc an toàn ở tầng giao thức [S26]:

User consent & control — người dùng phải đồng ý rõ ràng với mọi truy cập dữ liệu/hành động, giữ quyền kiểm soát những gì được chia sẻ.
Data privacy — host phải xin phép trước khi để lộ dữ liệu người dùng cho server; không chuyển dữ liệu đi nơi khác nếu chưa đồng ý.
Tool safety — tool đại diện cho khả năng thực thi mã tùy ý, phải coi là có rủi ro; annotation không nên tin tưởng mặc định.
LLM sampling controls — người dùng kiểm soát việc có cho phép sampling hay không, nội dung prompt thực sự gửi, server thấy gì.

Đây là an toàn tầng giao thức (protocol-level) — khác an toàn tầng agent (guardrail, permission — học ở Level 8) và khác quản trị dữ liệu tầng tích hợp cụ thể (học ở bài 75) — 3 tầng riêng biệt, không tầng nào thay thế tầng kia (xem tổng hợp đầy đủ ở bài 75).

15. Best practices

Luôn xác định rõ 1 MCP server expose primitive nào trước khi kết nối.
Không tin tưởng mặc định annotation của tool lạ — xác minh nguồn trước.
Bắt đầu ở chế độ chỉ đọc (Resources) trước khi cấp quyền cho Tools có khả năng ghi/hành động.
Khi mô tả hệ sinh thái MCP, ưu tiên mô tả cơ chế (ổn định theo thời gian) hơn con số cụ thể (thay đổi liên tục).

16. Nội dung nâng cao — Case study: viết về nội dung dễ lỗi thời (không bắt buộc)

Đây là ví dụ thực tế trong chính dự án này về xử lý 1 claim dễ lỗi thời. 1 nguồn Tier 3 từng nêu: “Claude có hơn 200 connector sẵn có” [S16]. Đối chiếu 2 nguồn Tier 1 chính thức: Chính sách Connectors Directory [S28] xác nhận cơ chế (connector xây qua remote MCP server, có chính sách duyệt riêng) nhưng không công bố con số tổng cụ thể; trang danh mục [S29] cho thấy phân trang ước tính hàng trăm connector — cao hơn 200, nhưng cũng không có 1 con số chính thức duy nhất.

Nguyên tắc rút ra: khi viết về 1 hệ sinh thái mở dựa trên giao thức, ưu tiên mô tả cơ chế thay vì số liệu ecosystem tại 1 thời điểm — số liệu gần như chắc chắn đã đổi vào lúc bạn đọc. Nếu buộc phải nêu 1 con số, luôn gắn ngày kiểm chứng và nguồn.

17. Nguồn tham khảo

[S26] Model Context Protocol — Specification (2025-11-25) — modelcontextprotocol.io/specification/2025-11-25 — kiến trúc, 6 primitive, 4 nguyên tắc an toàn. Freshness re-verify 2026-07-13: không đổi.
[S27] Introducing the Model Context Protocol — anthropic.com/news — bối cảnh/động lực ra đời, ví dụ early adopter (2024).
[S16] Kết Nối Claude Với Ứng Dụng Của Bạn (Tier 3, chỉ dùng làm ví dụ minh họa vấn đề lỗi thời ở mục 16, không phải căn cứ cho claim nào).
[S28] Anthropic Connectors Directory FAQ · [S29] Claude Connectors — dùng cho case study mục 16.
Dẫn chiếu (không trích dẫn mới): bài 65 (API), bài 67 (cơ chế tool calling).

18. Ngày kiểm chứng

Kiến trúc/giao thức (mục 2, 4, 5, 6, 14) kiểm chứng qua S26 ngày 2026-07-13 — ổn định vì gắn với phiên bản spec 2025-11-25, re-verify nếu MCP công bố phiên bản mới. Nội dung mục 7 (ví dụ 2024) và mục 16 gắn ngày cụ thể có chủ đích — không cần “cập nhật,” vì bài học chính là những con số này sẽ luôn lỗi thời.