MCP so với API: Sự khác biệt thực sự và khi nào nên sử dụng từng loại

“MCP so với API” nghe có vẻ như là sự lựa chọn giữa hai công nghệ cạnh tranh. Tuy nhiên, chúng cùng nằm trong cùng một hệ thống. Một API phơi bày những gì hệ thống có thể thực hiện. Một máy chủ MCP sau đó có thể cung cấp các khả năng được lựa chọn cho các ứng dụng AI, bất kể các khả năng đó đến từ API, cơ sở dữ liệu, tệp cục bộ hay nguồn khác.

Vì vậy, so sánh ở đây không phải là liệu MCP có thay thế API hay không, cũng không phải là sự khác biệt bản chất giữa chúng. Mà là mỗi lớp mang lại cho bạn điều gì, ở đâu mỗi lớp làm tăng độ phức tạp, và khi nào việc sử dụng cả hai sẽ hợp lý hơn so với việc chỉ chọn một trong hai.

So sánh nhanh giữa MCP và API

MCP là gì?

MCP ( Model Context Protocol) là một tiêu chuẩn mở cung cấp cho các ứng dụng AI một phương thức chia sẻ để phát hiện và sử dụng các công cụ, dữ liệu và dịch vụ bên ngoài.

Cách thức hoạt động của MCP

Thay vì mã hóa cứng mọi hành động có thể xảy ra, một khách hàng MCP có thể hỏi máy chủ được kết nối xem máy chủ đó cung cấp những gì. Máy chủ sẽ trả về danh mục các công cụ kèm theo tên, mô tả và lược đồ đầu vào. Sau đó, mô hình AI có thể quyết định công cụ nào phù hợp với yêu cầu của người dùng.

Khả năng khám phá thời gian chạy là một trong những ưu điểm chính của MCP. Thay vì phải học một mô hình tích hợp khác nhau cho từng dịch vụ, khách hàng sẽ có một cách tiêu chuẩn để xem máy chủ cung cấp những gì và gọi các tính năng đó khi cần thiết.

Anthropic đã giới thiệu MCP vào tháng 11 năm 2024 và tặng nó cho Quỹ Agentic AI thuộc Quỹ Linux vào tháng 12 năm 2025.

MCP phù hợp nhất với trường hợp nào

MCP là lựa chọn hợp lý nhất khi một trợ lý hoặc tác nhân AI cần truy cập vào nhiều công cụ và phải quyết định sử dụng công cụ nào tại thời điểm chạy.

API là gì?

API (Giao diện lập trình ứng dụng) là một hợp đồng được công bố. Nhà cung cấp cam kết thực hiện một tập hợp các thao tác, định dạng của từng yêu cầu và kết quả trả về. Mã nguồn của bạn chỉ cần đọc hợp đồng đó một lần và gọi nó theo cùng một cách mỗi lần.

Cách thức hoạt động của API

Thông thường, một nhà phát triển sẽ đọc tài liệu API, chọn một điểm cuối, xác định các tham số cần thiết và viết mã để thực hiện yêu cầu.

Ví dụ, một ứng dụng có thể gọi một điểm cuối để tạo công việc và một điểm cuối khác để truy xuất hồ sơ khách hàng. Ứng dụng đã biết nên sử dụng điểm cuối nào vì logic đó đã được lập trình sẵn trong phần mềm.

Ghi chú: “API” bao gồm nhiều kiểu không tương thích với nhau. REST tổ chức các thao tác xoay quanh các tài nguyên và động từ HTTP. GraphQL chỉ cung cấp một điểm cuối và cho phép người gọi chỉ định các trường dữ liệu mà họ muốn. gRPC sử dụng dữ liệu nhị phân qua HTTP/2 cho các cuộc gọi giữa các dịch vụ, nơi độ trễ là yếu tố quan trọng.

