AI Skills: Lớp hướng dẫn mỏng trên MCP Tools

Khi xây dựng AI Agent hoặc AI assistant cho ứng dụng doanh nghiệp, một trong những câu hỏi quan trọng là: làm sao để AI không chỉ “có tool để gọi”, mà còn biết dùng tool đó đúng cách?

MCP giúp giải quyết phần đầu tiên: cung cấp cho AI một chuẩn để truy cập tool, API, database, file system hoặc các hệ thống bên ngoài. Nhưng trong thực tế, chỉ expose tool cho AI là chưa đủ. Một tool có thể gọi được không có nghĩa là AI luôn hiểu khi nào nên gọi, gọi với tham số nào, mapping dữ liệu ra sao, xử lý lỗi thế nào và trả lời người dùng theo format nào.

Đây là lúc AI Skills trở nên rất hữu ích. Có thể xem Skill như một lớp hướng dẫn mỏng nằm trên MCP Tools. MCP cung cấp khả năng hành động. Skill cung cấp quy tắc sử dụng khả năng đó.

MCP Tools giải quyết vấn đề gì?

MCP, viết tắt của Model Context Protocol, giúp AI assistant kết nối với các công cụ bên ngoài theo một cách có cấu trúc. Thay vì AI chỉ trả lời bằng văn bản, nó có thể gọi tool để lấy dữ liệu, tạo bản ghi, cập nhật thông tin, tìm kiếm tài liệu hoặc gọi một REST API.

Ví dụ trong hệ sinh thái Oracle APEX, một MCP tool có thể được dùng để:

• Gọi ORDS REST API.
• Đọc metadata từ Oracle Database.
• Tạo hoặc cập nhật record thông qua service được kiểm soát.
• Truy vấn dữ liệu báo cáo.
• Gọi PL/SQL package thông qua ORDS endpoint.
• Tạo ghi chú, task hoặc ticket trong một hệ thống nội bộ.

MCP rất mạnh vì nó chuẩn hóa cách AI nhìn thấy và gọi tool. Nhưng MCP thường mô tả tool ở mức kỹ thuật: service nào, endpoint nào, method nào, parameter nào, response dạng gì.

Vấn đề là workflow nghiệp vụ thường không chỉ nằm ở endpoint. Nó nằm ở quy ước sử dụng.

Vấn đề của raw tool access

Giả sử bạn expose một ORDS REST API cho AI:

GET    /tasks
POST   /tasks
PUT    /tasks/{id}
DELETE /tasks/{id}

Về mặt kỹ thuật, AI đã có thể tạo, đọc, cập nhật và xóa task. Nhưng các câu hỏi thực tế sẽ phức tạp hơn:

• Khi user nói “nhắc tôi ngày mai”, có nên tạo task không?
• Trường nào dùng làm tiêu đề?
• Trường nào dùng làm nội dung chi tiết?
• Ngày “ngày mai” cần convert theo timezone nào?
• Task mặc định có urgency là gì?
• Nếu user nói “ý tưởng này hay”, nên tạo note hay idea?
• Nếu user hỏi “show việc cần làm”, filter thế nào?
• Khi trả lời, có nên hiển thị raw JSON không?

Nếu chỉ có MCP tool, AI phải tự suy luận rất nhiều. Có lúc nó suy luận đúng, có lúc nó chọn sai tool, sai field hoặc trả lời quá dài.

Đây là lý do raw tool access chưa đủ cho các workflow nghiêm túc.

AI Skill là gì trong bối cảnh này?

AI Skill có thể hiểu là một gói hướng dẫn chuyên biệt cho một loại công việc. Nó mô tả cho AI biết:

• Khi nào nên dùng workflow này.
• Tool MCP nào cần gọi.
• Service ID, path, method và query pattern nào là đúng.
• Field nào cần map từ ngôn ngữ tự nhiên sang dữ liệu có cấu trúc.
• Các rule mặc định là gì.
• Khi nào hỏi lại user.
• Khi nào không được gọi tool.
• Cách trả lời người dùng sau khi tool chạy xong.

