MCP đã chết. CLI muôn năm

 (ejholmes.github.io)
36 điểm bởi GN⁺ 2026-03-02 | 8 bình luận | Chia sẻ qua WhatsApp
  • MCP đang nhanh chóng mất sức hút trong ngành, và giờ đây cách tiếp cận dựa trên CLI thực tế hơn
  • LLM vốn đã rất thành thạo trong việc sử dụng công cụ dòng lệnh, nên chỉ với tài liệu và CLI, chúng đã có thể hoàn thành công việc mà không cần giao thức riêng
  • CLI cho phép cả con người lẫn LLM chạy và debug trong cùng một môi trường, giúp việc xác định nguyên nhân sự cố trở nên đơn giản
  • Xét về khả năng kết hợp (composability), cơ chế xác thực và độ ổn định, CLI hiệu quả hơn MCP và cũng dễ bảo trì hơn
  • MCP gây ra ma sát liên tục trong thực tế như khởi tạo thiếu ổn định, phải xác thực lại lặp đi lặp lại, và thiếu kiểm soát quyền hạn
  • Trong đa số trường hợp, CLI là lựa chọn đơn giản và đáng tin cậy hơn, và các công ty nên ưu tiên cung cấp API và CLI hơn là xây dựng máy chủ MCP

Giới hạn của MCP và ưu thế của CLI

  • Sau khi Anthropic công bố Model Context Protocol (MCP), ngành này đã đua nhau xây dựng máy chủ MCP, nhưng các công cụ lớn như OpenClaw và Pi không hỗ trợ nó, và lợi ích thực tế cũng không rõ ràng
    • LLM vốn đã có thể hoàn thành công việc thông qua CLI và tài liệu
    • MCP bổ sung endpoint và cơ chế xác thực mới, nhưng lại trùng lặp với các chức năng hiện có
  • LLM được tối ưu để sử dụng công cụ CLI và làm điều đó rất thành thạo
    • Chúng đã học từ hàng triệu man page, câu trả lời trên Stack Overflow, và shell script trên GitHub
    • Ví dụ, nếu yêu cầu Claude chạy lệnh như gh pr view 123, nó sẽ thực hiện đúng như vậy
  • MCP hứa hẹn một giao diện gọn gàng hơn, nhưng trên thực tế vẫn phải tài liệu hóa y hệt phần mô tả công cụ, tham số và thời điểm sử dụng của từng công cụ

CLI cũng hữu ích với con người

  • CLI cho phép con người và LLM cùng chia sẻ một bộ lệnh giống nhau
  • Khi Jira có hành vi ngoài dự kiến, có thể trực tiếp chạy lại cùng lệnh jira issue view để tái hiện sự cố
  • Với MCP, công cụ chỉ tồn tại bên trong cuộc hội thoại của LLM, nên khi có vấn đề xảy ra, bạn phải lục lại log JSON được gửi đi, rất phiền phức
  • Việc debug không nên đòi hỏi một bộ giải mã giao thức
  • CLI có đầu vào và đầu ra rõ ràng nên dễ lần theo nguyên nhân hơn

Khả năng kết hợp (Composability)

  • CLI có thể kết hợp theo pipeline với jq, grep, chuyển hướng file, v.v.
  • Ví dụ phân tích một Terraform plan quy mô lớn:
    • terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
  • Với MCP, либо phải dump toàn bộ plan vào context window (tốn chi phí và thường không khả thi), hoặc phải tự triển khai logic lọc tùy chỉnh ngay trong máy chủ MCP
  • Cách làm bằng CLI tận dụng các công cụ đã tồn tại, được tài liệu hóa đầy đủ, và cả con người lẫn agent đều có thể hiểu được

Vấn đề xác thực (Auth)

  • MCP quá áp đặt một cách không cần thiết trong cách xử lý xác thực
  • Các công cụ CLI đã sử dụng những cơ chế xác thực được kiểm chứng: aws dùng profile và SSO, gh dùng gh auth login, kubectl dùng kubeconfig
  • Dù là con người dùng trực tiếp hay Claude chạy giúp, luồng xác thực vẫn giống hệt nhau
  • Khi có sự cố xác thực, có thể xử lý bằng các cách sẵn có như aws sso login, gh auth refresh, không cần troubleshooting riêng cho MCP