Tiêu chuẩn mô tả chung gần nhất là OpenAPI, được nhiều nhà cung cấp công bố nhưng cũng có nhiều nhà cung cấp không áp dụng. Điều mà các API hiện có là khoảng hai thập kỷ tích lũy các công cụ: cổng kết nối, kiểm thử hợp đồng, theo dõi phân tán, quy ước phiên bản và hạ tầng giới hạn tốc độ — những thứ mà hầu hết các nhóm kỹ thuật đã triển khai. MCP vẫn đang trong quá trình xây dựng các thành phần tương đương.

API nào là phù hợp nhất cho

API hoạt động hiệu quả khi ứng dụng cần quyền truy cập có thể dự đoán được vào một dịch vụ đã biết, và các nhà phát triển muốn kiểm soát trực tiếp những gì được gọi và thời điểm gọi.

MCP so với API: Những điểm khác biệt chính là gì?

Cả API và MCP đều cung cấp các hành động, nhưng cách xử lý kết nối của chúng khác nhau. API bắt đầu với một thao tác đã biết. MCP bắt đầu với một câu hỏi: có những gì sẵn có? Từ đó nảy sinh ba điểm khác biệt, và không có điểm nào trong số đó liên quan đến việc giao diện nào “thắng”. Chúng liên quan đến việc giao diện nào xử lý người gọi nào.

API bắt đầu với một thao tác đã biết

Với API, ứng dụng đã biết trước endpoint nào mình cần. Nhà phát triển định nghĩa yêu cầu, cài đặt các tham số và viết mã xử lý phản hồi.

Điều này khiến API trở thành lựa chọn lý tưởng cho các quy trình làm việc cố định. Khi một thanh toán được xử lý thành công, hệ thống của bạn sẽ tạo hóa đơn. Lộ trình gọi API chỉ cần được viết một lần, kiểm thử và tái sử dụng mỗi lần.

Với MCP, con đường vẫn rộng mở. Một khách hàng kết nối sẽ kiểm tra các công cụ mà máy chủ cung cấp, sau đó đưa chúng vào hệ thống AI. Hành động tiếp theo phụ thuộc vào yêu cầu của người dùng, chứ không phải vào một luồng xử lý được định sẵn từ trước.

Lớp giao diện hoạt động theo cách khác

API có nhiều dạng khác nhau. Một nhà cung cấp sử dụng REST, một nhà cung cấp khác sử dụng GraphQL, và một nhà cung cấp khác lại dựa vào SDK. Xác thực, lỗi, phân trang và định dạng yêu cầu đều khác nhau giữa các dịch vụ.

MCP cung cấp cho các ứng dụng AI một giao thức duy nhất để kết nối với máy chủ và truy cập các dữ liệu mà máy chủ cung cấp. Điều này không có nghĩa là mọi công cụ đều giống hệt nhau. Hai máy chủ vẫn có thể đặt tên hoặc thiết kế các hành động tương tự theo cách khác nhau. Tuy nhiên, ứng dụng không cần phải sử dụng một giao thức khác nhau cho từng máy chủ.

Bối cảnh công cụ ảnh hưởng đến cách mô hình đưa ra quyết định

Mô tả API được thiết kế dành cho các nhà phát triển và mã nguồn của họ. Ứng dụng đã biết cần gọi hàm nào trước khi yêu cầu bắt đầu.

Với MCP, tên công cụ, mô tả và lược đồ đầu vào được truyền vào bối cảnh làm việc của mô hình. Mô hình đọc thông tin đó, quyết định hành động nào phù hợp với yêu cầu và điền các đối số vào.

Một trong những điểm hiển thị rõ sự khác biệt này là trong các quy trình làm việc của agent, nơi hệ thống có thể cần phải chọn hành động tiếp theo dựa trên yêu cầu thay vì tuân theo một trình tự cố định.

Cách lựa chọn giữa MCP và API

Hãy lựa chọn giữa MCP và API dựa trên cách thức mà tính năng cần được cung cấp. API hoạt động hiệu quả khi ứng dụng của bạn đã biết rõ dịch vụ hoặc thao tác nào cần gọi. MCP hữu ích khi một ứng dụng AI cần một phương thức tiêu chuẩn để phát hiện và sử dụng các tính năng trên các hệ thống khác nhau trong thời gian chạy.