Nói cách khác, Skill không thay thế MCP Server. Skill cũng không thay thế REST API. Skill là lớp hướng dẫn giúp AI dùng MCP Tool đúng hơn trong một ngữ cảnh cụ thể.

Lược đồ Skills nằm trên MCP Tools

Ví dụ với Oracle APEX và ORDS

Giả sử bạn có một ứng dụng APEX quản lý “second brain” nội bộ: ghi chú, ý tưởng, việc cần làm, kiến thức và reminder.

Database có bảng:

SB_ENTRIES
- ENTRY_ID
- SUBJECT
- ENTRY_TYPE
- USER_CONTENT
- AI_SUMMARY
- URGENCY
- ACTION_REQUIRED
- DUE_DATE
- CREATED_BY
- CREATED_AT

Bạn expose bảng này qua ORDS REST API:

GET    /sb_entries
POST   /sb_entries
PUT    /sb_entries/{entry_id}
DELETE /sb_entries/{entry_id}

Sau đó MCP Server expose ORDS API này cho AI. Tới đây, AI có tool để gọi API. Nhưng vẫn còn thiếu một lớp rất quan trọng: AI cần hiểu “second brain” trong ứng dụng của bạn nghĩa là gì.

Không có Skill thì AI dễ dùng sai tool

Khi user nói:

Ngày mai nhắc tôi review tài liệu ORDS.

AI có thể hiểu đây là:

• Một calendar event.
• Một task trong Microsoft Planner.
• Một reminder trong hệ điều hành.
• Một note trong second brain.
• Một task trong ứng dụng APEX nội bộ.

Nếu môi trường AI có nhiều tool, việc chọn đúng tool trở nên khó hơn. Tool nào cũng có vẻ hợp lý.

Skill giúp giảm mơ hồ bằng cách nói rõ:

Dùng skill này khi user muốn lưu note, task, idea,
knowledge item hoặc reminder-style entry vào second brain.

Nhờ vậy, AI có định hướng rõ hơn và ít chọn nhầm tool hơn.

Skill nên chứa những gì?

Một Skill tốt nên ngắn gọn nhưng đủ rõ. Không cần biến Skill thành tài liệu quá dài. Mục tiêu là đưa cho AI các rule vận hành quan trọng nhất.

Nội dung thường nên có:

• Tên Skill và mô tả khi nào dùng.
• Tool MCP hoặc service cần gọi.
• Các core rules.
• Mapping từ ngôn ngữ tự nhiên sang field.
• Request patterns chuẩn.
• Batch rules nếu xử lý nhiều item.
• Pagination rules nếu list dữ liệu.
• Error handling rules.
• Response style.
• Các điều không được làm.

Skill càng cụ thể, AI càng ít phải đoán. Nhưng Skill cũng không nên quá phức tạp đến mức khó bảo trì.

Ví dụ cấu trúc Skill cho Second Brain

Một file Skill có thể mô tả như sau:

---
name: second-brain
description: Use when the user wants to add, update, list,
or delete second-brain notes, tasks, ideas, knowledge items,
or reminder-style entries through the ORDS MCP tool.
---

# Second Brain

Use this skill for second-brain CRUD work through the ORDS MCP tool.

## Core Rules

- Use service_id: "sb_entries".
- Use path: "sb_entries" for create and list.
- Use path: "sb_entries/{entry_id}" for read, update, delete.
- Prefer structured query objects.
- Do not send raw JSON response to the user.
- Summarize only the fields the user needs.

## Field Mapping

- todo, task, reminder -> entry_type: "TASK"
- note -> entry_type: "NOTE"
- idea -> entry_type: "IDEA"
- knowledge -> entry_type: "KNOWLEDGE"
- For todos/reminders, action_required = "Y"
- Default urgency = "LOW"
- Convert relative dates to YYYY-MM-DD.

## Response Style

