Tôi vẫn thích MCP hơn Skills

• MCP là giao diện tiêu chuẩn dựa trên trừu tượng hóa API cho phép LLM yêu cầu thực hiện tác vụ mà không cần biết cấu trúc bên trong của công cụ, đồng thời hỗ trợ sử dụng từ xa và cập nhật tự động
• Thông qua kiến trúc Zero-Install, xác thực OAuth và bảo mật sandbox, nó giảm gánh nặng cài đặt và vấn đề quyền hạn, đồng thời cung cấp cùng một môi trường trên mọi nền tảng
• Trong khi đó, Skills gây ra nhiều ma sát trong môi trường thực thi thực tế do phụ thuộc vào cài đặt CLI, độ phức tạp của xác thực và triển khai, cũng như các vấn đề tương thích theo từng nền tảng
• Cần phân biệt Skills là lớp tri thức, còn MCP là lớp kết nối; khi LLM tương tác với hệ thống bên ngoài thì nên dùng MCP, còn khi truyền đạt tri thức mang tính quy trình thì nên dùng Skills
• Các dịch vụ đường hầm đám mây như MCP Nest cho phép truy cập máy chủ MCP cục bộ từ xa, nên được xem là yếu tố cốt lõi để xây dựng môi trường tích hợp AI được chuẩn hóa

---

Ưu điểm của MCP

• Model Context Protocol (MCP) dựa trên cấu trúc trừu tượng hóa API, trong đó LLM có thể thực hiện tác vụ chỉ bằng cách gửi yêu cầu mà không cần hiểu cách công cụ hoạt động bên trong
  • Ví dụ: khi LLM tương tác với DEVONthink, nó gọi devonthink.do_x() và máy chủ MCP sẽ xử lý toàn bộ phần còn lại
• Có thể sử dụng từ xa theo kiểu Zero-Install, nên phía client chỉ cần chỉ định URL của máy chủ MCP là có thể hoạt động ngay mà không cần cài đặt thêm
• Hỗ trợ cập nhật tự động, vì vậy khi máy chủ MCP từ xa được cập nhật với công cụ hoặc tài nguyên mới, mọi client đều có thể dùng ngay phiên bản mới nhất
• Bảo mật được tăng cường với xác thực dựa trên OAuth, và người dùng không cần tự quản lý token
• Có tính di động cao, có thể truy cập qua cùng một máy chủ MCP trên bất kỳ môi trường nào như Mac, di động hay web
• Nhờ cấu trúc sandbox, nó hạn chế quyền thực thi trực tiếp trên môi trường cục bộ và chỉ phơi bày giao diện đã được kiểm soát
• Thông qua các tính năng tìm kiếm thông minh và cập nhật tự động, chỉ những công cụ cần thiết mới được tải, và ngay cả khi cài cục bộ thì cũng có thể tự động cập nhật khi chạy

Giới hạn và ma sát của Skills

• Skills hữu ích để dạy cho LLM kiến thức hoặc cách sử dụng cụ thể, nhưng khi thực hiện hành động thực tế thì sự phụ thuộc vào CLI trở thành vấn đề
• Phần lớn Skill yêu cầu cài đặt CLI riêng, trong khi các bản web của ChatGPT, Perplexity hay Claude lại không thể chạy CLI
• Điều này dẫn đến các vấn đề sau
  • Độ phức tạp khi triển khai: phải phân phối và quản lý CLI dưới dạng binary, NPM, uv, v.v.
  • Vấn đề quản lý bí mật: token xác thực bị lưu dưới dạng văn bản thuần trong file .env, hoặc phiên xác thực biến mất khi session bị khởi tạo lại
  • Sự chia cắt hệ sinh thái: cách cài đặt và cập nhật Skill khác nhau theo từng nền tảng, gây ra vấn đề tương thích và lỗi phân tích YAML
  • Lãng phí ngữ cảnh: dù LLM chỉ cần một lệnh gọi hàm duy nhất, nó vẫn phải tải toàn bộ SKILL.md
