Đã đăng vào khoảng 16 giờ trước 11 phút đọc

MCP là gì? Hiểu đơn giản: Làm sao để AI biết dùng phần mềm thay vì chỉ ngồi chém gió?

Anh em có bao giờ nghĩ thế này chưa?

Mình đang có một ứng dụng quản lý công việc. Ứng dụng đã có API để lấy danh sách task, tạo task, sửa task. Bây giờ muốn nhờ AI làm những việc đó thì sao?

Chẳng lẽ lại phải xây dựng một con AI riêng, dạy nó cách gọi từng API, rồi mỗi lần đổi công cụ lại làm lại từ đầu?

Đây chính là lúc MCP xuất hiện.

1. Đầu tiên, hãy quên mấy thuật ngữ đi đã

Tưởng tượng anh em đang làm việc trong công ty.

Công ty có ba hệ thống:

Jira để quản lý task.
GitLab để quản lý source code.
Google Drive để lưu tài liệu.

Bình thường, muốn làm việc gì thì phải tự mở từng ứng dụng. Muốn tìm task thì vào Jira, muốn xem code thì vào GitLab, muốn đọc tài liệu thì mở Drive.

Giờ anh em có một trợ lý AI. Anh em chỉ cần nói:

"Tìm task đang bị lỗi trên Jira, kiểm tra xem GitLab có commit nào sửa lỗi đó chưa, rồi tìm tài liệu liên quan trên Drive."

Nghe rất hợp lý. Nhưng có một vấn đề: AI không tự nhiên biết cách sử dụng những hệ thống này.

Nó có thể biết Jira là gì, GitLab là gì, nhưng biết về một phần mềm không có nghĩa là có quyền truy cập vào phần mềm đó, càng không có nghĩa là biết gọi API của nó.

Muốn AI thực sự làm được việc, chúng ta cần cung cấp cho nó những công cụ phù hợp.

MCP sinh ra để giúp chuẩn hóa cách cung cấp và sử dụng những công cụ ấy.

2. MCP giống như một chuẩn cắm chung cho AI

Hãy tưởng tượng mỗi phần mềm có một cách giao tiếp riêng.

Jira có API của Jira. GitLab có API của GitLab. Google Drive cũng có API riêng.

Nếu mỗi AI phải tự học cách kết nối với từng phần mềm, công việc tích hợp sẽ khá mệt. Khi số lượng công cụ tăng lên, việc quản lý các kết nối cũng trở nên phức tạp.

MCP đưa ra một cách giao tiếp chung để ứng dụng AI có thể kết nối với những hệ thống hỗ trợ MCP.

Có thể hình dung như sau:

MCP Server: Cung cấp các công cụ để AI sử dụng.
MCP Client: Đảm nhiệm việc giao tiếp với MCP Server.
AI Agent: Suy nghĩ, lựa chọn công cụ và quyết định bước tiếp theo.

Nói vui một chút: AI là người nghĩ việc, MCP Client là người cầm điện thoại gọi, còn MCP Server là đầu mối cung cấp dịch vụ.

Ví dụ, MCP Server của Jira có thể cung cấp các công cụ:

Tìm kiếm task.
Xem chi tiết task.
Tạo task.
Cập nhật trạng thái task.

AI không cần tự đoán cách gọi tất cả API nội bộ của Jira. Nó có thể khám phá những công cụ được server cung cấp và sử dụng chúng thông qua MCP.

Tất nhiên, server phải được triển khai và cấu hình phù hợp. Không phải cứ cài một ứng dụng là AI tự nhiên điều khiển được nó.

3. Vậy MCP Server do ai viết?

Đây mới là phần developer cần quan tâm.

Giả sử anh em đang phát triển một ứng dụng quản lý công việc bằng Nuxt và Java Spring Boot.

Backend đã có API:

GET   /api/tasks
POST  /api/tasks
PATCH /api/tasks/{id}

Frontend đang dùng những API này bình thường.

Bây giờ muốn AI cũng sử dụng được các chức năng đó. Anh em có thể viết một MCP Server cung cấp những công cụ tương ứng:

search_tasks
create_task
update_task

Khi AI muốn tìm task, MCP Server gọi API lấy danh sách task. Khi AI muốn tạo task, server gọi API tạo task.

Luồng hoạt động:

Người dùng
    |
    | "Tạo task sửa lỗi đăng nhập"
    v
AI Agent
    |
    | Chọn tool create_task
    v
MCP Client
    |
    | Gửi yêu cầu qua MCP
    v
MCP Server
    |
    | Gọi API hiện có
    v
Backend
    |
    | Tạo task và trả kết quả
    v
AI nhận kết quả

Điểm hay là anh em không nhất thiết phải viết lại backend.

API hiện tại vẫn phục vụ frontend như cũ. MCP Server chỉ bổ sung một cách để ứng dụng AI sử dụng những chức năng mà anh em cho phép.

Nếu có quyền truy cập trực tiếp vào service bên trong backend, MCP Server cũng có thể gọi service đó mà không cần đi vòng qua HTTP API.

Và nhớ nhé: không phải cứ có API là phải viết MCP Server. Chỉ cần làm khi có nhu cầu tích hợp với ứng dụng AI tương thích MCP.

4. Nếu đã có API rồi, tại sao không cho AI gọi API luôn?

Câu hỏi rất hợp lý.

