MCP (Model Context Protocol) #25

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: MCP (Model Context Protocol) là giao thức mở chuẩn hóa cách ứng dụng AI trao đổi với nguồn dữ liệu và công cụ bên ngoài. MCP quy định vai trò, loại thông điệp và vòng kết nối; nó không phải model, không tự cấp quyền và không tự biến một server lạ thành nơi đáng tin.

Đọc xong, bạn sẽ hiểu:

• Host, client và server khác nhau ở đâu.
• Tools, resources và prompts dùng cho ba nhu cầu nào.
• Vì sao có chuẩn chung vẫn phải kiểm nguồn, quyền và xác nhận.

1. MCP là gì? Chuẩn kết nối, không phải model mới

Ở bài Function Calling #24, bạn đã thấy model có thể đề xuất một function call nhưng ứng dụng mới là bên kiểm và chạy code. Khi số hệ thống bên ngoài tăng lên, một câu hỏi khác xuất hiện: mỗi ứng dụng AI phải học một kiểu kết nối riêng cho từng nguồn dữ liệu và tool hay sao?

Model Context Protocol, viết tắt là MCP, giải quyết phần “nói chuyện theo chuẩn nào”. Đặc tả MCP hiện hành mô tả một giao thức mở giúp ứng dụng LLM tích hợp với nguồn dữ liệu và tool bằng thông điệp JSON-RPC 2.0. MCP Specification 2025-11-25

Hãy hình dung nhiều thiết bị dùng cùng một chuẩn ổ cắm. Chuẩn chung giúp bạn biết hình dạng đầu nối và dòng điện đi qua ra sao. Nó không bảo đảm mọi thiết bị cắm vào đều tốt, cũng không quyết định thiết bị được phép làm gì trong nhà.

MCP chuẩn hóa giao tiếp; quyết định kết nối server nào, gửi dữ liệu gì và cho phép hành động nào vẫn thuộc ứng dụng.

a. MCP không phải ba thứ dễ nhầm

• MCP không phải model mới; model vẫn là thành phần xử lý ngôn ngữ.
• MCP không phải một server cụ thể; server chỉ là chương trình nói được MCP.
• MCP không phải toàn bộ agent; agent còn cần context, state, guardrails và tiêu chí dừng.

MCP cũng không thay thế API. Server có thể gọi API, đọc file hoặc truy vấn database phía sau lớp giao tiếp chuẩn.

b. Chuẩn chung giảm “dây nối riêng”

MCP chuẩn hóa tên thông điệp, cấu trúc dữ liệu và cách mở/đóng phiên. Ứng dụng vẫn phải tự xác thực người dùng, chuyển dữ liệu sang nghiệp vụ của mình, giới hạn quyền và xử lý lỗi. Chuẩn giảm phần keo lặp lại, không loại bỏ trách nhiệm thiết kế.

2. Ba vai trò và ba primitive cốt lõi

MCP dùng kiến trúc client-server, nhưng có thêm host để giữ ranh giới điều phối. Tài liệu chính thức nêu rằng một host tạo một MCP client riêng cho mỗi MCP server; mỗi client duy trì kết nối chuyên biệt với server tương ứng. MCP Architecture overview

a. Host, client và server

MCP host là ứng dụng AI người dùng tương tác. Host quản lý server, connection, context và chính sách quyền.

MCP client nằm trong host, giữ một kết nối tới đúng một server và trao đổi request, response, notification. Ba server thường có ba client tách biệt.

MCP server là chương trình cung cấp capability. Nó có thể chạy cục bộ hoặc trên internet; “server” là vai trò, không chỉ một máy chủ lớn.

Trong project-docs-demo, app chat là host, client project-docs giữ kết nối và server đọc tài liệu demo. Host chỉ gửi context cần thiết.

b. Primitive là gì?

Primitive là khối giao tiếp chuẩn. Ba primitive cốt lõi phía server là:

