MCP đã chết chưa?

 (quandri.io)
1 điểm bởi GN⁺ 5 giờ trước | 2 bình luận | Chia sẻ qua WhatsApp
  • MCP kết nối LLM với các công cụ bên ngoài, nhưng trong workflow phát triển, chi phí context, độ ổn định vận hành và sự trùng lặp với CLI/API đã trở thành gánh nặng lớn
  • Theo đo lường của Quandri, 77 định nghĩa công cụ của Linear, Notion, Slack và Postgres chiếm khoảng 21.077 token, tương đương 10,5% context 200K của Claude
  • Với việc tra cứu issue trên Linear, cách dùng MCP tiêu tốn khoảng 12.957 token vì luôn phải mang theo 42 định nghĩa công cụ, lớn hơn rất nhiều so với cách dùng CLI chỉ khoảng 200 token
  • MCP đòi hỏi tiến trình server riêng cùng các vấn đề như xác thực, khởi tạo, xung đột và độ trễ round-trip ra bên ngoài, trong khi CLI/API dễ tái hiện, debug và kết hợp hơn trong terminal
  • Quandri đã bọc CLI hiện có bằng Skills để lấy lại khoảng 21K token, và chỉ dùng MCP khi không có CLI hoặc khi cần kiểm soát quyền ở cấp độ nhóm

Chi phí cốt lõi mà MCP bộc lộ

  • MCP (Model Context Protocol) kết nối LLM với các công cụ bên ngoài như GitHub, Linear, Notion, Slack, nhưng trong workflow phát triển thực tế, mức sử dụng context, độ ổn định vận hành và sự chồng chéo với CLI/API hiện có trở thành những vấn đề chính
  • Sau khi ra mắt vào cuối năm 2024, nó được gọi là “USB-C của hệ sinh thái AI”, nhưng với các lập trình viên dùng hằng ngày thì những chi phí khác lại lộ ra trước tiên
  • Kể từ thời điểm đo lường, Claude Code đã giới thiệu Tool Search with Deferred Loading, cho phép nạp schema công cụ MCP khi cần và giảm hơn 85% mức sử dụng context
  • Hiện tại trong Claude Code, vấn đề phình to context đã được giảm nhẹ đáng kể, nhưng các vấn đề về hiệu năng, debug và kiến trúc vẫn còn tồn tại

Tiêu tốn lớn cửa sổ context

  • Cửa sổ context là không gian LLM dùng để xử lý công việc, và khi kết nối MCP server, chỉ riêng các định nghĩa công cụ cũng đã chiếm một phần lớn thay vì nội dung công việc thực tế
  • Khi trích xuất và đo các định nghĩa công cụ thực tế từ các MCP server được kết nối trong môi trường Quandri, kết quả cho thấy chỉ riêng việc kết nối đủ 4 server đã dùng 10,5% cửa sổ context chỉ cho định nghĩa công cụ
  • Kích thước định nghĩa công cụ:
    • Linear: 42 công cụ, khoảng 51.229 ký tự, khoảng 12.807 token
    • Notion: 14 công cụ, khoảng 16.156 ký tự, khoảng 4.039 token
    • Slack: 12 công cụ, khoảng 15.168 ký tự, khoảng 3.792 token
    • Postgres: 9 công cụ, khoảng 1.755 ký tự, khoảng 438 token
    • Tổng cộng: 77 công cụ, khoảng 84.308 ký tự, khoảng 21.077 token
  • Mức sử dụng context theo từng model:
    • Với context 200K của Claude, định nghĩa công cụ chiếm 10,5%
    • Với context 128K của GPT-4o, định nghĩa công cụ chiếm 16,5%
  • Chỉ riêng Linear cũng luôn nạp 42 định nghĩa công cụ, chiếm hơn khoảng 12.800 token, và ngay cả khi thực tế chỉ dùng get_issue và save_issue thì toàn bộ định nghĩa vẫn được mang vào cùng lúc
  • Ví dụ về các định nghĩa công cụ lớn:
    • linear/save_issue: 2.479 ký tự, khoảng 619 token
    • slack/search_public: 1.614 ký tự, khoảng 403 token
    • linear/list_issues: 1.588 ký tự, khoảng 397 token
    • notion/fetch: 1.379 ký tự, khoảng 344 token
    • slack/send_message: 1.248 ký tự, khoảng 312 token