• Những Skill có kèm chỉ dẫn kiểu “hãy cài CLI trước” chỉ làm tăng thêm độ phức tạp không cần thiết, và MCP từ xa là phương án thay thế hiệu quả hơn

Tiêu chí chọn công cụ phù hợp

• Khi nào dùng MCP: dùng như một giao diện tiêu chuẩn khi LLM cần kết nối với các hệ thống bên ngoài như website, dịch vụ hay ứng dụng
  • Ví dụ: Google Calendar nên xử lý xác thực và thực thi qua MCP từ xa dựa trên OAuth, và không nên yêu cầu cài CLI
  • Với Chrome, Hopper, Xcode, Notion, v.v., lý tưởng nhất là mỗi công cụ đều cung cấp endpoint MCP tích hợp sẵn để điều khiển chức năng tương ứng
• Khi nào dùng Skills: nên tập trung vào việc truyền đạt tri thức thuần túy và cung cấp ngữ cảnh
  • Dùng để hướng dẫn cách sử dụng các công cụ đã được cài sẵn như curl, git, gh, gcloud
  • Chuẩn hóa thuật ngữ nội bộ, quy trình làm việc và văn phong trong tổ chức
  • Chia sẻ tri thức mang tính quy trình như xử lý PDF hay quản lý bí mật (ví dụ cách dùng fnox)
• Cần phân biệt rõ Skills là lớp tri thức, còn MCP là lớp kết nối

Connector và manual

• Để phân biệt rõ vai trò của Skills và MCP, có đề xuất gọi Skills là sổ tay cho LLM (LLM_MANUAL.md), còn MCP là connector
• Một số ví dụ đang được vận hành thực tế
  • mcp-server-devonthink: máy chủ MCP cục bộ cho phép LLM điều khiển trực tiếp DEVONthink
  • microfn: cung cấp MCP từ xa tại mcp.microfn.dev
  • Kikuyo: cung cấp MCP từ xa tại mcp.kikuyo.dev
  • MCP Nest: dịch vụ cho phép truy cập từ xa bằng cách tạo đường hầm đám mây cho máy chủ MCP cục bộ (mcp.mcpnest.dev/mcp)
• Trong một số dự án, Skill dành cho CLI cũng được cung cấp kèm theo, nhưng Skill giải thích cách sử dụng MCP còn hữu ích hơn
  • Skill hoạt động như lớp tri thức giải thích về tính năng của MCP, mối quan hệ giữa các công cụ và thời điểm sử dụng
  • MCP đảm nhiệm việc kết nối và thực thi thực tế
• Sự kết hợp này giúp LLM tận dụng MCP hiệu quả mà không phải lặp đi lặp lại việc thử sai

Kết hợp MCP và Skill

• Những mẫu không trực quan được phát hiện khi dùng MCP, như lỗi định dạng ngày tháng hay giới hạn tìm kiếm, có thể được tổng hợp thành Skill để tái sử dụng
• Những Skill được tạo theo cách này đóng vai trò như cheat sheet cho MCP, giúp LLM hoạt động chính xác mà không lãng phí token không cần thiết
• Thông qua thư mục .claude/skills, có thể duy trì hướng dẫn hành vi AI theo từng dự án và quản lý các quy trình dùng thường xuyên dưới dạng dotfiles
• Tương lai của tích hợp AI phụ thuộc vào các giao diện được chuẩn hóa (MCP), còn cách tiếp cận phân mảnh dựa trên CLI nên được tránh
• Có kỳ vọng rằng các dịch vụ lớn như Skyscanner, Booking.com, Trip.com, Agoda.com sẽ cung cấp MCP chính thức

Giới thiệu MCP Nest

• MCP Nest là dịch vụ cho phép các máy chủ MCP chỉ dùng cục bộ (Fastmail, Gmail, v.v.) có thể được truy cập từ xa thông qua đường hầm đám mây
• Có thể dùng giống nhau trên các client hỗ trợ MCP như Claude, ChatGPT, Perplexity
• Có thể duy trì cùng một môi trường MCP trên mọi thiết bị mà không cần phơi bày trực tiếp máy cục bộ