• Tools: hàm có input rõ để model đề xuất gọi, như search_docs.
• Resources: dữ liệu context ứng dụng có thể đọc, như docs://handbook.
• Prompts: mẫu tương tác tái sử dụng, như summarize_decision.

Tài liệu MCP mô tả tool thường do model chọn, resource do ứng dụng lấy và prompt do người dùng chọn. Hành động nhạy cảm vẫn cần xác nhận. Understanding MCP servers

Hình 1 — MCP chuẩn hóa đường trao đổi; host vẫn giữ quyền chọn server, context và hành động được phép.

c. Local và remote chỉ khác nơi chạy, không đổi trách nhiệm

Server local thường trao đổi trực tiếp với ứng dụng qua luồng vào/ra của tiến trình; server remote trao đổi qua HTTP trên mạng. Tên transport cụ thể là stdio và Streamable HTTP.

Local vẫn có thể chạy với quyền tài khoản của bạn; remote vẫn có thể dùng authentication tốt. Hãy hỏi server đến từ đâu, có quyền nào và dữ liệu nào được đi qua.

3. Một phiên MCP diễn ra như thế nào?

MCP không bắt đầu bằng việc model gọi ngay một tool. Client và server cần mở phiên, nhận diện khả năng rồi mới dùng primitive phù hợp.

a. Initialize và capability negotiation

Khi kết nối, ứng dụng và máy chủ giới thiệu phiên bản cùng khả năng hỗ trợ. Máy chủ tài liệu có thể cho phép tìm kiếm và đọc; ứng dụng chỉ dùng khả năng đã thống nhất. Bước khai báo và thống nhất này gọi là capability negotiation. Trong demo chỉ đọc, hai bên chỉ dùng các khả năng đã nêu trong Connection Card.

Phiên chỉ dùng capability đã khai báo. MCP đặt version theo ngày YYYY-MM-DD; bản current là 2025-11-25. Hai bên phải thống nhất version tương thích. MCP Versioning

b. Discover trước, read hoặc call sau

Sau khi khởi tạo, client có thể khám phá primitive:

1. tools/list lấy danh sách tool và input schema.
2. resources/list hoặc resources/templates/list lấy nguồn dữ liệu có thể đọc.
3. prompts/list lấy các prompt template có sẵn.

Trong ví dụ project-docs-demo, host thấy một resource docs://handbook, tool search_docs và prompt summarize_decision. Khi người dùng hỏi “Quy trình duyệt thay đổi là gì?”, host có thể đọc resource hoặc đưa tool tìm kiếm cho model. Nếu model đề xuất search_docs, host kiểm argument và quyền rồi client mới gửi tools/call.

Server trả kết quả về client; host lọc và chọn phần đưa vào context. Server không tự chèn toàn bộ dữ liệu vào model.

Hình 2 — Biết version và capability trước, khám phá primitive tiếp theo, chỉ sau đó mới đọc hoặc gọi.

c. Data layer và transport layer

Ví dụ: không kết nối được → kiểm transport; báo version không hỗ trợ → kiểm protocol; tool chạy nhưng trả sai quy trình → kiểm implementation và dữ liệu.

4. MCP không tự làm hệ thống an toàn

Một server nói đúng MCP vẫn có thể đến từ nguồn không đáng tin, mô tả tool sai hoặc trả dữ liệu chứa chỉ dẫn độc hại. Chuẩn giao tiếp và trust là hai bài toán khác nhau.

Đặc tả MCP nhấn mạnh consent, data privacy và tool safety. Tool có thể dẫn tới truy cập dữ liệu hoặc chạy code; mô tả hành vi của tool phải được xem là chưa tin cậy nếu không đến từ server đáng tin. MCP Specification — Security and Trust & Safety

a. Năm rủi ro người mới hay bỏ qua

1. Nguồn server: tên quen không chứng minh publisher thật.
2. Quyền quá rộng: tool đọc lại nhận cả thư mục cá nhân hoặc token ghi.
3. Prompt injection: resource có thể chứa câu giả làm chỉ thị.
4. Tool gây tác động: search_docs và delete_docs cần chính sách khác nhau.
5. Secret: token hoặc dữ liệu riêng có thể lọt vào log/context.

