
MCP thật tuyệt vời, bạn chỉ đang sử dụng nó sai cách
MCP is great, you're just using it wrong
MCP (Meta-Client Protocol) là một giải pháp hiệu quả để kết nối các AI client giao diện người dùng (GUI AI clients) với các công cụ bên ngoài, đồng thời cung cấp cho agent khả năng truy cập tài liệu theo cấu trúc. Nó giải quyết vấn đề tích hợp N×M, tương tự như cách LSP đã chuẩn hóa việc tích hợp với các trình soạn thảo (editors), bằng cách đưa ra một giải pháp N+M cho các công cụ AI. Các developer nên tận dụng MCP cho việc truy cập tài liệu chỉ đọc (read-only documentation access), đặc biệt là với các API nội bộ hoặc những API thường xuyên thay đổi. Trường hợp sử dụng này ít rủi ro hơn so với việc gọi công cụ theo chương trình (programmatic tool-calling) trong vòng lặp của agent. Việc sử dụng MCP để gọi công cụ trực tiếp trong mã agent gặp vấn đề vì các mô hình ngôn ngữ lớn (LLMs) không được tối ưu hóa để tạo ra cú pháp gọi công cụ đáng tin cậy, dẫn đến hành vi của agent trở nên dễ vỡ và thiếu ổn định.
Mọi người phàn nàn rằng MCP được thiết kế quá mức và không đáng tin cậy là đúng - nhưng vì những lý do sai lầm. MCP hoạt động tốt cho hai thứ: tích hợp máy khách GUI và máy chủ tài liệu. Đó là một ý tưởng tồi đối với các nhà phát triển khi kết nối công cụ gọi bằng mã đại lý. Đây là sự khác biệt mà không ai tạo ra.
Không ai tranh cãi về điều đúng đắn. Những người bảo vệ MCP trỏ đến Claude Desktop kết nối với Jira của bạn chỉ bằng hai cú nhấp chuột hoặc máy chủ tài liệu cung cấp cho tác nhân bối cảnh hoàn hảo về API của khung. Những người chỉ trích nó chỉ ra rằng cơ sở mã tác nhân của họ trở thành một mớ hỗn độn không đáng tin cậy của JSON-RPC boilerplate. Cả hai đều đúng. Họ đang mô tả các trường hợp sử dụng khác nhau.
MCP là phần mềm thực sự tốt cho hai vấn đề cụ thể: kết nối máy khách GUI AI với các công cụ bên ngoài và cho phép các đại lý truy cập vào tài liệu. Trường hợp nó sụp đổ là khi các nhà phát triển sử dụng nó cho công cụ lập trình gọi các vòng tác nhân bên trong.
Trường hợp MCP
Ý tưởng cốt lõi củaMCP là âm thanh. Nếu không có tiêu chuẩn, mọi ứng dụng khách AI (Claude, Cursor, bất cứ thứ gì tiếp theo) đều cần tích hợp tùy chỉnh cho mọi công cụ (GitHub, Jira, Notion, API nội bộ của bạn). Đó là một vấn đề N×M. MCP làm cho nó N+M. Một máy chủ hoạt động với mọi máy khách. Đó là giá trị thực.
Sự tương tự của LSP mà mọi người tiếp tục tiếp cận là phù hợp. Giao thức máy chủ ngôn ngữ đã giải quyết chính xác vấn đề này để tích hợp trình chỉnh sửa — một máy chủ ngôn ngữ hoạt động trong VS Code, Neovim, Emacs. Trước LSP, mọi sự kết hợp đều là một bản dựng tùy chỉnh. MCP đang thử điều tương tự cho các công cụ AI và cho trường hợp sử dụng máy khách GUI — Claude Desktop, Cursor, bất cứ thứ gì bạn đang chạy trong thanh bên — nó hoạt động tốt.
Nếu bạn không phải là nhà phát triển và bạn muốn trợ lý AI của mình đọc lịch, cập nhật vé hoặc truy vấn cơ sở dữ liệu, MCP là câu trả lời đúng. Công cụ ở đó, khách hàng hỗ trợ nó và bạn không cần phải viết một dòng mã.
Tài liệu MCP: trường hợp sử dụng bị đánh giá thấp
Tài liệu là nơi MCP lặng lẽ thực hiện công việc tốt nhất của mình và là nơi phần lớn những lời chỉ trích bỏ lỡ dấu ấn.
Máy chủ MCP tài liệu cung cấp cho nhân viên chăm sóc khách hàng kiến thức cập nhật, có cấu trúc về khung, API hoặc hệ thống nội bộ. Tác nhân yêu cầu những gì nó cần, máy chủ trả về đánh dấu sạch với các ví dụ mã, chữ ký loại và mẫu sử dụng. Không giống như đẩy toàn bộ trang web tài liệu vào cửa sổ ngữ cảnh trước, MCP cho phép nhân viên chăm sóc khách hàng kéo các trang cụ thể theo yêu cầu. Bối cảnh vẫn nhỏ. Thông tin luôn được cập nhật.
Điều này rất quan trọng vì LLM được đào tạo nhanh về internet. Thư viện gửi những thay đổi đột phá. Khởi chạy API mới. Các công cụ nội bộ không có tài liệu công khai nào cả. Máy chủ MCP tài liệu thu hẹp khoảng cách đó theo cách vừa được chuẩn hóa vừa có thể tổng hợp — cùng một máy chủ hoạt động cho dù tác nhân chạy trong Claude Desktop, Cursor hay máy khách tùy chỉnh.
Mẫu này đặc biệt phù hợp với:
- Tài liệu khung thay đổi giữa các phiên bản — máy chủ MCP Next.js hoặc SvelteKit có thể phân phát tài liệu khớp với phiên bản trong package.json của
bạn, chứ không phải bất kỳ phiên bản nào mà LLM được đào tạo - API nội bộ và công cụ dành riêng cho công ty — những điều mà LLM chưa bao giờ thấy và không thể đoán được
- Tham chiếu API với chữ ký loại phức tạp — dữ liệu có cấu trúc mà máy chủ MCP có thể trả về ở định dạng mà tác nhân phân tích cú pháp rõ ràng, thay vì hy vọng LLM nhớ hình dạng chính xác của đối tượng phản hồi
Sự khác biệt chính so với MCP gọi công cụ là hồ sơ rủi ro. Một máy chủ tài liệu là chỉ đọc. Nó trả về văn bản. Nếu nó trả về văn bản hơi sai, tác nhân có thể viết mã hơi sai, mà nhà phát triển bắt được khi xem xét. Một máy chủ MCP gọi công cụ thực hiện hành động sai đối với cơ sở dữ liệu sản xuất không có mạng lưới an toàn như vậy.
Vấn đề: MCP gọi công cụ trong mã tác nhân
Áp lực hệ sinh thái đã đẩy MCP vào vòng lặp tác nhân lập trình cho việc gọi công cụ, và đó là nơi nó đi sai.
Khi bạn sử dụng cơ chế gọi công cụ trực tiếp của MCP trong một tác nhân — có các công cụ gọi LLM thông qua giao thức khi chạy — bạn đang yêu cầu LLM hoạt động ở chế độ yếu nhất. LLM được đào tạo trên hàng tỷ dòng Python và TypeScript thực gọi các API thực. Họ được đào tạo về một bộ dữ liệu tổng hợp nhỏ của cú pháp JSON gọi công cụ. Đội ngũ kỹ thuật của Cloudflare nói thẳng thừng: "Làm cho một LLM thực hiện các nhiệm vụ bằng cách gọi công cụ giống như đưa Shakespeare qua một lớp học kéo dài một tháng bằng tiếng Quan Thoại và sau đó yêu cầu anh ta viết một vở kịch trong đó."
Bản sửa lỗi Cloudflare đã hạ cánh — và những gì StackOne tìm thấy làm giảm 98,7% chi phí mã thông báo — là có mã ghi LLM gọi các công cụ MCP thay vì gọi trực tiếp. Chế độ mã: tác nhân viết một hàm TypeScript, thực thi nó, nhận kết quả. Một lượt suy luận thay vì N lời gọi công cụ tuần tự. Đáng tin cậy hơn nhiều. Rẻ hơn nhiều.
Điều này đặt ra một câu hỏi rõ ràng: nếu cách đúng đắn để sử dụng MCP theo lập trình là có mã viết LLM gọi MCP... tại sao không viết mã gọi API trực tiếp? Bạn đã thêm quy trình máy chủ JSON-RPC, lớp giao thức và cơ chế khám phá cho những gì có thể là lệnh gọi fetch().
MCP gọi công cụ theo chương trình là tồi tệ nhất của cả hai thế giới
Nếu bạn đang xây dựng các tác nhân trong mã, gọi công cụ trực tiếp và MCP theo chương trình chia sẻ chế độ lỗi: cả hai đều làm cho độ tin cậy của tác nhân của bạn phụ thuộc vào LLM tạo ra chính xác đầu ra có cấu trúc (gọi công cụ hoặc gọi hàm) trong mỗi lượt. Nhưng MCP theo chương trình cũng cho biết thêm:
- Một quy trình máy chủ đang chạy mà bạn phải quản lý và duy trì hoạt động
- Chi phí cửa sổ ngữ cảnh: một thiết lập năm máy chủ khiêm tốn với 58 công cụ đã tiêu thụ ~55.000 mã thông báo trước khi bất kỳ cuộc trò chuyện nào bắt đầu (số lượng sản xuất của StackOne). 10 máy chủ × 5 công cụ, mỗi công cụ có nghĩa là 50 định nghĩa công cụ ăn ngữ cảnh trước khi bạn nói một từ.
- Giảm chất lượng phản hồi: bối cảnh dài khiến hướng dẫn LLM - tuân theo giảm. Càng nhiều công cụ được tải, tác nhân càng hoạt động kém trong các tác vụ không liên quan.
- Một giao thức mà LLM của bạn không hiểu rõ
Nếu quý vị có nhiều hơn năm công cụ và nhiều hơn một nhóm, tiêu chuẩn hóa của MCP có giá trị thực sự cho việc gọi công cụ. Nếu bạn đang xây dựng một ứng dụng duy nhất với một số ít các công cụ, chi phí chung là chi phí thuần túy mà không có lợi ích gì.
Lưu ý rằng những vấn đề này là cụ thể đối với các máy chủ gọi công cụ. Một máy chủ MCP tài liệu thường hiển thị một hoặc hai công cụ (SEARCH_DOCS, get_PAGE) với chi phí sơ đồ tối thiểu. Nó không làm phình to bối cảnh với 50 định nghĩa công cụ và không có nguy cơ tác nhân vô tình thực hiện một hành động phá hoại.
Kỹ năng, không phải MCP gọi công cụ
Đối với hầu hết những gì các nhà phát triển đạt được cho MCP gọi công cụ để giải quyết — cung cấp cho một đại lý kiến thức thủ tục về cách thực hiện mọi thứ — sự trừu tượng phù hợp gần với những gì Anthropic gọi là Kỹ năng: hướng dẫn được mã hóa về quy trình làm việc, phong cách và quy trình nhiều bước, được tải dần dần khi cần thiết thay vì tất cả trả trước.
Các kỹ năng dành riêng cho Claude và không giải quyết được vấn đề khả năng tương tác. Nhưng nếu bạn không giải quyết được vấn đề khả năng tương tác (bạn đang xây dựng một tác nhân trong một cơ sở mã cho một trường hợp sử dụng), bạn không cần phải trả chi phí của MCP để nhận được những gì Kỹ năng cung cấp miễn phí cho bạn.
Tài liệu MCP và Kỹ năng thực sự bổ sung cho nhau. Các kỹ năng cho nhân viên chăm sóc khách hàng biết cách thực hiện một việc gì đó (quy trình làm việc, quy ước, mô hình). Docs MCP cho tác nhân biết những gì có sẵn (bề mặt API, chữ ký loại, tùy chọn cấu hình). Một tác nhân có cả hai có thể tuân theo các quy ước mã hóa của công ty trong khi sử dụng API chính xác, hiện tại.
Vấn đề bảo mật không ai nói đủ
MCP có một vấn đề bảo mật nghiêm trọng mà việc triển khai tốt có thể giảm thiểu nhưng không thể loại bỏ và nó ảnh hưởng đến các máy chủ gọi công cụ nhiều hơn các máy chủ tài liệu.
Mô tả công cụ là hướng dẫn mà LLM đọc. Nếu một máy chủ MCP có thể tự động xác định lại các mô tả công cụ của nó — mà giao thức cho phép — một máy chủ bị xâm nhập hoặc độc hại có thể chèn các hướng dẫn vào ngữ cảnh của LLM không hiển thị trong giao diện người dùng. Các nhà nghiên cứu đã chứng minh điều này bằng cách ẩn các hướng dẫn lọc trong văn bản được mã hóa bằng khoảng trắng trong mô tả công cụ. Một máy chủ trông hợp pháp cài đặt, xây dựng lòng tin, sau đó viết lại các công cụ của nó để làm một việc khác. Không có xác minh tính toàn vẹn trong giao thức.
Vấn đề tiêm của bên thứ tư còn tồi tệ hơn: một máy chủ MCP đáng tin cậy lấy dữ liệu từ một nguồn không đáng tin cậy (một vấn đề GitHub, một trang web), trong đó có các hướng dẫn tiêm. Máy chủ của bạn sạch sẽ. Dữ liệu mà nó truy xuất thì không. Hai bước nhảy được loại bỏ khỏi người dùng và LLM coi đó là có thẩm quyền.
Một cuộc quét năm 2025 với khoảng2.000 máy chủ MCP tiếp xúc với internet cho thấy tất cả các máy chủ đã được xác minh đều không có bất kỳ xác thực nào. Giao thức đề xuất xác thực nhưng không thực thi nó.
Đối với máy chủ tài liệu, bề mặt tấn công nhỏ hơn. Máy chủ trả về văn bản tài liệu, chỉ đọc và thường có nguồn gốc từ một kho lưu trữ được kiểm soát. Một máy chủ tài liệu bị xâm nhập có thể đưa ra các hướng dẫn sai lệch, nhưng bán kính vụ nổ chỉ giới hạn ở các đề xuất mã xấu — không phải là hành động trái phép đối với các hệ thống sản xuất. Đối với các máy chủ gọi công cụ thực hiện các hành động chống lại các hệ thống bên ngoài, khoảng cách bảo mật là có cấu trúc.
Sự phân chia thực tế
Có ba trường hợp sử dụng MCP riêng biệt và chúng không nên được đánh giá cùng nhau:
Docs MCP — tốt:
- Cung cấp cho nhân viên chăm sóc khách hàng tài liệu hiện tại, có cấu trúc theo yêu cầu
- Chi phí chung trong bối cảnh thấp (một hoặc hai công cụ, không phải 50)
- Chỉ đọc và rủi ro thấp
- Hoạt động trên mọi máy khách tương thích MCP
- Đặc biệt có giá trị đối với các API nội bộ và các khung di chuyển nhanh
MCP máy khách GUI — tốt:
- Một người không phải là nhà phát triển kết nối máy khách GUI AI với các công cụ bên ngoài
- Khả năng tương tác giữa các mô hình có ý nghĩa quan trọng
- Hơn 10 công cụ được chia sẻ trên nhiều nhóm được hưởng lợi từ tiêu chuẩn N+M
MCP gọi công cụ theo chương trình — thường sai:
- Bạn đang xây dựng các tác nhân bằng mã với một số công cụ — thay vào đó, hãy sử dụng các lệnh gọi API trực tiếp hoặc gọi hàm
- Bạn đang mã hóa kiến thức thủ tục về cách thực hiện công việc — thay vào đó, hãy sử dụng các kỹ năng hoặc các mẫu nhắc nhở của hệ thống
- Bạn đang ở giai đoạn đầu và cơ sở hạ tầng máy chủ đang ngày càng phức tạp hơn so với mức tiết kiệm tiêu chuẩn hóa
Sự nhầm lẫn xuất phát từ việc coi MCP là một thứ. Máy chủ MCP tài liệu và máy chủ MCP gọi công cụ chia sẻ một giao thức nhưng chúng có cấu hình chi phí khác nhau, cấu hình rủi ro khác nhau và các đề xuất giá trị khác nhau. Những lời chỉ trích rằng MCP được thiết kế quá mức là đúng - đối với việc gọi công cụ bằng mã tác nhân. Đối với việc tích hợp tài liệu và GUI, giao thức sẽ được duy trì.
Tác giả: ritzaco