[jujumilk3]

Chỉ là hai thứ vốn hoàn toàn khác nhau, vậy mà sao những câu chuyện kiểu này cứ liên tục xuất hiện nhỉ

[xguru]

Vì cuối bài phải quảng bá MCP Nest mà.. haha. Có vẻ mấy lập luận mang tính so sánh đang được hưởng ứng khá mạnh.

[jjw9512151]

Skills là kiếm thuật, còn MCP là thanh kiếm.. Mục đích sử dụng khác nhau và cả hai đều cần thiết.

[ide127]

Skills và MCP vốn đảm nhiệm những vai trò khác nhau, nhưng có vẻ chính vì những bài viết như thế này mà mọi người cứ tiếp tục bị nhầm lẫn.

[ide127]

Đã là một ngành AI hỗn loạn với đầy rẫy những kẻ truyền đạo giả danh rồi mà

[GN⁺]

Ý kiến Hacker News

• Điều tôi muốn nhấn mạnh là nên tập trung vào thiết kế công cụ mà LLM cần để làm việc tối ưu, hơn là sở thích cá nhân
  MCP lại còn làm tăng ma sát. Ví dụ, nếu làm với hệ thống nhúng thì hãy để LLM có thể trực tiếp debug, reset, chạy emulator, v.v. thông qua một giao diện giám sát dựa trên CLI, rồi tài liệu hóa cách dùng bằng file skill là đủ
  Với tác vụ đơn giản thì MCP là không cần thiết. Ví dụ như git hay tính chi phí AWS thì LLM đã xử lý tốt rồi. Chỉ những hệ thống phức tạp mới đáng để tự làm công cụ và tài liệu hóa

  • Tôi thấy cuộc thảo luận về MCP đang trộn quá nhiều khái niệm với nhau. Điểm cốt lõi là tính liên tục của phiên
    Nếu chỉ dùng một lần thì CLI hay API là đủ, nhưng nếu cần truy cập liên tục thì máy chủ MCP sẽ hữu ích
    Một MCP được tổ chức tốt có thể chỉ cho agent cách dùng mà không lãng phí prompt. Việc bắt chước truy cập liên tục bằng file skill là không hiệu quả. MCP là cách hiệu quả nhất để tích hợp công cụ bên ngoài vào phiên của agent
  • MCP và skill là quan hệ bổ trợ. Xem chúng như hai phía đối lập là hiểu sai
  • Chuỗi công cụ LLM hiện tại vẫn giống một giai đoạn chuyển tiếp chưa được chuẩn hóa. Thay vì nhét thông tin vào nhiều nơi như .md hay skill, cần có một chuẩn để sắp xếp vào vị trí tối ưu thông qua vòng lặp tự phản tư tự động
  • Tôi cũng làm theo hướng tương tự. Phần lớn công cụ CLI là do chính Claude tạo ra, và tôi hầu như không dùng IDE
    Ngay cả tính năng refactor của JetBrains cũng được thay bằng script nên thời gian mỗi phiên giảm từ 5 phút xuống còn 10 giây
    Tôi vẫn chưa dùng MCP chút nào. Tổ hợp REST + Swagger + codegen + Claude + skill là đủ
  • Ưu điểm của MCP là kiểm soát quyền hạn. Ví dụ, nếu không muốn AI có quyền ghi vào git thì có thể dùng MCP để giới hạn phạm vi được lộ ra. Chỉ dùng READ_ONLY_SKILL là không đủ

• Tranh luận này rốt cuộc là vấn đề lập trình viên cá nhân vs cộng tác ở quy mô tổ chức
  Nếu làm một mình và muốn vòng phản hồi nhanh thì CLI tốt hơn, còn nếu cần kiểm soát và tính nhất quán ở cấp tổ chức thì MCP phù hợp hơn
  Hiện tại MCP ngốn khá nhiều ngữ cảnh, nhưng dự kiến sẽ được cải thiện bằng cách công bố dần từng phần

  • Trong tổ chức có vấn đề là kiểm soát truy cập MCP rất khó. Con người lỡ tay xóa hai cái thì còn được, nhưng agent có thể xóa hàng nghìn thứ trong chớp mắt. CLI an toàn hơn vì có thể giới hạn phạm vi truy cập
  • Việc lãng phí ngữ cảnh là vấn đề ở phía triển khai client. Tải dần từng phần có thể làm được mà không cần thay đổi spec
  • MCP và CLI là các công cụ phục vụ mục đích khác nhau, và mạnh nhất khi dùng cùng nhau