Nên chọn API khi

Nên chọn MCP khi

Những hạn chế của API

API có những hạn chế vì mỗi lần tích hợp đều được tùy chỉnh riêng biệt, chúng không thể thích ứng khi người dùng yêu cầu những tính năng mà nhà phát triển chưa mã hóa sẵn, các quy trình làm việc đa dịch vụ buộc bạn phải tự đảm nhận toàn bộ việc điều phối, và chất lượng tài liệu hướng dẫn không đồng đều giữa các nhà cung cấp.

Những điểm còn hạn chế của MCP

Những giới hạn chính của MCP bao gồm sự phức tạp trong việc gỡ lỗi, các mô tả công cụ có thể không còn đồng bộ với hành vi của máy chủ, sự thiếu vắng một kho lưu trữ máy chủ chung, và các mẫu thông tin xác thực chưa được tiêu chuẩn hóa cho mục đích sử dụng trong doanh nghiệp.

Không có yếu tố nào trong số này là cố định. Tiêu chuẩn đang phát triển nhanh chóng, và các công cụ hỗ trợ cũng đang bắt kịp. Tuy nhiên, nếu bạn đang đánh giá MCP cho một triển khai sản xuất ngay từ bây giờ, hãy xây dựng hệ thống dựa trên những hạn chế này thay vì giả định rằng chúng sẽ biến mất trước khi ra mắt.

Gọi công cụ MCP so với yêu cầu API trực tiếp

Một yêu cầu API được gửi trực tiếp đến một điểm cuối đã biết với các tham số cố định mà mã của bạn đã định nghĩa trước. Một lệnh gọi công cụ MCP bao bọc cùng một hành động trong một gói JSON-RPC mà mô hình AI lựa chọn tại thời điểm chạy sau khi đọc danh mục công cụ của máy chủ. Sau đó, máy chủ MCP thực thi lệnh gọi API cơ bản thay mặt cho mô hình.

Dưới đây là quy trình “tạo công việc trong ClickUp” qua từng lớp.

Thông qua API

Ứng dụng của bạn đã biết ID danh sách công việc, người được giao và điểm cuối chính xác. Ứng dụng gọi trực tiếp đến điểm cuối đó.

Phản hồi được trả về kèm theo đối tượng công việc đã tạo. Không có mô hình nào được sử dụng. Nhà phát triển đã viết logic, chọn điểm cuối và xử lý kết quả.

Thông qua MCP

Một khách hàng AI kết nối với máy chủ MCP của ClickUp và hỏi xem có những công cụ nào:

Mô hình đọc lược đồ, xác định xem `create_task` có phù hợp với yêu cầu của người dùng hay không, và trả về các đối số có cấu trúc:

Cùng một công việc được tạo ra. Máy chủ MCP vẫn gọi API REST của ClickUp ở phía sau để thực thi công việc đó.

Điểm khác biệt thực sự là gì

Kết quả là như nhau. Điều thay đổi là người đưa ra quyết định.

Với API, mã nguồn của bạn đã biết điểm cuối (endpoint) trước khi yêu cầu bắt đầu. Với MCP, mô hình sẽ đọc danh mục công cụ tại thời điểm chạy và chọn hàm `create_task` từ hơn 40 công cụ có sẵn dựa trên yêu cầu của người dùng được diễn đạt bằng ngôn ngữ thông thường.

Không có phương pháp nào tốt hơn một cách tuyệt đối. API nhanh hơn, rẻ hơn và có tính xác định. MCP linh hoạt, dễ phát hiện và được thiết kế dành cho người gọi sử dụng ngôn ngữ tự nhiên.

MCP là có trạng thái hay không có trạng thái?

Theo tiêu chuẩn ngày 28 tháng 7 năm 2026, lõi giao thức của MCP là không trạng thái. Sự khác biệt mà các so sánh trước đây thường dựa vào (REST là không trạng thái, MCP duy trì phiên làm việc) hiện nay mô tả một phương thức truyền tải đã bị loại bỏ.