Gánh nặng về độ ổn định vận hành và hiệu năng

  • MCP phải khởi động và duy trì một tiến trình riêng nên có thể phát sinh lỗi khởi tạo và các vấn đề xác thực lặp đi lặp lại
  • Mỗi lần gọi công cụ đều cần round-trip đến server bên ngoài nên tốc độ phản hồi của AI chậm hơn
  • Nếu tiến trình MCP server bị crash, công cụ có thể biến mất giữa chừng trong phiên làm việc
  • Rất khó thấy rõ từng công cụ thực sự có những quyền gì, nên khả năng quan sát quyền hạn thấp
  • Trong benchmark Jira MCP của MCP is dead. Long live the CLI, MCP chậm gấp 3 lần mỗi lần gọi so với gọi trực tiếp REST API, còn lần gọi đầu tiên tính cả khởi tạo thì chậm gấp 9,4 lần
  • Chênh lệch hiệu năng này không chỉ giới hạn ở Jira, mà xuất phát từ kiến trúc thêm vào một lớp tiến trình là MCP server giữa LLM và API gốc
  • Phần overhead tương tự cũng áp dụng cho các server Linear, Notion và Slack trong stack của Quandri

Bị trùng lặp với CLI/API hiện có

  • CLI/API cho phép con người và LLM dùng cùng một lệnh, trong khi MCP chỉ tồn tại bên trong hội thoại với LLM
  • CLI/API có thể kết hợp tự do với pipe, jq, grep, trong khi MCP bị ràng buộc vào định dạng do server trả về
  • CLI/API có thể tái hiện và debug ngay trong terminal, còn MCP chỉ có thể tái hiện trong context hội thoại
  • LLM đã học cách dùng CLI/API thông qua man page và StackOverflow, còn MCP cần các định nghĩa công cụ riêng
  • CLI/API phần lớn đã được cài sẵn, còn MCP cần thêm cấu hình server, xác thực và quản lý tiến trình

Chi phí token khi tra cứu issue trên Linear

  • Khi tra cứu cùng một issue trên Linear, cách dùng MCP tiêu tốn token nhiều hơn khoảng 65 lần so với CLI
  • Cách dùng CLI tiêu tốn khoảng 200 token:
    • Prompt lệnh curl: khoảng 50 token
    • Phản hồi: khoảng 150 token
  • Cách dùng MCP tiêu tốn khoảng 12.957 token:
    • 42 định nghĩa công cụ Linear luôn được nạp: khoảng 12.807 token
    • Lời gọi công cụ và phản hồi: khoảng 150 token
  • Ví dụ CLI dưới đây gọi trực tiếp Linear GraphQL API:
curl -s -H "Authorization: Bearer $LINEAR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' \
  https://api.linear.app/graphql

Phương án thay thế: chiến lược ưu tiên CLI và Skills

  • Cách tiếp cận cung cấp theo thứ tự CLI → API → tài liệu nhẹ hơn và trực tiếp hơn
  • Vì LLM đã học cách dùng CLI từ man page và StackOverflow, nên không cần lúc nào cũng mang theo các định nghĩa công cụ riêng
  • Dùng trực tiếp CLI hiện có sẽ không lãng phí context cho định nghĩa công cụ, đồng thời con người và AI dùng cùng một interface nên việc debug dễ hơn
  • Có thể kết hợp tự do với các lệnh khác thông qua pipeline
  • Nếu MCP giống như “trải sẵn toàn bộ menu lên bàn ăn”, thì Skills giống với “chỉ nhờ thủ thư lấy đúng cuốn sách cần thiết” hơn
  • MCP nạp tất cả định nghĩa công cụ ngay khi kết nối và luôn chiếm chỗ trong context, còn Skills chỉ được nạp khi cần và chỉ chiếm context trong lúc sử dụng
  • Số lượng server càng tăng thì áp lực context của MCP càng lớn, trong khi Skills không chiếm context thường trực chỉ vì số skill nhiều hơn
  • Điểm cốt lõi là đưa hướng dẫn dùng CLI vào trong Skills, và khi kết hợp với chiến lược ưu tiên CLI thì đây là cách hiệu quả nhất
  • Ví dụ Linear Skill chỉ bao gồm URL API, cách xác thực, lệnh curl để tra cứu issue, cách truy vấn GraphQL và hướng dẫn parse JSON bằng jq:
# Linear Issue Lookup Skill  
- Linear API: https://api.linear.app/graphql  
- Auth: Bearer Token ($LINEAR_TOKEN env var)  
- Get issue: curl -s -H "Authorization: Bearer $LINEAR_TOKEN" -H "Content-Type: application/json" -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' https://api.linear.app/graphql  
- Search issues (GraphQL): adjust the query field for JQL-like filtering  
- Results are JSON, parse with jq
  • Với cách này, LLM chỉ nạp phần nội dung trên vào context khi gọi đúng skill đó
  • Không cần lúc nào cũng mang theo 42 định nghĩa công cụ của Linear, mà chỉ cần nạp đúng các lệnh CLI cần thiết

Khi nào MCP vẫn còn phù hợp

  • Khi dịch vụ không có CLI, MCP có thể là cách kết nối duy nhất
  • Với người dùng không phải lập trình viên không dùng terminal, MCP có thể dễ tiếp cận hơn
  • Trong các trường hợp giao tiếp hai chiều theo thời gian thực vượt ra ngoài mô hình request-response đơn giản, MCP có thể phù hợp

Tiêu chí chọn cách truy cập cơ sở dữ liệu

  • Truy cập cơ sở dữ liệu suy cho cùng là thực thi truy vấn, và LLM vốn đã biết khá tốt SQL cũng như truy vấn MongoDB
  • Nếu đưa thông tin DB và cách dùng CLI vào Skill cùng với schema, LLM có thể viết truy vấn mà không cần MCP
  • Ví dụ Postgres Skill chỉ bao gồm host, schema bảng và cách dùng psql CLI:
# Postgres Skill  
- Host: postgres://localhost:5432/myapp  
- Tables: users (id, name, email), orders (id, user_id, status)  
- CLI: psql -h localhost -d myapp -c "SELECT * FROM users WHERE ..."
  • Với cơ sở dữ liệu, MCP cũng có những ưu điểm riêng:
    • An toàn truy vấn: MCP server có thể ép chế độ chỉ đọc và chặn các truy vấn nguy hiểm ở cấp server
    • Bảo vệ thông tin xác thực: cách dùng CLI có thể làm lộ chuỗi kết nối trong prompt, trong khi MCP server quản lý thông tin xác thực ở bên trong
  • Với môi trường phát triển cục bộ hoặc DB cá nhân, Skills + CLI nhẹ hơn, nhanh hơn và dễ phục hồi sau sai sót
  • Với DB production hoặc môi trường chia sẻ trong nhóm, MCP phù hợp hơn vì các cơ chế an toàn như kiểm tra truy vấn và kiểm soát truy cập ở cấp server là rất quan trọng
  • Trong phần lớn workflow phát triển, MCP dễ trở thành một thiết kế quá mức cần thiết

Cách Quandri sử dụng

  • Quandri kết hợp Bash + CLI, Skills và MCP tùy theo từng dịch vụ
  • Với các công cụ dùng hằng ngày như gh, psql, aws, họ dùng Bash + CLI:
    • Không tốn chi phí context
    • Tính linh hoạt cao
    • Có thể debug ngay trong terminal
  • Với các workflow lặp đi lặp lại nhiều bước như viết commit và review PR, họ dùng Skills:
    • Chỉ nạp khi được gọi
  • Với các dịch vụ không có CLI mạnh như Slack, Linear, Notion, họ dùng MCP
  • Họ cũng dùng MCP cho các trường hợp như truy cập cơ sở dữ liệu production, nơi việc xác thực theo nhóm hoặc giới hạn phạm vi quyền là quan trọng
  • Nếu đã có CLI và có thể xác thực cục bộ, cách đó thường là nhẹ nhất
  • Nếu dịch vụ không có CLI hoặc cần xác thực nhất quán trên toàn nhóm, MCP sẽ có giá trị