• Tôi muốn một agent dùng nguyên trạng các công cụ CLI hiện có hơn là API
  Tôi đã dùng CLI ở local rồi thì chẳng có lý do gì phải thêm MCP. Tôi cũng không muốn mô hình chạy từ xa
  Nếu cần gọi API thì skill là đủ

  • Tôi cũng chèn trực tiếp lệnh curl vào skill để gọi API tùy biến. LLM xử lý mấy thứ này khá tốt
  • Nhưng quản lý khóa bí mật thì MCP an toàn hơn. Nếu khởi chạy máy chủ MCP trước, khóa sẽ không bị lộ trong môi trường của agent
  • MCP đóng vai trò là lớp ranh giới bảo mật giữa agent và thế giới bên ngoài. Không phải lúc nào cũng cần, nhưng rất hữu ích
  • Ở một số môi trường, LLM có thể không có quyền truy cập CLI. Khi đó kiểu gọi CLI dựa trên skill sẽ vô dụng
  • Cũng có vấn đề về xác thực (authn) và phân quyền (authz). MCP có thể kiểm soát các thứ này như middleware

• MCP và Skill không phải quan hệ zero-sum
  MCP phụ trách giao diện chuẩn hóa ở tầng hạ tầng, còn Skill đảm nhiệm ngữ cảnh hành vi theo từng dự án
  Kết hợp cả hai sẽ có được cả tính ổn định lẫn tính linh hoạt

  • MCP về bản chất vẫn là dạng bọc ngoài cho CLI. Thậm chí MCP còn có overhead ngữ cảnh lớn hơn
  • Một số MCP trả phí thực sự có giá trị. Ví dụ MCP cho tìm kiếm web tiện hơn là tự chạy crawler
  • Trong các agent được host trên cloud, tổ hợp Skill + MCP là cấu trúc then chốt. Xác thực và quản lý phụ thuộc đều dễ hơn
  • Tác giả bài viết cũng ủng hộ tổ hợp này. MCP có tính di động cao nên có thể dùng giống nhau trên ChatGPT, Claude, Perplexity, v.v.
  • Skill có thể bị LLM bỏ qua, nhưng chính sách của MCP có tính cưỡng chế ở phía máy chủ

• Phần lớn thảo luận đều xoay quanh những người chạy coding agent ở local
  Trong môi trường như vậy, Skill tiện hơn, nhưng người dùng phổ thông lại dùng dịch vụ cloud như ChatGPT
  Trong trường hợp này, MCP là lựa chọn mặc định. Xác thực và truy cập từ xa là điểm mạnh

  • Nhưng có người cho rằng MCP chỉ là một wrapper API ồn ào
    Phải dựng server, và với LLM thì còn là gánh nặng. Skill đơn giản hơn vì mã hóa tài liệu API theo cách thân thiện với LLM
  • Cũng có phản biện rằng nhận định “đa số người dùng không dùng agent local” cần có bằng chứng
  • Cũng có một câu đùa sửa lỗi chính tả từ ‘agronomic’ thành ‘ergonomic’

• Tôi thích Skill hơn. Vì có thể tái sử dụng nguyên xi các công cụ CLI mà con người dùng
  Skill là tài liệu con người có thể đọc và viết, nên LLM và con người cùng chia sẻ công cụ
  Trong khi đó MCP buộc phải tạo API mới dành riêng cho LLM, và tài liệu cũng phải quản lý riêng
  Skill chỉ được nạp khi cần nên giữ ngữ cảnh gọn gàng

