Tweet
MCP là gì và tại sao cần MCP.
MCP LÀ GÌ VÀ TẠI SAO CẦN MCP
1 Khái niệm (Concept)
Model Context Protocol (MCP) là một giao thức mở cho phép ứng dụng AI/agent kết nối có kiểm soát tới dữ liệu và công cụ trong thế giới “thực” (file, DB, API, hệ thống mạng…), thông qua một thành phần trung gian gọi là MCP server.
- MCP server = “cầu nối” giữa AI và hạ tầng: nó công bố những gì AI được phép đọc hoặc làm (dưới dạng resources và tools), cùng các prompts (mẫu hội thoại có tham số) để tái sử dụng.
- AI client/host = ứng dụng AI (chat app, IDE, agent runtime…) “nói chuyện” với MCP server theo chuẩn chung (JSON-RPC), không phụ thuộc bạn dùng LLM nào ở phía trên hay công nghệ gì ở phía dưới.
2.1 Các vấn đề tồn tại trước MCP
2.1 Thiếu ngữ cảnh “sống” (missing live/real-time context)
LLM giỏi suy luận nhưng thường chỉ dựa trên kiến thức tĩnh. Khi cần dữ liệu cập nhật đúng thời điểm—như file nội bộ, bản ghi DB, log sự cố, cấu hình thiết bị hay API riêng—không có “cầu” chuẩn và an toàn để truy xuất. Hậu quả là câu trả lời dễ lỗi thời, thiếu căn cứ, tăng rủi ro hallucination và quyết định vận hành kém tin cậy.
2.2 Tích hợp phân mảnh, dễ lock-in (fragmented integrations; vendor lock-in)
Mỗi app/LLM lại có cơ chế plugin/extension riêng: cách định nghĩa tham số, xác thực, streaming… khác nhau. Đội ngũ phải viết đi viết lại cùng một năng lực (ví dụ: “mở PR”, “đọc log”, “truy vấn DB”) cho từng nền tảng, gây trùng lặp, khó bảo trì, chi phí di trú cao và phụ thuộc nhà cung cấp. Kết quả là hệ thống bị tight coupling, khó chuyển đổi hoặc mở rộng.
2.3 An toàn & kiểm soát kém (weak security & governance)
Các lời gọi API/SSH rời rạc thiếu quyền hạ tầng tinh chỉnh (fine-grained authorization), consent của người dùng, audit log, rate-limit, timeout/retry, idempotency và quản lý secrets đúng chuẩn. Khi LLM thao tác công cụ mà không có guardrails, rủi ro prompt-injection, data exfiltration, hoặc thao tác nhầm lẫn trên hệ thống thật sẽ tăng mạnh, khiến governance và tuân thủ trở nên khó đảm bảo.
2.4 Khó tái sử dụng & mở rộng (poor reusability & extensibility)
Không có ngôn ngữ chung ở tầng giao thức/hợp đồng (contract) nên tích hợp thường không mang tính di động (low portability). Thay IDE/LLM hay thay đổi kiến trúc là phải tích hợp lại từ đầu; các “hợp đồng” dễ trôi dạt (contract drift), phiên bản hóa không nhất quán, làm chậm tiến độ mở rộng chức năng và nhân rộng sang đội/nhánh hệ thống khác.
3. MCP giải quyết như thế nào? (Address with MCP)
3.1 Chuẩn hoá giao tiếp
MCP đặt ra một “ngôn ngữ chung” giữa ứng dụng AI (client/host) và MCP server bằng JSON-RPC 2.0, vì thế mọi lời gọi đều theo cùng một khuôn dạng có phương thức, tham số, mã định danh và kết quả. Khi chạy cục bộ, hai tiến trình có thể trao đổi qua stdio để đơn giản hoá phát triển và thử nghiệm; khi triển khai như dịch vụ, kết nối thường đi qua HTTP với cơ chế streaming (SSE hoặc biến thể) để trả dữ liệu theo dòng. Nhờ lớp hợp đồng này, client chỉ cần biết MCP là có thể khám phá năng lực của server và gọi chúng mà không phụ thuộc backend cụ thể.
3.2 Ba năng lực có khai báo
Trên lớp giao thức thống nhất đó, MCP bọc hạ tầng thành ba dạng năng lực được mô tả rõ ràng bằng schema. “Tools” đại diện cho các hành động có kiểm soát như gọi API, mở pull request, chạy job hay thay đổi cấu hình; “Resources” đại diện cho dữ liệu chỉ-đọc như file, truy vấn cơ sở dữ liệu, log hay cấu hình đang chạy; “Prompts” là các mẫu hội thoại có tham số để tái sử dụng các luồng lặp lại. Vì đều có kiểu và ràng buộc tham số, mô hình biết chính xác cần truyền gì và sẽ nhận lại cấu trúc dữ liệu nào. Chẳng hạn, thay vì để mô hình suy diễn câu lệnh tuỳ ý, client chỉ việc gọi get_uplink_util(host, iface) và nhận về một JSON gọn có phần trăm sử dụng cùng dấu thời gian.
3.3 Kiểm soát và an toàn từ thiết kế
MCP tích hợp cơ chế kiểm soát ngay trong thiết kế để giảm rủi ro khi chạm hệ thống thật. Mỗi năng lực gắn với phạm vi quyền theo nguyên tắc “ít quyền nhất”, các thao tác nhạy cảm có thể yêu cầu đồng ý tức thời hoặc đi qua lớp chính sách trước khi thực thi. Ở tầng vận hành, server ghi nhật ký và dấu vết, áp thời hạn chờ, thử lại có backoff, giới hạn tần suất, dùng khoá idempotency để tránh thao tác ghi lặp, và quản lý bí mật ở phía server thay vì nhúng vào prompt. Các “lan can” như kiểm tra kích thước và kiểu tham số, làm mờ thông tin nhạy cảm, hay chặn prompt-injection và rò rỉ dữ liệu đảm bảo mô hình chỉ tương tác qua các Tools/Resources đã công bố, không còn “đường tắt” nguy hiểm.
3.4 Giảm lock-in, tăng tái sử dụng
Bằng cách tách rời client và server trên một giao thức chung, MCP cho phép viết một server duy nhất phục vụ nhiều ứng dụng AI hoặc mô hình khác nhau, đồng thời một client có thể kết nối nhiều server mà không phải thay đổi cách gọi. Hợp đồng ổn định (schema, lỗi, cơ chế streaming) giúp khi đổi mô hình, IDE hay mở rộng backend, lớp tích hợp hạ tầng hầu như không cần viết lại. Kết quả là bốn nút thắt ở mục 1.2 được tháo gỡ đồng thời: ngữ cảnh được kéo đúng lúc, tích hợp bớt phân mảnh, an toàn được chuẩn hoá, và năng lực có thể mang đi dùng lại giữa các môi trường.
4. Ví dụ minh họa
Ví dụ 1 — Đo % sử dụng uplink
Dùng Tool get_uplink_util(host, iface) để hỏi nhanh mức sử dụng cổng trên Router-A; MCP server đọc counters qua SNMP/RESTCONF và trả về JSON gọn (phần trăm sử dụng kèm timestamp) để giám sát tải.
Ví dụ 2 — Đọc NAT log gần nhất
Dùng Resource router://{host}/nat-log?lines=10 để lấy 10 dòng NAT log mới nhất; MCP server truy xuất file/syslog/API và trả lại nội dung đã lọc thông tin nhạy cảm phục vụ điều tra sự cố.