- For creates, return entry id, subject and due date.
- For lists, return compact results.
- Do not expose raw tool payloads.

Phần quan trọng không phải là cú pháp cụ thể. Phần quan trọng là Skill mô tả workflow ở mức mà AI có thể làm theo.

Field mapping giúp giảm lỗi rất nhiều

Một trong những phần giá trị nhất của Skill là field mapping. User thường không nói theo tên cột database.

User nói:

Lưu ý tưởng này lại: làm dashboard theo dõi lỗi đăng nhập.

Nhưng database cần:

ENTRY_TYPE = IDEA
SUBJECT = Làm dashboard theo dõi lỗi đăng nhập
USER_CONTENT = ...
ACTION_REQUIRED = N
URGENCY = LOW

Nếu không có mapping, AI có thể chọn sai ENTRY_TYPE hoặc thiếu field bắt buộc.

Với Skill, bạn có thể định nghĩa rõ:

• “ý tưởng” map thành IDEA.
• “việc cần làm” map thành TASK.
• “nhắc tôi” map thành TASK có DUE_DATE.
• “kiến thức” map thành KNOWLEDGE.

Đây là lớp ngữ nghĩa mà MCP tool thuần kỹ thuật thường không thể mô tả đủ tốt.

Request pattern giúp AI gọi tool ổn định hơn

Một lỗi thường gặp khi AI gọi API là truyền tham số không đúng format. Ví dụ ORDS có thể yêu cầu filter theo cú pháp cụ thể, nhưng AI lại gửi query parameter kiểu tự nghĩ ra.

Skill nên ghi rõ pattern đúng.

Ví dụ list các task còn active:

{
  "service_id": "sb_entries",
  "method": "GET",
  "path": "sb_entries",
  "query": {
    "q": {
      "entry_type": {
        "$eq": "TASK"
      },
      "action_required": {
        "$eq": "Y"
      }
    }
  },
  "page_limit": "1",
  "item_limit": "25"
}

Khi có pattern mẫu, AI không cần đoán cấu trúc request. Điều này làm tool call ổn định hơn, đặc biệt với các API có cú pháp filter riêng.

Response style cũng rất quan trọng

Tool response thường chứa nhiều thông tin kỹ thuật: headers, links, pagination, metadata, raw JSON, status code, field nội bộ.

Người dùng cuối thường không cần tất cả những thứ này. Skill nên nói rõ cách trả lời.

Ví dụ:

• Không paste raw MCP JSON vào câu trả lời.
• Với create task, chỉ trả entry id, subject và due date.
• Với list task, trả danh sách ngắn gọn.
• Nếu lỗi do thiếu thông tin, hỏi một câu rõ ràng.
• Nếu API lỗi, báo lỗi dễ hiểu, không đổ toàn bộ stack trace ra UI.

Đây là điểm rất quan trọng trong ứng dụng doanh nghiệp. AI không chỉ cần gọi đúng tool, mà còn cần giao tiếp kết quả đúng cách.

Skill như executable documentation

Một lợi ích rất hay của Skill là nó vừa là hướng dẫn cho AI, vừa là tài liệu cho developer.

Thay vì chỉ có tài liệu API nói rằng endpoint POST /sb_entries nhận các field nào, Skill mô tả luôn hành vi mong muốn:

• Khi nào tạo task.
• Khi nào tạo note.
• Khi nào update item cũ.
• Cách hiểu relative date.
• Cách sort kết quả.
• Cách trả lời user.

Đây là tài liệu ở mức workflow, không chỉ ở mức transport.

Với team APEX/ORDS, điều này rất hữu ích. Developer mới có thể đọc Skill để hiểu AI workflow được kỳ vọng hoạt động như thế nào.

Explicit invocation giúp giảm nhầm lẫn

Một lợi ích khác của Skill là có thể được gọi rõ ràng trong một số môi trường AI. Ví dụ user có thể nói:

$second-brain thêm task ngày mai review ORDS module.