Kết luận và cách đo lường

  • Quan trọng hơn việc kết nối mọi thứ là dạy cho mô hình đúng cách
  • Tại Quandri, họ thay thế MCP server bằng Skills bọc quanh CLI hiện có và lấy lại khoảng 21K token context
  • Trong workflow hằng ngày, lỗi khởi tạo biến mất và việc debug vẫn được giữ trong terminal
  • Cách hiệu quả hơn là chỉ nạp đúng công cụ vào đúng thời điểm, kèm theo hướng dẫn CLI
  • MCP có thể tiếp tục tiến hóa để giải quyết những vấn đề này trong tương lai, nhưng ở thời điểm hiện tại, Skills là lựa chọn tốt hơn
  • Cách đo lường:
    • Trích xuất từng JSON schema công cụ từ các MCP server thực tế được nạp trong môi trường Claude Code
    • Đo kích thước dựa trên tên công cụ, mô tả và tham số
    • Ước lượng token dùng heuristic khoảng 1 token cho mỗi 4 ký tự
    • Ước lượng toàn bộ server được ngoại suy từ giá trị trung bình của các công cụ mẫu

Bài viết liên quan

2 bình luận

 
aer0700 3 giờ trước

Tôi nghĩ cứ chọn công nghệ phù hợp với tình huống của mình là được mà. Bảo là đã chết thì có vẻ không đúng, vì thực tế nó đã được dùng quá nhiều rồi.
 