Harness còn phải xử lý timeout, retry trùng, output quá lớn, tool list đổi và version lệch.

b. Checklist trước khi bật một server

• Xác minh publisher và URL/package.
• Chỉ bật primitive cần dùng; tắt phần dư.
• Giới hạn filesystem, database role và token.
• Tách read-only khỏi write/send/delete.
• Preview và xác nhận hành động gây tác động.
• Kiểm schema, business rule và output size.
• Đặt timeout, retry giới hạn và chống chạy trùng.
• Ghi log nhưng che secret; dừng khi capability/auth/output bất thường.

Hình 3 — Connection Card biến câu “kết nối MCP” thành phạm vi quyền có thể kiểm tra.

5. Bài tập 15 phút: lập MCP Connection Card

Dùng giấy hoặc Markdown để thiết kế kết nối read-only project-docs-demo; không cài package, nhập token hoặc nối dữ liệu thật.

a. Mẫu tham khảo đã điền

Đối chiếu link từ website/tài liệu chính thức của nhà cung cấp tới đúng repository hoặc package; kiểm tên owner, package ID và hướng dẫn cài đặt khớp nhau. Nếu không có đường liên kết chính thức, không kết nối.

b. Trace một yêu cầu

Trace yêu cầu: “Tìm quy trình duyệt thay đổi và tóm tắt ba bước.”

1. Host chọn client project-docs.
2. Client đã thống nhất version và capability.
3. Host chỉ cho resources/read hoặc search_docs trong scope demo.
4. Result được kiểm kích thước; model chỉ tóm tắt phần có bằng chứng.

Đổi yêu cầu thành “sửa luôn tài liệu”. Card cấm write, nên phải dừng và báo cần capability, quyền và xác nhận khác.

c. Tiêu chí đạt

Bạn đạt khi nói rõ ai giữ quyền, client nối server nào, primitive/dữ liệu nào được dùng và điều kiện buộc dừng.

6. Tổng kết: chuẩn chung, quyền vẫn do host giữ

a. Năm ý chính

• MCP là giao thức kết nối, không phải model, server cụ thể hay toàn bộ agent.
• Host điều phối; mỗi client giữ kết nối riêng tới một server.
• Server có thể cung cấp tools, resources và prompts qua primitive chuẩn.
• Phiên MCP cần initialize, capability negotiation và discovery trước khi read/call.
• Chuẩn chung không thay thế xác minh nguồn, least privilege, consent, validation và audit.

b. Câu hỏi tự kiểm tra

• MCP server có được thấy toàn bộ hội thoại không?
• Resource khác tool ở đâu?
• Server dùng đúng MCP có đồng nghĩa đáng tin không?
• Khi nào nên dừng thay vì retry?

c. Gợi ý đáp án

Xem gợi ý câu 1

Không mặc định. Host giữ context và chỉ gửi phần cần thiết; mỗi connection giữ ranh giới riêng. → xem mục 2.

Xem gợi ý câu 2

Resource cung cấp dữ liệu để ứng dụng đọc; tool là function model có thể đề xuất gọi. → xem mục 2.

Xem gợi ý câu 3

Không. Tuân thủ protocol chỉ nói cách giao tiếp; nguồn, quyền và hành vi vẫn phải được kiểm. → xem mục 4.

Xem gợi ý câu 4

Dừng khi version lệch, auth lỗi lặp lại, capability đổi, output bất thường hoặc hành động vượt scope. → xem mục 4.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• MCP Specification 2025-11-25
• MCP Architecture overview
• Understanding MCP servers
• MCP Versioning

Xem lại Function Calling #24 nếu còn nhầm model với executor. Học tiếp Prompt Routing #26 để hiểu cách phân loại request trước khi chọn prompt, model, tool set hoặc workflow.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Chỉ kết nối server đã xác minh và cấp quyền tối thiểu.