Khi đó, AI không phải đoán giữa calendar, planner, email hay ứng dụng task nội bộ. Người dùng đã chỉ rõ workflow cần dùng.

Explicit invocation rất hữu ích khi hệ thống có nhiều tool gần giống nhau. Ví dụ:

• Calendar tool để tạo lịch.
• Planner tool để tạo task team.
• Second brain tool để lưu task cá nhân.
• Ticket tool để tạo issue hỗ trợ.

Nếu không có cách chỉ định rõ, một yêu cầu như “nhắc tôi ngày mai” có thể bị đưa vào sai hệ thống.

Áp dụng vào Oracle APEX như thế nào?

Với Oracle APEX, pattern Skills + MCP rất phù hợp vì APEX thường có nhiều business workflow được expose qua PL/SQL package, ORDS endpoint hoặc REST Data Source.

Ví dụ:

• Skill quản lý ticket hỗ trợ.
• Skill tạo đơn hàng.
• Skill cập nhật trạng thái hồ sơ.
• Skill tìm kiếm dữ liệu khách hàng.
• Skill tạo ghi chú CRM.
• Skill kiểm tra lỗi ứng dụng từ bảng log.
• Skill tạo task follow-up sau cuộc gọi.

Mỗi Skill có thể hướng dẫn AI dùng đúng ORDS tool tương ứng, mapping đúng field và tuân thủ đúng quy trình nghiệp vụ.

Không nên để Skill thay thế bảo mật

Cần nhấn mạnh: Skill là hướng dẫn, không phải lớp bảo mật.

Nếu Skill nói “không được xóa dữ liệu production”, điều đó tốt, nhưng không đủ. Bảo mật thật vẫn phải nằm ở:

• Database privileges.
• ORDS authentication.
• Authorization ở server-side.
• APEX authorization schemes.
• Validation trong PL/SQL package.
• Audit log.
• Human approval cho hành động rủi ro cao.

Skill giúp AI hành xử đúng hơn. Nhưng hệ thống vẫn phải được thiết kế để an toàn ngay cả khi AI gọi sai tool hoặc truyền tham số sai.

Thiết kế MCP Tool tốt trước, rồi mới thêm Skill

Skill không thể cứu một tool được thiết kế kém. Nếu API quá mơ hồ, field không rõ nghĩa, quyền không được kiểm soát, response không ổn định hoặc endpoint làm quá nhiều việc cùng lúc, Skill sẽ khó giúp AI dùng tool tốt.

Trước khi viết Skill, bạn nên thiết kế MCP Tool/API tốt:

• Tool nhỏ, rõ mục đích.
• Input/output có schema rõ ràng.
• Tên field dễ hiểu.
• Error message nhất quán.
• Không expose dữ liệu nhạy cảm không cần thiết.
• Phân biệt tool đọc dữ liệu và tool ghi dữ liệu.
• Có authorization ở server-side.
• Có audit log cho hành động quan trọng.

Sau đó Skill mới đóng vai trò hướng dẫn cách dùng tool trong workflow cụ thể.

Ví dụ: Skill cho APEX Support Ticket

Giả sử bạn có ORDS endpoint:

GET    /tickets
POST   /tickets
PUT    /tickets/{ticket_id}

Skill có thể định nghĩa:

• “lỗi”, “bug”, “không chạy” → tạo ticket type BUG.
• “yêu cầu”, “cần thêm chức năng” → tạo ticket type REQUEST.
• Nếu thiếu mức độ ưu tiên, mặc định priority MEDIUM.
• Nếu user nói “gấp”, priority HIGH.
• Nếu user chưa mô tả lỗi đủ rõ, hỏi thêm một câu.
• Sau khi tạo ticket, trả ticket id và trạng thái.
• Không trả raw JSON.

Nhờ Skill, AI không chỉ biết gọi POST /tickets. AI biết cách biến câu nói tự nhiên của user thành ticket đúng quy ước của hệ thống.

Ví dụ: Skill cho tra cứu log APEX