Quy trình bắt tay “initialize” cũ và tiêu đề “Mcp-Session-Id” đã không còn. Mỗi yêu cầu đều mang theo phiên bản giao thức, danh tính khách hàng và các tính năng riêng của mình. Bất kỳ yêu cầu nào cũng có thể được xử lý bởi bất kỳ phiên bản máy chủ nào phía sau bộ cân bằng tải theo cơ chế round-robin thông thường. Không có định tuyến dính (sticky routing), không có bộ lưu trữ phiên chung.

Tiêu chuẩn này cũng đưa tên phương thức và công cụ vào các tiêu đề HTTP. Các cổng kết nối, bộ giới hạn tốc độ và tường lửa ứng dụng web (WAF) giờ đây có thể định tuyến hoặc đo lường lưu lượng MCP mà không cần phân tích nội dung JSON trước.

Khi vẫn cần nhiều lần trao đổi, MCP cung cấp hai mô hình. Yêu cầu đa vòng đi-về (Multi-Round-Trip Requests) xử lý các trao đổi nhẹ nhàng trong một lần gọi duy nhất. Phần mở rộng Tasks xử lý các hoạt động kéo dài: máy chủ trả về một handle công việc bền vững, và nếu cần thêm thông tin trong quá trình thực thi, nó sẽ tạm dừng với trạng thái “input_required” cho đến khi khách hàng cung cấp đầu vào còn thiếu. Hành vi có trạng thái (stateful) cũ đang trong giai đoạn chuyển đổi, và Roots, Sampling và Logging (ba tính năng cũ cho phép máy chủ yêu cầu thông tin trở lại từ khách hàng) đã bị loại bỏ dần riêng biệt, với thời gian ít nhất 12 tháng trước khi bị gỡ bỏ hoàn toàn.

Vì vậy, tính có trạng thái (statefulness) không còn là ranh giới phân biệt. Sự khác biệt còn tồn tại nằm ở cấp độ cao hơn giao thức truyền tải: API dựa vào logic do nhà phát triển viết để xác định những gì sẽ được gọi. MCP cho phép mô hình AI tự phát hiện và chủ yếu tự quyết định.

Sự khác biệt giữa MCP và việc gọi hàm là gì?

Gọi hàm là một tính năng của mô hình. MCP là tiêu chuẩn phát hiện và truyền tải cung cấp tính năng này. Gọi hàm cho phép mô hình phát ra một yêu cầu có cấu trúc để gọi một hàm mà bạn đã định nghĩa trong mã của riêng mình. MCP tiêu chuẩn hóa nguồn gốc của các định nghĩa đó, cách khách hàng lấy chúng từ máy chủ trong thời gian chạy, và cách thức hoạt động của cơ chế ủy quyền. Mô hình sử dụng tính năng gọi hàm để thực hiện các tác vụ trên các công cụ do MCP cung cấp.

Việc gọi hàm (còn gọi là sử dụng công cụ) được tích hợp sẵn trong các API mô hình của OpenAI, Anthropic và Google. Bạn định nghĩa một tập hợp các hàm, truyền lược đồ của chúng cho mô hình, và mô hình sẽ trả về các đối số có cấu trúc khi xác định rằng một trong số đó là phù hợp. Bạn vẫn là người quyết định các hàm nào sẽ cung cấp, viết mã thực thi và xử lý phản hồi. Mô hình sẽ chọn hàm nào để gọi. Mã của bạn sẽ thực hiện phần còn lại.

MCP hoạt động ở một lớp bên ngoài. Nó tiêu chuẩn hóa cách một khách hàng AI xác định các hàm nào tồn tại ngay từ đầu, trên nhiều máy chủ, mà không cần mã hóa cứng từ phía bạn. Máy chủ công bố các công cụ của mình. Khách hàng đọc các công cụ này tại thời điểm chạy. Sau đó, mô hình sử dụng việc gọi hàm để thực thi hàm mà nó đã chọn.