Vấn đề vận hành: không có bộ phận chuyển động (No Moving Parts)

  • Máy chủ MCP cục bộ đòi hỏi phải khởi chạy và duy trì một tiến trình riêng, và trong Claude Code nó được tạo thành tiến trình con nên đôi khi phát sinh lỗi
  • Công cụ CLI chỉ đơn giản là các file nhị phân trên đĩa, không cần tiến trình nền, quản lý trạng thái hay thủ tục khởi tạo

Những bất tiện trong công việc thực tế

  • Khởi tạo thiếu ổn định: máy chủ MCP không khởi động được khiến việc phải khởi động lại Claude Code diễn ra thường xuyên, rồi phải xóa trạng thái và thử lại
  • Xác thực lại lặp đi lặp lại: khi dùng nhiều công cụ MCP, phải xác thực từng cái; trong khi với CLI dùng SSO hoặc thông tin xác thực có thời hạn dài, vấn đề này không xảy ra
  • Kiểm soát quyền hạn thô sơ: trong Claude Code có thể cho phép công cụ MCP theo tên, nhưng không thể giới hạn chỉ đọc hoặc ràng buộc phạm vi tham số
    • Với CLI có thể kiểm soát quyền chi tiết hơn, chẳng hạn cho phép gh pr view nhưng yêu cầu phê duyệt với gh pr merge

Khi nào MCP vẫn hợp lệ

  • MCP có thể phù hợp khi hoàn toàn không có công cụ tương đương CLI
  • Vẫn thừa nhận giá trị của MCP như một giao diện chuẩn hóa, và khả năng tồn tại những use case mà MCP phù hợp hơn CLI
  • Tuy nhiên, trong phần lớn công việc, CLI vẫn đơn giản hơn, debug nhanh hơn và đáng tin cậy hơn

Bài học cốt lõi và lời nhắn gửi tới các builder

  • Công cụ tốt nhất là công cụ hoạt động cho cả con người lẫn máy móc, và CLI đã trải qua hàng chục năm lặp lại trong thiết kế để trở nên dễ kết hợp, dễ debug và tích hợp với các hệ thống xác thực sẵn có
  • MCP cố tạo ra một tầng trừu tượng tốt hơn, nhưng thực ra một tầng trừu tượng đủ tốt đã tồn tại từ trước
  • Những công ty đang đầu tư vào máy chủ MCP mà lại không có CLI chính thức nên xem lại chiến lược, và nếu cung cấp theo thứ tự
    API tốt → CLI tốt, thì agent sẽ tự biết cách tận dụng
  • Có thể giảm bớt độ phức tạp giao thức không cần thiết và cải thiện năng suất lẫn khả năng bảo trì

Bài viết liên quan

8 bình luận

 
sonnet 2026-03-03

Không phải là MCP không có lợi ích, mà là chúng ta đã tỉnh ra khỏi ảo tưởng về việc dùng nó một cách bừa bãi cho những mục đích vốn không có lợi ích từ MCP. Ngay cả khi mở microservice cho LLM thì cũng đâu phải sẽ dùng CLI, vì MCP là một giao thức "API".
 
brainer 2026-03-03

Lúc đó cứ dùng API là được. Thực ra lý do từng dùng MCP là vì giới hạn của long context, nhưng giờ thì phần lớn giới hạn đó đã được khắc phục rồi.
 
jamsya 2026-03-03

Hoàn toàn đồng cảm mạnh mẽ.
Ngay cả khi không cài aws mcp, Claude Code vẫn tự biết lấy những thứ cần thiết bằng AWS CLI luôn 😂
 