Một Skill khác có thể dùng để tra cứu log ứng dụng:

• Khi user hỏi “vì sao page 27 lỗi”, dùng tool đọc bảng log.
• Filter theo app id, page id, user và khoảng thời gian nếu có.
• Mặc định lấy 50 dòng gần nhất.
• Nhóm lỗi theo error code hoặc process name.
• Không hiển thị dữ liệu nhạy cảm.
• Trả kết quả theo dạng: lỗi chính, thời điểm, user ảnh hưởng, gợi ý kiểm tra.

Đây là workflow rất thực tế cho APEX developer. MCP tool cung cấp khả năng đọc log, Skill hướng dẫn cách phân tích và trình bày kết quả.

Khi nào nên tạo Skill?

Không phải tool nào cũng cần Skill. Với tool rất đơn giản, mô tả tool có thể đủ.

Nên tạo Skill khi:

• Workflow có nhiều bước.
• User request cần được diễn giải theo domain.
• Có nhiều tool dễ bị nhầm lẫn.
• API có query/filter syntax đặc biệt.
• Có nhiều field mapping từ ngôn ngữ tự nhiên sang database.
• Cần response format nhất quán.
• Cần batch rules hoặc pagination rules.
• Cần human approval hoặc safety rules.

Nếu bạn thấy mình phải nhắc AI cùng một quy tắc nhiều lần, đó là dấu hiệu nên đưa quy tắc đó vào Skill.

Checklist viết Skill trên MCP Tool

• Skill dùng cho workflow nào?
• Khi nào nên dùng Skill này?
• Khi nào không nên dùng?
• MCP service/tool nào được phép gọi?
• Path/method chuẩn là gì?
• Field mapping từ ngôn ngữ tự nhiên sang API là gì?
• Default values là gì?
• Batch limit là bao nhiêu?
• Pagination xử lý thế nào?
• Khi thiếu thông tin thì hỏi lại hay dùng default?
• Response cho user nên ngắn hay chi tiết?
• Có field nào không được hiển thị không?
• Có hành động nào cần approval không?

Best practice

• Giữ Skill ngắn gọn, tập trung vào workflow.
• Không nhồi toàn bộ tài liệu API vào Skill nếu không cần.
• Dùng ví dụ request/response chuẩn.
• Ghi rõ các trường hợp không được gọi tool.
• Phân biệt read-only workflow và write workflow.
• Không dùng Skill thay cho authorization.
• Đặt tên Skill rõ ràng, dễ gọi.
• Viết response style để tránh AI trả raw JSON.
• Cập nhật Skill khi API hoặc business rule thay đổi.
• Test Skill bằng nhiều câu nói tự nhiên của user.

Kết luận

MCP Tools và AI Skills giải quyết hai vấn đề khác nhau nhưng bổ sung rất tốt cho nhau. MCP giúp AI có khả năng truy cập tool. Skill giúp AI biết dùng tool đó đúng cách trong một workflow cụ thể.

Với ứng dụng Oracle APEX và ORDS, pattern này rất đáng quan tâm. Bạn có thể expose business capabilities qua ORDS hoặc MCP Tool, sau đó dùng Skill như một lớp hướng dẫn mỏng để định nghĩa intent, field mapping, request pattern, batch rule, pagination rule và response style.

Cách làm này giúp giảm sự mơ hồ, giảm lỗi chọn sai tool, giảm prompt lặp lại và làm cho AI workflow ổn định hơn.

Nhưng cần nhớ: Skill là lớp hướng dẫn, không phải lớp bảo mật. Bảo mật vẫn phải nằm ở database, ORDS, APEX authorization, PL/SQL validation, audit log và quy trình phê duyệt.

Nếu thiết kế đúng, Skills sẽ là lớp rất mỏng nhưng rất có giá trị: không thay thế MCP Server, không thay thế API, nhưng lấp khoảng trống giữa “AI có thể gọi tool” và “AI biết nên dùng tool như thế nào cho đúng trong hệ thống của bạn”.