• Người chỉ ủng hộ “Skill thôi” thường là không chuyên kỹ thuật, còn kiểu “chỉ CLI” thì hay gặp ở lập trình viên cá nhân
  MCP phù hợp với môi trường enterprise. Nó chuẩn hóa xác thực và giao diện

  • Nhiều người có ác cảm với MCP vì sự thiếu ổn định của JIRA MCP. Skill dựa trên acli ổn định hơn
  • Tôi đã tự xây MCP nội bộ cho công ty. Gắn xác thực Google Workspace vào và để Claude truy vấn dữ liệu nội bộ hay triển khai ứng dụng một cách an toàn
    MCP dễ cập nhật và triển khai nên ngay cả người không chuyên kỹ thuật cũng dễ tiếp cận
  • Cũng có ý kiến cho rằng doanh nghiệp vốn đã có sẵn hệ thống xác thực nội bộ nên CLI tốt hơn
    Xét cho cùng, MCP chỉ là một tập con được cấu trúc lại của API
  • MCP có thể dựng rất nhanh. Cấu hình nối tiếp Codex → LiteLLM → VLLM → MCP chỉ mất vài phút
  • Tôi xem các hệ thống SaaS hiện tại là legacy
    So với API khó truy cập dữ liệu, DB SQL local hiệu quả hơn nhiều
    MCP chỉ là thêm một giao thức RPC nữa, và bài toán xác thực vẫn chưa được giải quyết

• Tôi cho rằng MCP là cần thiết vì sự phi lý của con người
  Nhiều tổ chức vẫn không cung cấp API hay CLI. MCP giúp lấp khoảng trống đứt gãy số này
  Trong doanh nghiệp, hệ thống báo cáo hay cấu trúc chính trị đang cản trở tự động hóa, và MCP có thể lách qua các rào cản đó

  • Tôi cũng đồng ý. Nếu agent của đồng nghiệp có thể cộng tác thay họ thì việc số hóa tổ chức sẽ dễ hơn rất nhiều. MCP tốt ở chỗ nó che giấu độ phức tạp của dây nối này

• Skill có vấn đề phình ngữ cảnh vì phải đưa toàn bộ tài liệu vào context
  MCP cũng tương tự, nhưng có thể tải dần nhờ chức năng khám phá công cụ
  Vấn đề lớn hơn là đầu ra của MCP đi thẳng vào context của agent. Nếu gọi dịch vụ MCP qua CLI thì có thể lọc hoặc cache được

  • Cũng có phản ứng kiểu “thế thì dùng HTTP request luôn chẳng phải xong sao?”
  • Tác giả bài viết giải thích rằng MCP mới nhất đã giải quyết bằng lazy loading dựa trên khám phá công cụ. Claude Code dùng sub-agent để tránh log bị tràn
  • Tôi giải quyết bằng cách bọc MCP local với cache bộ nhớ. Gán ID cho đầu ra của từng công cụ, rồi dùng ID đó để gọi các công cụ khác. Cách này hiệu quả trong việc tiết kiệm token và tăng tốc

• Skill phù hợp để chứa tri thức trực giác, còn MCP hợp với tự động hóa có thể lặp lại
  Nếu LLM cứ phải viết đi viết lại cùng một script thì cố định nó thành công cụ sẽ hiệu quả hơn

  • Phần lớn quy trình nên được tiền xử lý bằng script, còn LLM chỉ nên tham gia vào việc lập kế hoạch và kiểm chứng
    Nói cách khác, điểm mấu chốt là tiền xử lý bằng script nhiều nhất có thể
  • Cũng có thể nhúng trực tiếp script vào skill. skill có thể chứa cả code
  • Tác giả nguyên văn cho biết đây là bài viết do người thật viết khi đang ở trên máy bay, không phải do AI
  • Có người nói họ cũng dùng skill cho tác vụ lặp lại, và từ đó cuộc thảo luận tiếp tục theo góc nhìn hợp đồng API của MCP
    Nếu chỉ là script nhỏ thì cứ đưa vào context rồi bảo “hãy dùng cái này” là đủ