Thực tế, hoàn toàn có thể tích hợp AI với API trực tiếp. MCP không phải điều kiện bắt buộc để xây dựng AI Agent.

Vấn đề xuất hiện khi anh em có nhiều công cụ và muốn tái sử dụng chúng trong nhiều ứng dụng AI khác nhau.

Ví dụ, anh em xây dựng một MCP Server cho GitLab, cung cấp công cụ tìm merge request và đọc thông tin commit.

Sau đó, một ứng dụng AI khác có hỗ trợ MCP cũng có thể sử dụng server này nếu đáp ứng các yêu cầu kết nối và quyền truy cập.

Anh em không nhất thiết phải viết lại toàn bộ cơ chế tích hợp riêng cho từng ứng dụng AI.

Tuy nhiên, MCP không giúp API chạy nhanh hơn, không tự cấp quyền truy cập và cũng không tự đảm bảo AI chọn đúng công cụ. Anh em vẫn phải xây dựng và kiểm thử những phần đó.

Nói ngắn gọn: API giúp phần mềm giao tiếp; MCP chuẩn hóa cách ứng dụng AI khám phá và sử dụng các khả năng được cung cấp.

5. Thế MCP Client có phải chính là AI Agent không?

Không hẳn. Hai thứ này có nhiệm vụ khác nhau.

Giả sử anh em dùng OpenCode và yêu cầu:

"Tìm các task quá hạn, sau đó cập nhật trạng thái những task tôi chọn."

AI Agent sẽ phân tích yêu cầu và quyết định cần gọi công cụ nào.

MCP Client đảm nhiệm việc gửi yêu cầu gọi tool đến MCP Server và nhận kết quả trả về.

MCP Server thực hiện thao tác tương ứng thông qua backend.

Có thể hình dung:

Thành phần	Nói kiểu dễ hiểu
AI Agent	Người quyết định cần làm gì
MCP Client	Người giao tiếp với dịch vụ
MCP Server	Nơi cung cấp công cụ
Backend	Nơi thực sự xử lý nghiệp vụ

Trong thực tế, MCP Client thường nằm bên trong ứng dụng đóng vai trò MCP Host. Những thành phần này phối hợp với nhau, chứ không nhất thiết là bốn chương trình riêng biệt.

Và có một điều cần nhớ: AI Agent có thể sử dụng nhiều MCP Server cùng lúc. Ví dụ, một server cho GitLab, một server cho Jira và một server cho hệ thống tài liệu nội bộ.

Đó là lý do MCP có thể hữu ích khi anh em muốn AI phối hợp nhiều công cụ để hoàn thành một công việc.

6. Nhưng có MCP rồi, AI muốn làm gì cũng được à?

Không nhé. Đây là chỗ rất dễ hiểu nhầm.

Giả sử MCP Server cung cấp tool delete_task. Điều đó chỉ có nghĩa là có một công cụ xóa task được công bố. Nó không có nghĩa AI được quyền xóa mọi task trong hệ thống.

Server và backend vẫn phải kiểm tra quyền, dữ liệu đầu vào và các quy tắc nghiệp vụ. Với thao tác quan trọng, hệ thống có thể yêu cầu người dùng xác nhận trước khi thực hiện.

Nếu không làm tốt phần này, anh em có thể tạo ra một hệ thống mà AI gọi đúng công cụ nhưng lại tác động sai dữ liệu.

MCP giúp kết nối công cụ. Nó không thay thế bảo mật hay trách nhiệm thiết kế hệ thống.

7. Nếu là developer, nên bắt đầu thế nào?

Đừng vội xây một MCP Server với hàng chục công cụ.

Hãy chọn một chức năng đơn giản trong ứng dụng hiện có, chẳng hạn tìm kiếm task.

Xác định API hoặc service đang xử lý chức năng đó.
Xây dựng MCP Server công bố tool search_tasks.
Kết nối server với một ứng dụng AI hỗ trợ MCP.
Yêu cầu AI tìm task theo trạng thái hoặc từ khóa.
Kiểm tra xem AI có chọn đúng tool, truyền đúng tham số và xử lý lỗi hợp lý không.

Khi luồng đọc dữ liệu hoạt động ổn định, anh em có thể thử các thao tác ghi dữ liệu với cơ chế phân quyền và xác nhận phù hợp.

Cách này giúp kiểm chứng giá trị thực tế trước khi đầu tư quá nhiều thời gian vào kiến trúc.

Lời kết

Nếu chỉ nhớ một điều về MCP, hãy nhớ thế này:

MCP không biến AI thành một lập trình viên biết mọi phần mềm. MCP cung cấp một cách giao tiếp chuẩn để AI có thể sử dụng những công cụ mà hệ thống cho phép.

Là developer, anh em có thể tận dụng API và service hiện có để xây dựng MCP Server, thay vì phải viết lại toàn bộ ứng dụng.

Còn AI Agent sẽ sử dụng những công cụ đó để thực hiện công việc theo yêu cầu.

Và cuối cùng, đừng thêm MCP chỉ vì thấy nó đang được nhắc đến nhiều. Hãy thêm nó khi anh em thực sự muốn các ứng dụng AI có thể sử dụng lại những khả năng của hệ thống một cách thống nhất, có kiểm soát và dễ bảo trì hơn.

Làm rõ MCP Host trong sơ đồThêm bảng MCP có và không có

AI Agent