Ứng dụng MCP trong công việc - Phần 3 - Tự xây dựng MCP Server và thiết kế tool an toàn

Ở Phần 1 và Phần 2, chúng ta đã đi qua bài toán thực tế và giải mã kiến trúc MCP. Phần cuối của series sẽ đi vào thực hành:

• Quy trình 4 bước tạo Custom MCP Server
• Cạm bẫy khi prompt bằng tiếng Việt
• Ba ví dụ thiết kế tool an toàn
• MCP định hình lại cách team làm việc như thế nào

Quy trình 4 bước tạo Custom MCP Server

Bước 1 – Tạo App & lấy quyền (credentials.json) Tạo dự án trên Google Cloud Console Bật Google Docs API Tạo và tải về file cấu hình xác thực (OAuth Client ID)

Bước 2 – Dùng AI sinh mã nguồn (AI tự code toàn bộ SDK) Prompt cho Claude/Cursor: “Viết cho tôi một MCP Server bằng Python/Node.js để đọc highlight từ file Google Docs này và chèn sang file kia”

Bước 3 – Kiểm tra mô tả Tool (description rõ ràng) Đảm bảo tên hàm và phần mô tả (Tool Description) rõ ràng để mô hình AI biết chính xác khi nào nên kích hoạt hàm nào.

Bước 4 – Đăng ký vào config (claude_desktop_config.json) Khai báo đường dẫn file code vào cài đặt Claude Desktop hoặc Cursor; khởi động lại ứng dụng là tính năng sẵn sàng.

Thời gian thực hiện: Nhờ có AI hỗ trợ sinh code, toàn bộ quy trình chỉ mất khoảng 15–20 phút để hoàn thiện. Đây chính là kỷ nguyên Vibe Coding.

Cạm bẫy từ đa nghĩa: “BỎ”

Một sai lầm thường gặp khi prompt bằng tiếng Việt. Ví dụ prompt thực tế: “Bỏ đoạn dịch này vào tài liệu giúp mình” Rủi ro AI hiểu nhầm: Trong tiếng Việt, “Bỏ” vừa có nghĩa là Thêm vào (put into), vừa có nghĩa là Loại bỏ (delete). AI có thể gọi nhầm hàm xóa nội dung hoặc tạo khối mới (insertParagraph) phá vỡ toàn bộ format gốc. Cách sửa dành cho user: Dùng từ chính xác, ví dụ: “Chèn bản dịch tiếng Nhật vào sau đoạn tiêu đề 2.1…” → Bài học: Ngôn ngữ hội thoại phải tường minh hành động.

Ba ví dụ thiết kế tool an toàn

So sánh thực tế giữa làm sơ sài và làm chuẩn: A. Description có ràng buộc rõ ràng (Negative Constraints) ✗ Viết sơ sài: “Chèn nội dung vào docs” (AI dễ tự ý xóa/ghi đè) ✓ Viết chuẩn: “Chèn text vào index. KHÔNG xóa hoặc sửa các đoạn đã có”

B. Tách nhỏ tác vụ (không gộp chung hàm lớn) ✗ Gộp hàm: sync_and_update_all() (AI sẽ bị phân vân khi ra quyết định chọn tool) ✓ Tách riêng: read_highlights() và insert_text_at_index()

C. Cơ chế duyệt trước khi ghi đè (Dry-Run / Preview) ✗ Tự chạy ngầm: Âm thầm ghi vào file đích, người dùng không kịp kiểm soát ✓ Confirm trước: AI in thông báo “Sắp chèn 2 đoạn vào mục 3, bạn duyệt không?”

→ Nguyên tắc vàng: Tool mô tả càng chi tiết và có cờ xác nhận, tỉ lệ thực thi chính xác càng tiệm cận 100%.

Tóm lại: Cả người prompt và người code tool đều cần hiểu cơ chế của nhau để tránh các lỗi logic đáng tiếc.

MCP định hình lại cách team làm việc như thế nào?

Giá trị lớn nhất của MCP là trao quyền cho đội ngũ non-tech, giúp mỗi người chủ động tự tạo công cụ cho chính mình:

• Tự xây dựng kịch bản: Nhờ AI viết code MCP Server theo đúng mong muốn mà không phải chờ Dev rảnh tay.
• Làm chủ dữ liệu công việc: Tự động hóa các tác vụ lặp đi lặp lại như đối chiếu tài liệu, cập nhật bảng tính.
• Giao tiếp hoàn toàn tự nhiên: Tương tác 100% bằng ngôn ngữ chat hằng ngày, không cần học cú pháp code.

Lời kết

Qua 3 phần, chúng ta đã đi từ một bài toán rất cụ thể (đồng bộ highlight giữa hai file Google Docs Việt – Nhật), hiểu MCP là gì và hoạt động ra sao, đến tự tay xây dựng một MCP Server với những nguyên tắc thiết kế an toàn.

Thông điệp cuối cùng của series: hãy chuyển từ “người dùng công cụ có sẵn” thành “người kiến tạo công cụ cho bản thân”.

Cảm ơn bạn đã đọc hết series!

Tác giả: Dinh Tuan Anh ー SHIP Vietnam