Nói một cách đơn giản: việc gọi hàm chính là cách mô hình thông báo: “Tôi muốn gọi công cụ này với các đối số này.” MCP là thành phần cho mô hình biết những công cụ nào có sẵn để gọi.

Hầu hết các khách hàng tương thích với MCP đều chạy cả hai cùng lúc. Chúng lấy các lược đồ công cụ từ máy chủ MCP, định dạng chúng thành các định nghĩa hàm cho mô hình, và chuyển đầu ra có cấu trúc của mô hình trở lại qua MCP để thực thi. Cả hai đều là các lớp trong cùng một stack, do đó bạn thường sẽ thấy chúng hoạt động theo thứ tự trên một yêu cầu duy nhất.

MCP có chậm hơn hay tốn kém hơn API không?

Đúng vậy, MCP vừa chậm hơn vừa tốn kém hơn so với việc gọi API trực tiếp. MCP đưa mô hình AI vào vòng lặp yêu cầu, điều này gây ra độ trễ thêm và chi phí token. API trực tiếp gửi yêu cầu trực tiếp đến điểm cuối, trong khi MCP yêu cầu mô hình ngôn ngữ lớn (LLM) phải chọn, chạy và đọc các công cụ một cách động.

Tại sao MCP lại chậm hơn

Tại sao MCP lại đắt hơn

Liệu MCP có kém về bảo mật hơn API không?

Không phải theo bản chất. MCP có các yêu cầu bảo mật tương tự như bất kỳ API nào: xác thực, ủy quyền, quyền truy cập có phạm vi và xác thực đầu vào. Sự khác biệt nằm ở việc ai là người quyết định gọi hàm nào.

Có hai rủi ro đáng được đề cập:

Đầu độc công cụ. Một máy chủ MCP độc hại trả về các lệnh ẩn bên trong phản hồi của công cụ. Mô hình coi phản hồi đó là bối cảnh đáng tin cậy và thực hiện theo các lệnh được nhúng trong đó. OWASP phân loại điều này là tấn công tiêm lệnh gián tiếp nhắm vào các tác nhân kết nối với MCP. Kỹ thuật này hoạt động vì mô tả công cụ chỉ được kiểm tra một lần tại thời điểm kết nối, nhưng phản hồi của công cụ lại được đưa trực tiếp vào bối cảnh của mô hình trong quá trình chạy mà không qua bất kỳ kiểm tra tương tự nào.

“Bộ ba chết người.” Đây là cách diễn đạt của Simon Willison. Nó ám chỉ một tác nhân có quyền truy cập vào dữ liệu riêng tư, tiêu thụ nội dung không đáng tin cậy và có thể giao tiếp với bên ngoài. Khi kết hợp cả ba yếu tố này, việc chèn lệnh (prompt injection) sẽ trở thành con đường dẫn đến việc rò rỉ dữ liệu. MCP khiến việc kết hợp này trở nên dễ dàng vì người dùng kết nối các công cụ từ nhiều nguồn khác nhau.

Câu hỏi thực tế không phải là liệu MCP có “bảo mật” hay không. Mà là liệu bạn đã giới hạn được những gì mô hình có thể “nhìn thấy”, “chọn” và “thực thi” hay chưa, chứ không chỉ là những gì mã có thể gọi.

Đối với các triển khai MCP:

Cách ClickUp sử dụng cả MCP và API

ClickUp là một ví dụ về mô hình “xây dựng cả hai” mà chúng tôi đã mô tả cho đến nay.

API ClickUp là giao diện dành cho nhà phát triển đầy đủ tính năng. Các nhóm sử dụng API này để xây dựng các kết nối tùy chỉnh, đồng bộ hóa dữ liệu giữa các hệ thống và chạy các quy trình làm việc với khả năng kiểm soát trực tiếp từng yêu cầu.

