- CLI đang nổi lên như xu hướng mới cho giao diện công cụ của tác tử, nhưng CLI tùy biến cũng gặp vấn đề ngữ cảnh giống hệt MCP và phải đánh đổi cấu trúc cùng nhiều lợi ích khác
- MCP cục bộ ở chế độ
stdio và MCP từ xa dựa trên Streamable HTTP là hai trường hợp sử dụng hoàn toàn khác nhau, nhưng sự khác biệt này đang bị bỏ qua trong các cuộc tranh luận hiện tại
- Tính năng Prompts và Resources của MCP là cơ chế để phân phối theo thời gian thực các kỹ năng và tài liệu được chuẩn hóa trên toàn tổ chức, đóng vai trò then chốt trong việc chuyển từ vibe coding sang agentic engineering có hệ thống
- Máy chủ MCP tập trung giúp chuẩn hóa xác thực OAuth, telemetry, khả năng quan sát, từ đó cho phép bảo mật ở cấp độ tổ chức và đo lường hiệu quả công cụ
- Với lập trình viên cá nhân, CLI có thể phù hợp hơn, nhưng ở quy mô tổ chức và doanh nghiệp, MCP là công cụ của hiện tại và tương lai để bảo đảm tính nhất quán, bảo mật và chất lượng
Chu kỳ hype do influencer dẫn dắt
- Chỉ 6 tháng trước, Model Context Protocol (MCP) còn là chủ đề nóng nhất của ngành, và mọi nhà cung cấp đều muốn tung ra sản phẩm liên quan đến MCP
- Ngay từ lúc đó đã có góc nhìn hoài nghi kiểu “chỉ là API thôi, sao phải cần wrapper”, và thực tế cũng có những đội ngũ bỏ qua chu kỳ hype của MCP để chọn cách viết tool wrapper đơn giản trên các endpoint REST API
- Trong phần lớn trường hợp sử dụng, MCP ngày càng bị xem là overhead không cần thiết so với việc gọi API trực tiếp
- Hiện nay, diễn ngôn trong ngành đã chuyển sang chỉ trích MCP và ca ngợi CLI, điều này gắn với cấu trúc mà các AI influencer liên tục tạo ra xu hướng mới để duy trì sự chú ý
- Ngay cả những tên tuổi như Garry Tan hay Andrew Ng cũng có xu hướng khái quát hóa trải nghiệm cá nhân, và văn hóa influencer tạo ra FOMO cùng hype đang làm méo mó diễn ngôn trong lĩnh vực này
- Thực tế có những trường hợp CLI phù hợp hơn như một giao diện công cụ cho tác tử, nhưng không phải trong mọi trường hợp
Việc tiết kiệm token của CLI: thực tế và giới hạn
Công cụ CLI có sẵn trong dữ liệu huấn luyện
- Các tiện ích CLI như
jq, curl, git, grep, psql, aws vốn đã có trong tập dữ liệu huấn luyện của LLM nên tác tử có thể dùng ngay mà không cần chỉ dẫn bổ sung, schema hay ngữ cảnh
- MCP phải khai báo trước công cụ trong phản hồi
tools/list, nên phát sinh overhead so với các CLI đã được biết đến sẵn
- Với các công cụ CLI đã có trong dữ liệu huấn luyện, luôn nên ưu tiên dùng chúng hơn MCP
Giới hạn của CLI tùy biến
- Công cụ CLI tùy biến (bespoke) thì LLM không thể tự biết cách dùng, nên phải cung cấp mô tả trong
AGENTS.md hoặc README.md
- Có thể chỉ định thư mục
/cli-tools và dựa vào tên mang tính mô tả, nhưng tác tử thường mắc lỗi với cách này nên cuối cùng vẫn cần thêm tài liệu giải thích
- Ngay cả công cụ như
curl cũng mất lợi thế tiết kiệm token ngay khi nó phải hiểu OpenAPI schema tùy biến
Trích xuất và biến đổi theo chuỗi
- Chuỗi CLI có thể tìm dữ liệu rồi biến đổi để giảm lượng dữ liệu phải đưa vào cửa sổ ngữ cảnh
- Tuy nhiên, nội dung có cấu trúc như HTML, JSON, XML cũng có thể trích xuất bằng các selector như DOM/CSS, JSONPath, XPath, nên đây không phải lợi thế riêng của CLI
Tiêu thụ ngữ cảnh theo kiểu tăng dần
- Trong khi MCP nạp trước toàn bộ bộ công cụ và schema, CLI có thể nạp ngữ cảnh dần dần qua
--help
- Nhưng với CLI tùy biến, tác tử phải dò nội dung help qua nhiều lượt trao đổi, và rốt cuộc sẽ nạp loại thông tin tương tự schema của MCP nhưng không có cấu trúc
- Với những luồng đủ phức tạp, tác tử cuối cùng sẽ phải khám phá hầu hết cây lệnh nên mức tiết kiệm là không đáng kể
- Theo nghiên cứu của Vercel, khi đặt toàn bộ chỉ mục tài liệu trong
AGENTS.md, khả năng tận dụng tài liệu của tác tử được cải thiện; việc cung cấp trước toàn bộ schema có lợi cho việc chọn đúng công cụ
- Khi Anthropic hiện đã cung cấp cửa sổ ngữ cảnh 1 triệu token, vẫn còn là dấu hỏi liệu tiết kiệm token có còn là lập luận mang tính quyết định hay không
Tính hai mặt của MCP: stdio vs Streamable HTTP
Giới hạn của chế độ stdio
- Ở chế độ
stdio, máy chủ MCP chạy cục bộ cùng tác tử và tạo thêm độ phức tạp không cần thiết so với việc viết CLI đơn giản
- Trong phần lớn trường hợp sử dụng, MCP ở chế độ
stdio là không cần thiết
Giá trị đột phá của Streamable HTTP
- MCP dùng phương thức truyền Streamable HTTP cho phép chạy cùng một logic trên máy chủ tập trung, và là yếu tố cốt lõi để chuyển từ vibe coding sang agentic engineering trong bối cảnh tổ chức và doanh nghiệp
- Phần lớn influencer không phân biệt được hai chế độ này
Ưu điểm của máy chủ MCP tập trung
Tính năng backend phong phú
- Trên máy chủ tập trung, công cụ có thể tận dụng các khả năng nền tảng phong phú như instance Postgres hay truy vấn đồ thị Cypher dựa trên Apache AGE
- Ở phía tác tử, chỉ cần cấu hình endpoint HTTP và token xác thực nên việc triển khai rất đơn giản
- Cơ sở dữ liệu cục bộ như SQLite cũng có thể dùng, nhưng bị hạn chế khi cần chia sẻ trạng thái trên toàn tổ chức
Runtime tác tử tạm thời
- Trong các môi trường runtime tạm thời như GitHub Actions, có thể dùng công cụ cần backend phức tạp thông qua máy chủ MCP từ xa mà không cần cài đặt gì
- Việc quản lý workload có trạng thái trong môi trường stateless được giao cho máy chủ trung tâm
Xác thực và bảo mật
- Nếu dùng CLI để truy cập API bảo mật, mọi lập trình viên đều phải truy cập trực tiếp API key, gây gánh nặng lớn cho đội vận hành
- Khi tập trung phía sau máy chủ MCP, lập trình viên chỉ cần xác thực với máy chủ MCP bằng OAuth, còn API key và secret nhạy cảm được kiểm soát phía sau máy chủ
- Khi một thành viên rời nhóm, chỉ cần thu hồi token OAuth, và người đó vốn dĩ chưa từng truy cập các key hay secret khác
Telemetry và khả năng quan sát
- Trên máy chủ MCP tập trung, có thể thu thập trace và metric bằng các công cụ chuẩn như OpenTelemetry
- Có thể biết công cụ nào hiệu quả, runtime tác tử nào đang được dùng, và công cụ thất bại ở đâu
- CLI cũng làm được, nhưng triển khai cục bộ đòi hỏi cập nhật tới bên tiêu thụ và phải lặp lại phần khung telemetry cho từng công cụ CLI
Triển khai tức thì được chuẩn hóa và tự động cập nhật
- Công cụ phân tán (gói cài đặt) gây ra vấn đề tương thích phiên bản API, còn MCP dùng Subscriptions và Notifications để máy chủ thông báo cập nhật cho client
- MCP Prompts tương ứng với
SKILL.md được gửi từ máy chủ, còn MCP Resources tương ứng với /docs được gửi từ máy chủ
Giá trị ở cấp tổ chức của MCP Prompts và Resources
- Nội dung động: các tệp
*.md trong repository là tệp tĩnh cần cập nhật thủ công, nhưng prompt và resource dựa trên máy chủ có thể được tạo động theo thời gian thực
- Có thể tiêm động các tài liệu chỉ hữu ích trong một ngữ cảnh cụ thể, dữ liệu giá, trạng thái hệ thống hiện tại... mà không cần gọi công cụ
- Cập nhật tự động để duy trì nhất quán: các tệp
*.md được phân phối qua repository hay package cần đồng bộ, nhưng nếu được truyền qua MCP prompt thì luôn ở trạng thái mới nhất
- Ngay cả tài liệu chính thức của bên thứ ba cũng có thể được proxy qua máy chủ, không cần sao chép và cập nhật thủ công vào repository
- Chia sẻ tri thức trên toàn tổ chức: có thể phân phối nhất quán nội dung áp dụng cho toàn tổ chức như bảo mật, best practice về telemetry, các lưu ý khi triển khai hạ tầng tới mọi repository, mọi workflow, mọi frontend tác tử (Claude Code, Codex, VS Code Copilot, GitHub Agents, OpenCode, v.v.)
- Trong môi trường microservice, một nhóm có thể cần truy cập tài liệu của dịch vụ khác, hoặc nhóm phụ trách dịch vụ có thể cung cấp kỹ năng động mỗi lần triển khai
- Đã có các trường hợp MCP prompt và resource thực sự hoạt động trong OpenCode, Claude Code CLI..., và chỉ với cấu hình client MCP là không cần quản lý bổ sung sau khi triển khai
Kết luận: ở cấp độ tổ chức, MCP là hiện tại và tương lai
- Sáu tháng trước MCP là chủ đề nóng nhất, còn hiện tại bị chỉ trích là thủ phạm gây phình ngữ cảnh, nhưng những đánh đổi và cạm bẫy tương tự của CLI tùy biến lại đang bị bỏ qua
- Khi đội ngũ bắt đầu suy nghĩ về cách chuyển từ vibe coding sang agentic engineering, họ sẽ tự nhiên đi đến thiết kế và sứ mệnh của MCP
- Như trường hợp gần đây của bộ phận Amazon AWS (yêu cầu kỹ sư cấp cao phê duyệt các thay đổi có hỗ trợ AI) cho thấy, cuối cùng các nhóm vẫn phải vận hành và bảo trì những hệ thống phần mềm do tác tử AI tạo ra
- Lời khuyên của Garry Tan hay Andrew Ng có thể đúng trong môi trường đồng nhất của cá nhân, nhưng khó áp dụng nguyên xi trong môi trường tổ chức nơi các nhóm với trình độ và kinh nghiệm khác nhau phải hội tụ về chất lượng nhất quán
- Muốn phát hành phần mềm đáng tin cậy và có thể bảo trì, cần có kỷ luật kỹ thuật để bảo đảm tính nhất quán, bảo mật, chất lượng và độ chính xác; và vì thế MCP là công cụ phù hợp cho tổ chức và doanh nghiệp ở thời điểm hiện tại
6 bình luận
CLI là công cụ cục bộ, còn MCP là máy chủ, nên mục đích sử dụng rất khác nhau.
Nếu chạy CLI trên máy chủ thì chẳng phải cũng như nhau sao?
MCP hồi sinh từ cõi chết!
Tài liệu liên quan: MCP đã chết. CLI muôn năm
Mình mong là các cuộc thảo luận về một kiểu tính năng sandbox CLI để có thể dùng công cụ CLI ngay cả trên ứng dụng di động sẽ tiếp tục phát triển hơn nữa; khi thực sự cố gắng làm cho thiết bị di động tương thích, có vẻ như nút thắt cổ chai cuối cùng vẫn là vấn đề sandboxing.
Ý kiến trên Hacker News
Tôi có cảm giác phần lớn các tính năng tích hợp AI ra mắt dạo này đều được thiết kế khá cẩu thả
Trong khi ngay cả những lệnh cơ bản còn chưa được chuẩn hóa, thứ tràn ngập lại là tài liệu hướng dẫn thiếu chính xác do LLM tạo ra thay vì tài liệu thật
Rốt cuộc, những thứ được gọi là “tiêu chuẩn AI” có lẽ sẽ cứ liên tục xuất hiện rồi biến mất. LLM về bản chất là dựa trên văn bản nên khó vận hành chính xác như các giao thức mạng. Kiểu kỹ thuật lấy văn bản làm trung tâm này cuối cùng sẽ tạo ra một kim tự tháp trừu tượng đầy bất ổn
Trong các công cụ AI, thứ hữu ích nhất theo tôi là cấu trúc bọc tác tử xác suất bằng một cổng quyết định
Vì vậy tôi dùng MCP trên HTTP. Ví dụ, NanoClaw tăng cường bảo mật bằng cách lọc tin nhắn WhatsApp một cách quyết định và làm proxy cho API key. Cấu trúc kiểu này khiến AI đáng tin hơn
Cấu trúc này có tính bảo mật và khả năng quản trị cao, đồng thời còn có thể tự động tạo CLI từ danh mục công cụ
Có thể xem ví dụ triển khai tại smith-gateway
Phần lõi mã nguồn mở có thể xem tại tenuo
MCP tách bạch rõ ràng giữa việc ra quyết định của AI và việc thực thi mang tính quyết định của hệ thống. Tôi dùng Claude Code cùng máy chủ MCP; AI lo phần giải quyết vấn đề mang tính sáng tạo còn việc thực thi đi theo lộ trình có thể dự đoán được, nên rất hiệu quả
MCP là một đặc tả giao thức cố định cho giao tiếp giữa các ứng dụng AI
Thay vì gượng ép buộc API giữa các ứng dụng lại với nhau như cách “integration” truyền thống, nó cung cấp một lớp trừu tượng giao tiếp có thể tái sử dụng như HTTP·FTP·SMTP
Tôi nghĩ nếu AI muốn tương tác với nhiều dịch vụ khác nhau thì cần một ngôn ngữ chung như vậy
Có thể xem đặc tả tại modelcontextprotocol.io/specification/2025-11-25
Thứ thực sự cần không phải là giao thức mới mà là đặc tả CLI hoặc API có thể được khám phá dần dần. Họ cho rằng MCP chỉ là biện pháp tạm thời từ thời các tác tử ban đầu chưa thể chạy CLI
Đây là góc nhìn cho rằng MCP rốt cuộc chỉ là giải pháp tạm thời cho sự non nớt của công nghệ
Khi MCP mới xuất hiện, tôi đã bỏ qua vì nó trông như một thứ rác được thiết kế quá tay
Đến giờ tôi vẫn không thấy hối tiếc. LangChain cũng vậy. Thấy phổ biến rồi chạy theo là rất nguy hiểm
Chỉ cần đầu tư rất ít thời gian cũng có thể thu được hiệu quả lớn
Đôi khi công cụ thô ráp lại sống sót vì nó đơn giản hóa được những bài toán tích hợp phức tạp
Nếu ngay từ đầu đã bỏ qua chỉ vì nó xấu xí, về sau có thể sẽ bỏ lỡ cơ hội khi nó trở thành hạ tầng tiêu chuẩn
Theo đánh giá này, nó không phải thiết kế quá tay mà là một cấu trúc rõ ràng và trực quan
Remote MCP khá ổn ở chỗ xác thực được xử lý tự động nên việc truy cập dịch vụ trở nên thuận tiện
Nhưng so với tổ hợp CLI + Skills thì nó có gánh nặng ngữ cảnh (context bloat) lớn hơn, đồng thời làm mất các ưu điểm của Unix CLI như xử lý pipeline hay đầu vào heredoc
CLI có thể tự động tạo skill từ đầu ra
--help, nên rất hiệu quảMCP cần tiến trình chạy liên tục, còn CLI thì chỉ chạy khi cần
Tôi vẫn nghĩ MCP là một lớp thừa không cần thiết
Tôi đồng ý rằng CLI > MCP, nhưng các lợi ích về tài liệu hóa và tập trung hóa vẫn có thể giải quyết bằng cách khác
Ví dụ, dùng Skills có thể chứa hướng dẫn cho cả CLI lẫn API và chỉ tải khi cần
Những ưu điểm của MCP tập trung hóa thực ra cũng hoàn toàn có thể triển khai bằng proxy sẵn có hoặc AWS SSO
Rốt cuộc tôi cho rằng tốt hơn là dùng Skills để tài liệu hóa, còn tương tác thực tế thì xử lý bằng CLI hoặc REST API
Người ta cho rằng nội dung của Skills rốt cuộc vẫn được đưa vào ngữ cảnh và gây tải, và proxy không thể thay thế hoàn toàn chức năng của MCP
MCP có thể kích hoạt prompt và tài nguyên bằng lệnh
/và tham chiếu@, điều mà proxy không làm đượcCó thể xem demo liên quan ở các ảnh .gif cuối bài và đặc tả MCP
Tôi cảm thấy MCP phù hợp hơn với môi trường tiêu dùng
Trong môi trường phát triển nó phức tạp và kém hiệu quả, nhưng với người dùng phổ thông, thông qua MCP, họ có thể dễ dàng hiểu mô hình có thể thực hiện những chức năng gì
Không cần thiết lập môi trường, và trong GUI cũng có thể trực quan hóa phản hồi như Siri hay Google Assistant
Ở vị trí cung cấp công cụ AI cho người dùng không phải lập trình viên trong doanh nghiệp, cách tiếp cận MCP tập trung đã rất hữu ích
Có thể quản lý nhất quán giọng điệu thương hiệu, thuật ngữ nội bộ, truy cập dữ liệu dùng chung và ngữ cảnh theo miền
Thông qua phương thức resource của MCP, có thể cung cấp “skills” đã được chuẩn hóa và kiểm soát mẫu kết nối dữ liệu
Tác giả xem xét nhiều khái niệm từ nhiều góc độ, nhưng có vẻ không biết đến những khái niệm đã tồn tại như Token Notation(TOON)
Nó tạo cảm giác như thể tác giả đang mong những thứ như vậy tồn tại
Vấn đề thật sự của MCP là gánh nặng bảo trì
Ví dụ, nếu cần tích hợp GitHub thì thay vì dùng API đã được tài liệu hóa tốt, lại phải phụ thuộc vào một wrapper npm
Tôi chỉ dùng
ghCLI hoặccurl. Nếu API thay đổi, tác tử sẽ đọc tài liệu mới rồi tự thích nghiVới MCP, phải chờ đến khi lớp wrapper ở giữa được cập nhật
Lập luận về bảo mật cũng đầy mâu thuẫn — ban đầu nó ra mắt không có xác thực nhưng giờ lại lấy bảo mật làm ưu điểm
Trên thực tế, đây là vấn đề mà các cách cũ như chroot hay scoped token đã giải quyết từ lâu
Điểm duy nhất MCP thực sự có lợi là OAuth flow cho người không phải lập trình viên. Còn với công cụ cho lập trình viên, tôi nghĩ tốt hơn là cứ làm CLI tốt hơn