GN⁺ 5 giờ trước
Ý kiến trên Hacker News

  • Tôi đang dẫn dắt đội ngũ tại OpenAI phụ trách ChatGPT App Store, plugin Codex và toàn bộ mảng MCP, và điều mà các bài viết kiểu “MCP đã chết” bỏ qua là việc MCP có được dùng như một giao thức truyền tải hay không thực ra gần như không quan trọng
    Lý do MCP chưa chết là vì gần như mọi công ty trên Trái Đất đều đang xây MCP server, và chúng tôi biết điều đó vì làm việc trực tiếp với họ
    Nhiều công ty trong số này không có CLI, thậm chí không có cả API bên ngoài, nhưng vẫn đang làm MCP server
    Về mặt nội bộ, hoàn toàn có thể biến mọi MCP server thành CLI, dùng code mode hoặc triển khai khám phá công cụ, nhưng đó chỉ là chi tiết triển khai; điểm cốt lõi là AI agent có thể truy cập những dịch vụ mà trước đây vốn không thể truy cập
    Có thể còn tranh cãi việc MCP với vai trò tầng giao tiếp để mô hình đối thoại trực tiếp có chết hay chưa, nhưng nói MCP đã chết với tư cách một giao thức thì hoàn toàn không đúng
    Vì tính năng dùng máy tính/trình duyệt của ứng dụng Codex nên lập luận này giờ còn yếu hơn trước, và nếu bạn chưa thử thì nó thật sự rất ấn tượng

    • Tôi nghĩ khả năng cao MCP sẽ chết
      Lý do lớn nhất là dù cách triển khai thực tế là API, web hay CLI đi nữa, nó vẫn thêm một tầng nữa cùng một con người nữa ở phía trên, nơi việc đồng bộ có thể bị phá vỡ
      AI không nên dùng một giao thức hay tập chỉ thị khác với thứ con người truy cập, hiểu và sử dụng
      Hiện tại các công ty muốn phơi bày MCP server vì đó là trào lưu, nhưng thực tế là họ dùng Claude để dựng MCP server trên API hiện có, rồi thỉnh thoảng lại bảo nó cập nhật cho khớp với tài liệu công khai
      Vì tài liệu API đã công khai sẵn và Claude Code cũng chỉ đọc tài liệu công khai trên Internet để tạo MCP server, MCP hiện giống một biện pháp lách tạm thời cho các giới hạn của mô hình hơn
    • Rốt cuộc MCP gần như chỉ là tên thương hiệu cho một “API mà mô hình ngôn ngữ lớn có thể dùng”
      Kết quả là ngay cả những công ty vốn không quá thiên về kỹ thuật cũng đang làm API để công cụ của họ không trông lỗi thời trong kỷ nguyên agent
      Tôi ủng hộ mục tiêu đó, nhưng việc có chọn thứ này làm giao thức cho mục tiêu ấy hay không là chuyện khác, và dù sao thì đây cũng đã trở thành một giao thức mà mọi người từng nghe qua và thực sự đang dùng
    • Câu “gần như mọi công ty trên Trái Đất đều làm MCP server” lại nghe đúng kiểu buồng vọng âm
    • MCP thực chất đang giải một bài toán không tồn tại, đồng thời vẫn tiêu tốn cửa sổ ngữ cảnh vốn rất quý
      Lập luận rằng không có MCP thì agent không thể truy cập dịch vụ, nói nhẹ nhất cũng là dễ gây hiểu lầm; như bài viết đã nói, chỉ với công cụ dòng lệnh và đầu vào/đầu ra của nó cũng đã truy cập được rồi
      Ngay cả xét thuần túy kỹ thuật, MCP cũng kém khả năng tổ hợp hơn công cụ dòng lệnh, và phe không coi trọng khả năng tổ hợp cuối cùng sẽ phải trả giá vì điều đó
      Nói thẳng ra thì ở đây có thiên kiến đầu tư, và việc họ đang bán MCP cho rất nhiều công ty không bác bỏ được thiên kiến ấy
      Nhìn Microsoft cũng thấy mức độ hữu ích và chiều sâu kỹ thuật bị chôn vùi đến đâu thật ra chẳng liên quan mấy, thậm chí có người còn cho là ngược lại
      Tôi nghi việc OpenAI hiện đang thúc đẩy MCP cũng phần lớn vì yếu tố tổ chức, và từ bên trong có thể khó mà thấy được điều đó
    • Nghe chuyện họ đang làm MCP ở những nơi không có CLI thì khá đáng lo
      Việc sao chép chức năng CLI hiện có để tích hợp agent tốt hơn khác với việc biến nó thành giao diện duy nhất trói mọi người vào một đặc tả mà sau này có thể bị đánh giá là tốt hơn phương án khác
      Làm vậy rồi sau này sẽ phải trả nợ MCP, và rốt cuộc có khi không làm vẫn rẻ hơn

  • Đọc bài này cứ như thể nó do AI viết vậy
    MCP về bản chất gần với JSON-RPC có thêm một vài trường đặc biệt bắt buộc phải có
    Dù có những lo ngại về JSON-RPC, vẫn cần một tầng khám phá dịch vụ để mô hình ngôn ngữ lớn có thể tích hợp
    Nó phải hoạt động ở nhiều nơi như website, ứng dụng desktop, dịch vụ backend; còn CLI chỉ là một trong những điểm chạm với các hệ thống như vậy
    Dù thay MCP bằng gì đi nữa, ngay cả khi định nghĩa giao thức giao tiếp hay các trường khám phá công cụ theo cách khác, rất có thể hình thức cuối cùng vẫn sẽ tương tự

    • Mỗi lần đọc bài về MCP tôi lại có cảm giác cả Internet hay cả HN đang lên cơn tập thể
      Người ta bảo API tốt hơn MCP, nhưng MCP đơn giản chỉ là API có gắn thêm chút chỉ dẫn để AI có thể tự khám phá cách dùng
      Cũng có người bảo hãy dùng CLI, nhưng tôi không rõ chính xác ý đó là gì
      Việc mô hình ngôn ngữ lớn dùng tốt các công cụ CLI phổ biến như ffmpeg là vì kiến thức đó đã được nén cứng trong trọng số của nó
      Nếu bạn tạo một công cụ CLI mới, bạn vẫn phải dạy AI cách dùng nó; và nếu muốn phần “dạy” đó được cung cấp từ server thì là MCP, còn nếu muốn để ở dạng tĩnh cục bộ thì là skill
      Tôi không hiểu vì sao một khái niệm đơn giản như vậy lại gây tranh cãi nhiều đến thế
    • Vấn đề là MCP chiếm ngữ cảnh gần như thường trực, nhưng lại không đi kèm một cơ chế cài đặt/gỡ bỏ và khám phá gọn gàng
      Skill nên đều dựa trên MCP, chỉ được gọi khi cần, và phải để cả con người lẫn AI dễ quản lý và khám phá thì mới vận hành đúng cách
      Nhìn vào phạm vi áp dụng thực tế thì phạm vi ban đầu quá hẹp, nhưng nếu xây thêm gì đó lên trên thì nó vẫn có thể hồi sinh

  • Về nhận định “Vấn đề 1: nuốt chửng cửa sổ ngữ cảnh”, tôi không hiểu nó khác gì so với việc lần lượt chạy linearcli --help, notioncli --help, slackcli --help
    Thậm chí với MCP, môi trường thực thi có thể chỉ đưa tiêu đề của từng công cụ vào ngữ cảnh, còn tài liệu đầy đủ thì chỉ bổ sung theo từng máy chủ MCP hoặc từng công cụ khi cần
    Muốn đạt hiệu quả tương tự bằng CLI thì mọi CLI đều phải cung cấp một lệnh như --short-descr
    “Vấn đề 2: độ tin cậy vận hành thấp” cũng vậy, nếu công cụ dùng REST API thì giao thức tương tự nhau nên không có lý do gì MCP phải chậm hơn
    Nếu chậm thì có khả năng lớn là vấn đề triển khai, kiểu như chồng thêm MCP lên trên API rồi đặt trên một máy chủ thuê ngoài ở trung tâm dữ liệu xa xôi
    Có thể phần lớn máy chủ MCP đều làm rất tệ, nhưng đó là vấn đề của ngành chứ không phải của giao thức
    “Vấn đề 3: chồng lấn với CLI/API hiện có” thì đúng khi đã có sẵn công cụ CLI, và các máy chủ SQL MCP hay curl MCP có vẻ đúng là lãng phí token
    Nhưng trong đa số tổ chức thì không có CLI, và nếu có thì cùng lắm chỉ là API được thiết kế cho chương trình sử dụng chứ không phải cho mô hình ngôn ngữ lớn
    Câu “hãy cung cấp theo thứ tự CLI → API → tài liệu” nghe giống như bảo công ty trước tiên phải phát hành client desktop native và client mobile native thay vì một website chậm chạp, tốn kém

    • Tôi chưa đào quá sâu vào mảng này, nhưng trừ bản phát hành Claude Code mới nhất ra thì theo tôi biết MCP được nạp sẵn vào ngữ cảnh
      Nếu không cần thường xuyên thì phải tắt đi rồi khi cần mới bật lại
      Nếu đưa ví dụ sử dụng vào file kỹ năng thì cũng có thể giảm lần gọi --help đầu tiên, và nếu là CLI thì có vẻ cũng dễ khởi chạy một tác tử con với ngữ cảnh riêng rồi chỉ nhận lại kết quả

  • Bài viết không ghi ngày, nhưng nói rằng tải công cụ theo độ trễ là một cập nhật gần đây xuất hiện sau khi bài được viết
    Nhưng tải công cụ theo độ trễ đã được thêm vào từ tháng 11 năm 2025: https://www.anthropic.com/engineering/advanced-tool-use
    Vì vậy các con số này ít nhất cũng đã 7 tháng tuổi, và tôi không hiểu vì sao nó lại được đăng lên bây giờ

    • Vẫn còn đem chuyện này ra bàn mới thật kỳ lạ
      Vì tải công cụ theo độ trễ, ngữ cảnh lớn và prompt caching, năm 2026 đã hoàn toàn khác năm 2025
      Tranh luận rằng CLI tiết kiệm token cũng sụp đổ nếu bước đầu tiên vẫn là chạy --help
      Nếu cách gọi không được nhớ trong tham số thì rốt cuộc nó vẫn phải nằm trong ngữ cảnh
    • Hơn nữa bài này có vẻ còn cũ hơn thế, và ngầm cho thấy GPT-4o vẫn là mới nhất
    • Tải công cụ theo độ trễ không phải là một phần của MCP
      Nó là tham số chỉ dành cho Claude API mà phần lớn API mô hình ngôn ngữ lớn khác không hỗ trợ
    • Bài viết là ngày 29 tháng 5 năm 2026, và việc nói cập nhật đó là thay đổi “gần đây” sau bài viết chỉ là nói dối để khiến họ trông tốt hơn

  • Hình như đã có một bài viết rất hay rằng MCP phù hợp ở cấp độ tổ chức, khi cần cung cấp quyền truy cập hợp nhất và an toàn vào các API tiện ích nội bộ cho nhân viên không chuyên kỹ thuật đang dùng công cụ tác tử nội bộ
    Quy trình làm việc được mã hóa thành kỹ năng để chia sẻ giữa các instance, còn những gì cần truy cập API có nhận thức ngữ cảnh thì để MCP xử lý

    • Có phải bài này không? https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
    • Nếu đúng thì tôi tò mò ưu điểm của MCP là gì so với việc tác tử truy cập API trực tiếp
    • Tôi tự hỏi liệu đây có phải là thứ thay thế cho hệ thống phân quyền bảo vệ API không
      Dù sao API có lẽ vẫn phải có cơ chế phân quyền dưới một hình thức nào đó
    • Đúng vậy
      Việc các công ty như Runlayer tăng trưởng nhanh cũng chính vì lý do này, và nếu không có mặt phẳng điều khiển tập trung thì MCP sẽ thành một bãi mìn

  • Ngoài các điểm đã nêu, MCP từ xa còn có lợi thế là do máy chủ điều phối nên bên cung cấp có thể thêm tính năng mới mà không cần cập nhật kỹ năng hay CLI của mọi client
    Ngoài ra, MCP từ xa an toàn hơn vì không đòi quyền thực thi mã thực tế trên hệ thống cục bộ
    Kỹ năng thường đóng gói script bằng npx/uvx, và điều này thực chất nguy hiểm cỡ curl npm.com | bash

  • Tôi đã thử triển khai một kỹ năng để kết nối các nhóm với hệ thống quản trị nội bộ của công ty, và cuối cùng đã đăng ký nó thành MCP
    Bản thân MCP chỉ phơi bày grep tài liệu và gọi API nên tự nó hoàn toàn vô dụng, nhưng lý do chính khiến tôi chọn hướng này là triển khai
    Các nhóm không chuyên kỹ thuật muốn có UI chỉ cần thêm URL là mọi thứ chạy được ngay và OAuth được hướng dẫn sẵn, và MCP cho phép điều đó trong Claude hoặc ChatGPT
    Cách các lệnh gọi MCP hiển thị trong giao diện chat cũng tốt hơn và rõ ràng hơn với người dùng

  • Thay vì phải xử lý máy chủ MCP và phân phối CLI cho mọi nền tảng, tôi tự hỏi sao không phơi API qua SSH
    SSH là giao thức hoàn hảo cho mô hình ngôn ngữ lớn
    Tác tử lập trình đã dùng được rồi, và chỉ cần ssh api@example.com list-users là đủ
    90% người dùng có lẽ đã cài sẵn ssh, và cả đầu vào lẫn đầu ra đều là văn bản nên cực kỳ hợp với mô hình ngôn ngữ lớn
    Nó xử lý xác thực khóa công khai, đầu ra streaming, nhập/xuất tương tác, và nếu muốn thì cả truyền tệp qua scp/rsync
    Nếu người dùng đã liên kết tài khoản với Github hoặc GitLab, bạn thậm chí có thể lấy khóa ssh của họ để cấu hình xác thực sẵn, để họ chỉ cần kết nối là vào được ngay

    • Hãy thử mở rộng cách này ra quy mô toàn tổ chức

  • Phép ví von nhà hàng là không hay
    Kiểu như “10 cuốn thực đơn mở trên bàn khiến không còn chỗ đặt món ăn, và mỗi lần gọi món lại phải lôi thực đơn ra xem lại”, nhưng việc gọi lặp đi lặp lại không phổ biến trừ khi đó là quán tapas
    Đồ ăn vẫn có thể đặt lên trên thực đơn, và thông thường sau khi gọi món người ta sẽ dẹp thực đơn đi để giải phóng cái bàn, tức là ngữ cảnh
    Nếu muốn giải thích bằng phép ví von thì cần cố làm cho nó liên quan hơn