Máy chủ MCP của ClickUp cung cấp nhiều hành động tương tự thông qua MCP. Các ứng dụng AI như Claude Code, Cursor và ChatGPT có thể kết nối, xác định các công cụ ClickUp hiện có và gọi chúng thông qua các lệnh bằng ngôn ngữ tự nhiên. Điều này bao gồm tạo công việc, tìm kiếm trong Không gian Làm việc ClickUp, làm việc với tài liệu, đăng bình luận và ghi lại thời gian.

Lớp AI tương tác với người dùng nằm ở phía trên. ClickUp Brain trích xuất bối cảnh từ các công việc, tài liệu, cuộc trò chuyện và các công việc khác.

Các ClickUp Super Agents sử dụng bối cảnh đó để đưa ra quyết định và tự động thực hiện các quy trình làm việc nhiều bước. Bạn có thể giao công việc cho họ, nhắn tin cho họ và cho phép họ thực hiện các công việc trên toàn bộ Không gian Làm việc ClickUp.

Điều này mang lại cho ClickUp ba lớp chức năng. API phục vụ các nhà phát triển muốn có quyền truy cập đầy đủ. MCP cung cấp cho các khách hàng AI bên ngoài một cách tiêu chuẩn để tìm kiếm và sử dụng các công cụ của ClickUp. Brain và Super Agents tích hợp khả năng suy luận AI trực tiếp vào chính sản phẩm.

Tất nhiên, ClickUp cũng cho phép bạn kết nối với các công cụ khác thông qua các máy chủ MCP của họ. Không cần phải thực hiện bất kỳ công việc nào với API.

Hãy ngừng so sánh các giao thức truyền tải và bắt đầu so sánh các ứng dụng người dùng

MCP và API không phải là các tiêu chuẩn cạnh tranh với nhau, và những điểm khác biệt mà mọi người thường nhắc đến nhất chính là những điểm đã trở nên lỗi thời nhanh nhất.

Điều còn lại là một quyết định kiến trúc thực sự. API là một hợp đồng dành cho các nhà phát triển. Máy chủ MCP là một hợp đồng dành cho các mô hình, điều này khiến nó vừa là lời nhắc, vừa là chi phí token, vừa là bề mặt tấn công cùng một lúc.

Thiết kế phù hợp. Giữ API làm nền tảng xác định của bạn. Sau đó, quyết định, từng công cụ một, những việc cần làm mà không cần sự can thiệp của con người, và chỉ công bố những điều đó. Đánh giá chi phí của danh mục công cụ trong bối cảnh cụ thể, và giả định rằng mọi mô tả công cụ và mọi phản hồi từ công cụ đều nằm dưới sự kiểm soát của kẻ tấn công cho đến khi bạn xác minh ngược lại.

Dù bạn chọn API hay MCP, ClickUp đều tương thích với cả hai. Bắt đầu sử dụng ClickUp miễn phí ngay hôm nay.

Các câu hỏi thường gặp về MCP so với API

Định dạng truyền tải là JSON-RPC 2.0 qua HTTP, được thiết kế để không có gì đặc biệt. Giá trị nằm ở danh mục khả năng được tiêu chuẩn hóa, lược đồ công cụ và mô hình ủy quyền được xây dựng dựa trên nền tảng đó. Theo tiêu chuẩn tháng 7, mỗi yêu cầu đều tự mô tả và không lưu trạng thái, với tên phương thức và công cụ được truyền trong các tiêu đề HTTP để các cổng có thể định tuyến mà không cần phân tích nội dung. Hiện nay, một tích hợp duy nhất có thể phục vụ Claude, ChatGPT, Cursor, Gemini và Copilot mà không cần các thành phần kết nối tùy chỉnh riêng cho từng dịch vụ.

ClickUp có cả API và máy chủ MCP không?

Đúng vậy. ClickUp cung cấp một API REST với tiêu chuẩn OpenAPI để thực hiện các tích hợp xác định và điều khiển bằng mã, cùng với một máy chủ MCP riêng biệt (phiên bản beta công khai) cho phép các trợ lý như Claude, ChatGPT và Cursor tương tác với dữ liệu không gian làm việc bằng ngôn ngữ tự nhiên. Giao diện MCP là một tập con được thiết kế có chủ đích của API, do đó mọi thao tác nằm ngoài phạm vi này vẫn sử dụng API REST. Tính năng này có sẵn trên tất cả các kế hoạch.