GN⁺ 2026-03-02
Ý kiến trên Hacker News

  • Tôi đã cố tránh nói điều này suốt một thời gian dài, nhưng giờ thì tôi tin chắc rằng MCP không có lợi thế thực chất nào
    Tôi đang vận hành các AI agent điều khiển toàn bộ workflow phát triển của mình bằng lệnh shell, và ngay cả khi lần đầu thấy các cờ CLI, chúng vẫn hiểu khá tốt chỉ nhờ đầu ra của --help
    Trong khi đó, các máy chủ MCP lúc nào cũng thiếu ổn định và cần được quản lý
    CLI có thể được kết hợp bằng jq, grep, chuyển hướng tệp, v.v., còn MCP thì bị bó buộc trong định dạng mà máy chủ trả về
    Cuối cùng, tôi nghĩ việc chấp nhận MCP chỉ là một tín hiệu marketing kiểu ‘AI-first’ hơn là vì lý do kỹ thuật

    • MCP tăng trưởng bùng nổ trong năm 2024, nhưng đến đầu năm 2025, khi terminal agent (Claude Code) xuất hiện, tôi cho rằng cục diện đã thay đổi rất nhanh
    • Tôi thì ngược lại, tôi thích MCP hơn. So với CLI, xử lý lỗi và gỡ lỗi sạch sẽ hơn nhiều, và có thể hạn chế các cờ nguy hiểm hoặc chia kết quả theo kiểu phân trang
      Có thể hiểu MCP đơn giản như một lớp wrapper, giống REST hay gRPC
    • Tôi cũng tránh MCP. Tôi đã thử JIRA MCP và nó rất tệ. Thay vào đó, để LLM gọi API trực tiếp và viết script thì hiệu quả hơn hẳn
      Hiện tại tôi nghĩ công cụ CLI cho LLM đang ở đỉnh cao
    • Công ty chúng tôi dùng MCP để phơi bày các công cụ chỉ có trên web như wiki nội bộ, để Claude có thể trực tiếp tra cứu log và metric
      Tuy vậy, việc kết quả MCP lúc nào cũng đi vào context window là khá bất tiện. Sẽ tốt hơn nếu có thể dump ra filesystem
    • Máy chủ MCP có vẻ như là sản phẩm chuyển tiếp được tạo ra khi LLM còn chưa phát triển đầy đủ. Tôi nghĩ huấn luyện bằng dữ liệu CLI sẽ tốt hơn nhiều

  • MCP giống như một black-box API có thể gọi ngay mà không cần cài đặt hay cấp phát tài nguyên
    Ngược lại, CLI có thể truy cập môi trường cục bộ nên chính xác hơn nhiều
    Tôi dùng jq, duckdb CLI để lấy mẫu các tệp dữ liệu lớn, và Opus 4.6 tự động điều chỉnh truy vấn trong lúc khám phá
    CLI có khả năng phản hồi thời gian thực rất tốt, nên đặc biệt hữu ích cho phân tích dữ liệu khám phá
    Những CLI tôi hay dùng gồm showboat, br, psql, roborev, v.v.

    • Tôi cũng có trải nghiệm tương tự. Văn bản đầu vào/đầu ra của CLI là thứ phù hợp nhất với cách LLM được huấn luyện
      Tôi đã rất thích dùng duckdb với ChatGPT, nhưng không biết bạn có đặt system prompt để nó duy trì DB cục bộ hay không
    • Thay vì CLI, có thể chạy lệnh trong container Docker để tránh các vấn đề cài đặt. Có lẽ cũng có thể tạo một “skill” để tự động hóa cách tiếp cận này
    • Là người không dùng tiếng Anh bản ngữ, tôi thấy cách dùng số nhiều như MCPs khá thú vị

  • MCP có ý nghĩa khi cần khám phá những công cụ không có trên CLI và gọi chúng theo ngữ cảnh
    Ví dụ, echomindr do tôi tạo ra cung cấp một DB trích xuất các quyết định của nhà sáng lập từ podcast thông qua MCP
    Khi Claude nhận câu hỏi liên quan đến startup, nó sẽ tìm kiếm trải nghiệm thực tế của các nhà sáng lập để trả lời
    CLI phù hợp khi con người đã biết mình sẽ dùng công cụ nào, còn MCP phù hợp cho việc chọn công cụ theo hướng khám phá

  • Có vẻ tác giả chỉ nhìn việc dùng AI từ góc độ nhà phát triển
    Phần lớn người dùng sử dụng LLM qua giao diện dựa trên web như ChatGPT
    Ở góc độ doanh nghiệp, MCP phù hợp hơn nhiều để kết nối các công cụ marketing, sales và quản lý dự án

  • Bản thân MCP không tệ, nhưng stdio MCP bị thiết kế quá mức
    Thay vào đó, cách làm Streamable HTTP + OAuth Discovery hiện là phương pháp tích hợp AI hiệu quả nhất
    Ví dụ, Sentry MCP cho phép xác thực và truy cập dữ liệu chỉ với một URL duy nhất
    Vấn đề nằm ở cách triển khai MCP. Thay vì gọi bằng bash, nếu phơi bày MCP thành HTTP endpoint thì nó sẽ hoạt động linh hoạt hơn nhiều

    • Dù là CLI hay MCP thì hệ thống quyền hạn đều phải được thiết kế nhất quán ở cấp API. Phần Streamable HTTP cần được giải thích thêm
    • Tôi cũng cùng quan điểm. Xác thực và telemetry tập trung đơn giản hơn nhiều. Tuy nhiên, chỉ nên dùng đúng chỗ

  • Một số khách hàng của tôi không có máy chủ MCP, nhưng các nhà phát triển lại yêu cầu điều đó
    Cuối cùng tôi phải xuất Postman API sang JSON để cung cấp, nhưng các nhà phát triển vẫn muốn có máy chủ MCP
    Thực tế là việc có hỗ trợ MCP hay không đang hoạt động như một checklist marketing

  • Blog này có vẻ thiên quá nhiều về góc nhìn của nhà phát triển
    Khi kết nối với các công cụ hay dịch vụ dành cho người không phải developer, MCP tự nhiên hơn nhiều

    • Đúng vậy. Trong giao diện chat thì không thể chạy CLI, và các dịch vụ cho người không phải developer cũng vốn không có CLI
    • Tôi cũng từng thắc mắc liệu có thể chạy CLI trong các giao diện web/mobile như ChatGPT hay LeChat hay không
    • Các giao diện dành cho người không phải developer đã và đang tiến hóa theo các dạng như OpenClaw, Claude Cowork

  • Những tin tuyển dụng kiểu “cần người có 5 năm kinh nghiệm MCP” rốt cuộc đã trở thành một meme vô nghĩa

  • Một trong những lý do CLI tốt hơn MCP là vì nó có định dạng được tối ưu theo lý thuyết thông tin
    Đầu ra của các công cụ Unix sắp xếp thông tin liên quan ở gần nhau, nên cơ chế attention của LLM hoạt động hiệu quả hơn
    JSON thì dễ parse nhưng lại bất tiện để đọc và suy luận
    Định dạng CLI trực quan cho cả con người lẫn LLM
    Tham khảo liên quan: Entropy and Information Layout

  • So sánh MCP với CLI giống như so sánh OpenAPI với chuỗi (JSON)
    MCP được định nghĩa một cách hình thức, còn CLI là một giao diện trừu tượng ở mức (String, List String, Map Int Stream) -> PID
    Suy cho cùng, cả hai đều chỉ là API; điều quan trọng là chọn đúng công cụ để đạt được mục tiêu

    • Nhưng CLI cung cấp tài liệu đầy đủ qua --help, nên nếu LLM có thể hiểu được điều đó thì khó nói việc chuẩn hóa theo MCP là tốt hơn
    • Trải nghiệm sử dụng thực tế quan trọng hơn lý thuyết. Nếu muốn nói MCP và CLI là như nhau, hãy tạo một ví dụ cho thấy Playwright CLI và MCP có cùng mức dùng token và khả năng cấu hình
      Nếu không, bạn sẽ trực tiếp cảm nhận được rằng trong thực tế hai cách tiếp cận này khác nhau thế nào
 
develosopher 2026-03-03

Nếu ai đó đang phát triển một SaaS và cân nhắc giữa CLI và MCP để tích hợp AI, thì có lẽ họ sẽ chọn MCP trước. Hỗ trợ CLI đồng nghĩa với việc tăng thêm các điểm cần quản lý. Hai bên có thể cùng tồn tại, nhưng có lẽ CLI sẽ không biến mất.
 
hanje3765 2026-03-03

Có vẻ như khi trí tuệ của LLM tăng lên, sự cần thiết của MCP trở nên mơ hồ hơn.
Bản thân tôi cũng thực sự cảm thấy như vậy.
 
m00nlygreat 2026-03-03

Có vẻ như đang được sắp xếp thành: thực thi từ xa là mcp, còn thực thi cục bộ là skills.
 
hulryung 2026-03-03

Tôi cũng đã bắt đầu tự tạo và dùng công cụ trực tiếp bằng CLI thay vì MCP.