Claude Desktop, Claude Code, ChatGPT (các gói trả phí, bao gồm Plus, Pro, Business và Enterprise), Cursor, GitHub Copilot, VS Code (thông qua phần mở rộng Copilot), Gemini, Windsurf và Microsoft Copilot Studio đều hỗ trợ MCP kể từ giữa năm 2026. OpenAI, Google, Microsoft và một số công ty khác đã gia nhập Agentic AI Foundation thuộc Linux Foundation, tổ chức quản lý tiêu chuẩn này. Hỗ trợ từ phía khách hàng rất rộng rãi nhưng không đồng đều: không phải mọi khách hàng đều hỗ trợ tất cả các tính năng của MCP (ví dụ: tài nguyên và lời nhắc chậm hơn so với các lệnh gọi công cụ).

Đúng vậy, và việc bao bọc (wrapping) một API hiện có là phương pháp phổ biến nhất. Máy chủ xác thực với API, ánh xạ một tập hợp các điểm cuối đã chọn sang các công cụ, và công bố tên, mô tả cùng các lược đồ JSON cho từng điểm cuối. Hãy tránh ánh xạ mọi điểm cuối. Mô tả của mỗi công cụ sẽ được đưa vào bối cảnh của mô hình ở mỗi lượt, do đó một danh mục lớn sẽ tiêu tốn token và mở rộng diện tích tiếp xúc cho việc chèn lệnh vào lời nhắc. Chỉ nên công khai những hành động mà bạn sẵn sàng cho phép một tác nhân thực hiện mà không cần giám sát.

Sử dụng ít nhất có thể tùy theo yêu cầu của trường hợp sử dụng. Nhóm kỹ thuật của Anthropic báo cáo rằng tổng hợp các định nghĩa công cụ và kết quả có thể tiêu tốn hơn 50.000 token trước khi mô hình thậm chí đọc được yêu cầu của người dùng. Các khuyến nghị từ cộng đồng đều cho rằng nên giới hạn ở mức 10-20 công cụ trên mỗi máy chủ trước khi các kỹ thuật quản lý bối cảnh (tiết lộ dần dần, tìm kiếm công cụ) trở nên cần thiết. Nếu số lượng công cụ vượt quá 50, hãy chia thành nhiều máy chủ chuyên dụng theo mục đích.

Không, mặc dù hầu hết các triển khai đều có một máy chủ MCP. Một máy chủ MCP có thể cung cấp truy cập vào các tệp cục bộ, cơ sở dữ liệu hoặc logic xử lý trong quá trình mà không cần đến API HTTP, đây chính là cách giao thức truyền tải stdio ban đầu được thiết kế. Điều MCP luôn cần là một thành phần để thực thi công cụ. Việc bao bọc (wrap) một API hiện có đơn giản là con đường nhanh nhất, vì các cơ chế xác thực, xác minh và xử lý lỗi đã được tích hợp sẵn.

Các công cụ là các hành động có thể gọi (tạo công việc, chạy truy vấn) và gần giống nhất với các điểm cuối API. Tài nguyên là dữ liệu chỉ đọc mà mô hình có thể đưa vào bối cảnh (tệp, bản ghi cơ sở dữ liệu, tài liệu trực tiếp). Các lời nhắc (prompts) là các mẫu hướng dẫn có thể tái sử dụng mà khách hàng AI có thể yêu cầu, chẳng hạn như quy trình làm việc “tóm tắt PR này”. Các công cụ thu hút nhiều sự chú ý nhất, nhưng tài nguyên và lời nhắc mới là những yếu tố giúp MCP khác biệt so với một danh sách gọi hàm đơn thuần: chúng cho phép máy chủ định hình bối cảnh của mô hình, chứ không chỉ các hành động của nó.