MCP là gì: Cách Model Context Protocol hoạt động

LLM đã có thể gọi công cụ từ lâu, nhưng Model Context Protocol (MCP) mang lại một cách có cấu trúc và được chuẩn hóa để thực hiện việc đó.

Tuy vậy, vẫn còn nhiều nhầm lẫn về việc MCP thực sự là gì.

Nhiều người cho rằng MCP là một ứng dụng, một API hoặc một công cụ nào đó, nhưng MCP không phải những thứ này. MCP là một giao thức, và điều đó có một ý nghĩa rất cụ thể.

Hãy phân tích từng phần.

Nếu bạn chỉ muốn xem MCP mở ra những khả năng gì trong thực tế, hãy xem video ngắn này:

Giao thức là gì?

Giao thức đơn giản là một tập hợp các quy tắc xác định cách hai hoặc nhiều hệ thống giao tiếp với nhau.

Bản thân giao thức không tự làm gì cả. Nó chỉ xác định cấu trúc và kỳ vọng của một cuộc trao đổi giữa hai thực thể. Hãy xem nó như một ngôn ngữ chung có các quy tắc ngữ pháp chặt chẽ mà máy tính tuân theo để trao đổi thông tin.

Hệ thống bưu chính cũng làm điều tương tự. Tất cả bưu cục trong một quốc gia nhất định đều tuân theo một định dạng địa chỉ chuẩn để gửi thư.

Hoặc hãy nghĩ về nó như USB-C cho các công cụ AI. Hai mươi năm trước, thị trường tràn ngập các loại cáp sạc và cáp dữ liệu khác nhau. Tương tự, các hệ sinh thái AI đã có nhiều cách khác nhau để truyền công cụ cho các mô hình ngôn ngữ. Các framework như LangChain, Haystack, và Pydantic AI đều định nghĩa định dạng riêng để tích hợp công cụ, nghĩa là nếu một developer muốn viết một bộ công cụ cho Google Maps, họ phải làm việc đó cho từng công nghệ cụ thể.

Để làm rõ hơn, hãy xem giao thức phổ biến nhất, HTTP (Hypertext Transfer Protocol), nền tảng vận hành các website. HTTP định nghĩa, trong số nhiều thứ khác, cách trình duyệt (client) yêu cầu một trang web từ web server và cách server cần phản hồi.

Đây là một ví dụ về chu trình request-response của HTTP:

1. Trình duyệt tạo một HTTP request

Khi bạn nhập https://example.com vào trình duyệt, trình duyệt gửi một HTTP request có cấu trúc tới web server:

Đây là các tham số và giá trị HTTP được dùng trong ví dụ của chúng ta:

"GET" – Đây là hành động (yêu cầu một trang web).
"/index.html" – Trang web cụ thể đang được yêu cầu.
"HTTP/1.1" – Phiên bản giao thức đang được sử dụng.
"Host: example.com" – Tên miền của website.
"User-Agent: Mozilla/5.0" – Thông tin về trình duyệt tạo request.

Web server biết cách diễn giải request này vì HTTP chuẩn hóa định dạng này. Nó hiểu “ngôn ngữ” này.

2. Server phản hồi bằng giao thức HTTP

Server xử lý request và gửi lại một HTTP response có cấu trúc:

"HTTP/1.1 200 OK" – Mã phản hồi (200 nghĩa là thành công).
"Content-Type: text/html" – Loại nội dung được gửi lại.
"Content-Length: 512" – Kích thước của response.
HTML Content – Nội dung trang web thực tế (chỉ có một tiêu đề "Welcome to Example.com")

Quan trọng: bản thân HTTP không lưu trữ các trang web hoặc hiển thị chúng. Nó chỉ định nghĩa các quy tắc về cách trình duyệt web và web server được phép giao tiếp. Bất kỳ hệ thống nào tuân theo các quy tắc đó đều có thể giao tiếp qua Internet được định nghĩa bởi HTTP.

MCP hoạt động như một giao thức như thế nào

Bây giờ, hãy áp dụng cùng cách suy nghĩ đó cho MCP (Model Context Protocol).

MCP là một giao thức để các AI agent giao tiếp với công cụ và nguồn dữ liệu bên ngoài. Giống như HTTP, nó không tự lưu trữ dữ liệu hoặc thực thi tác vụ. Nó chỉ định nghĩa một cách chuẩn hóa để AI yêu cầu và truy xuất thông tin từ công cụ.

Bạn có thể hỏi, những “công cụ” đó là gì?

Trong ngữ cảnh của LLM, công cụ là các hệ thống, API hoặc dịch vụ bên ngoài mà AI có thể tương tác để mở rộng khả năng của nó vượt ra ngoài việc chỉ tạo văn bản. Chúng cho phép các AI agent lấy dữ liệu theo thời gian thực, đặt lịch hẹn hoặc nhắn tin cho bạn bè của bạn, khiến chúng hữu ích hơn nhiều cho các nhu cầu trong thực tế.

Giả sử bạn hỏi một AI agent:

“Bây giờ ở London là mấy giờ?”

Vì bản thân AI không biết câu trả lời đúng, do các mô hình AI có ngày giới hạn tri thức (tháng 10 năm 2023 đối với các mô hình của OpenAI), nó cần lấy dữ liệu trực tiếp từ một dịch vụ thời gian. Nhưng thay vì dùng HTTP để yêu cầu một trang web, AI dùng MCP để yêu cầu dữ liệu thời gian.

Đây là điều xảy ra:

1. AI agent tạo một MCP request tới dịch vụ thời gian (ví dụ)

"method": "tools.call" → AI đang gọi một công cụ bên ngoài.
"tool": "get_time" → Tên của công cụ mà AI muốn sử dụng.
"args": { "location": "London" } → Các tham số đầu vào cụ thể.

Cũng như trong HTTP, request này tuân theo một định dạng chặt chẽ để bất kỳ công cụ nào tương thích với MCP đều biết chính xác cách diễn giải nó.

2. MCP time server phản hồi

Công cụ bên ngoài (time server) tuân theo các quy tắc phản hồi của MCP và gửi lại:

"status": "success" → Xác nhận request đã được xử lý đúng.
"result" → Chứa dữ liệu thời gian thực tế.

Bây giờ, AI agent có thể lấy dữ liệu này và soạn một câu trả lời thực tế cho người dùng như sau:

“Thời gian hiện tại ở London là 12:20 PM (GMT).”

Để tóm tắt và làm rõ nhầm lẫn:

“MCP là một ứng dụng.” → Không, MCP là một tập hợp các quy tắc. Bạn cần phần mềm AI và công cụ triển khai MCP để thực sự sử dụng nó, giống như ứng dụng Instagram cần các server Instagram đang hoạt động để phản hồi HTTP request và cung cấp dữ liệu.

“MCP là một cơ sở dữ liệu.” → Không, MCP không lưu trữ dữ liệu. Nó giúp các AI agent giao tiếp với cơ sở dữ liệu hoặc API.

“MCP giống như một API.” → Không hẳn. API là một cách cụ thể để tương tác với một hệ thống, trong khi giao thức (như MCP hoặc HTTP) định nghĩa một cách phổ quát để nhiều hệ thống khác nhau có thể giao tiếp. MCP là một ngôn ngữ mà một hệ thống AI có thể dùng để tương tác với nhiều API thực tế (thời gian, cơ sở dữ liệu, Stripe, Slack, v.v.).

Vì sao MCP đáng chú ý

Bây giờ khi chúng ta biết MCP là một cách chuẩn hóa để phần mềm AI tương tác với công cụ và ứng dụng bên ngoài, và MCP không phải là API, hãy tìm hiểu vì sao cộng đồng developer AI (bao gồm cả chúng tôi) hào hứng với nó.

Vì MCP không phải là API mà cho phép ứng dụng AI tương tác với các API thực tế ở quy mô lớn, nó giúp các dự án cần kết nối với nhiều hệ thống bên ngoài bắt đầu nhanh hơn. Công cụ cũng trao cho mô hình phạm vi tác động, và điều đã xảy ra trong sự cố OpenAI Hugging Face cho thấy phạm vi đó trông như thế nào khi nó vượt quá tác vụ. Để làm việc này, đôi khi developer cần đi qua một chu trình phát triển tích hợp API đầy đủ, nhưng hiện nay họ thường dùng các thư viện hoặc dự án mã nguồn mở có sẵn (ví dụ, trên GitHub) cung cấp chức năng cần thiết.

Việc dùng các thư viện này giúp khởi động phát triển nhanh hơn, nhưng tích hợp chúng đúng cách với hệ thống của bạn (nếu hệ thống không tương thích với implementation bạn tìm thấy trên GitHub) vẫn đòi hỏi công sức để công cụ hoạt động với AI.

Với MCP, một khi framework đã sẵn sàng, việc thêm một tích hợp mới (ví dụ, tích hợp Google Drive) có thể chỉ là kết nối tới Google Drive MCP server bằng vài dòng code. Bạn sẽ không gặp vấn đề tương thích vì cả hai bên đều dùng cùng một giao thức: MCP.

Hãy so sánh hai cách tiếp cận để thấy sự khác biệt rõ hơn.

Tích hợp tiêu chuẩn so với dùng Model Context Protocol (MCP)

Để làm cho so sánh này cụ thể, hãy xem cách thêm quyền truy cập file Google Drive vào một AI Agent, trước tiên theo cách thủ công, sau đó bằng công cụ tương thích với MCP.

Tích hợp tiêu chuẩn

1. Tìm và điều chỉnh thư viện: Bạn tìm một Google Drive API client hoặc dự án mã nguồn mở. Google cung cấp các thư viện client (ví dụ Google Drive API for Python); bạn đưa thư viện này vào dự án. Bạn vẫn cần đảm bảo nó hoạt động với môi trường AI của bạn.

2. Triển khai logic: Bạn viết các function để, chẳng hạn, tìm kiếm file hoặc lấy một tài liệu từ Drive. Khi AI cần thứ gì đó, nó phải gọi các function này. Bạn định dạng request của AI thành các API call đặc thù của Google Drive. Sau khi nhận response từ Google, bạn trích xuất nội dung để đưa lại vào context của AI.

3. Xử lý lỗi và trường hợp ngoại lệ: Thêm code để xử lý các trường hợp như “không tìm thấy file”, lỗi quyền truy cập hoặc giới hạn tốc độ API. Nếu API của Google trả về lỗi, bạn bắt lỗi đó và có thể phản hồi bằng một thông báo xin lỗi hoặc yêu cầu AI diễn đạt lại. Bạn cũng cần bảo vệ để AI của bạn không gửi quá nhiều request quá nhanh.

4. Bảo trì: Theo thời gian, nếu Google cập nhật API hoặc thư viện của họ, bạn phải cập nhật code của mình. Nếu bạn tìm thấy lỗi trong thư viện, bạn có thể phải vá lỗi hoặc tìm nguồn khác. Về cơ bản, bạn trở thành người bảo trì tích hợp Google Drive này bên trong ứng dụng AI của mình.

Quy trình này áp dụng cho các công cụ khác: muốn thêm Slack hoặc một cơ sở dữ liệu vào AI của bạn? Bạn cần lặp lại toàn bộ quy trình cho từng công cụ.

Tích hợp MCP

Bây giờ hãy xem quy trình đó sẽ như thế nào khi dùng MCP.

Trước tiên, hãy định nghĩa các khái niệm chính:

Client – một ứng dụng AI (ChatGPT, Claude app, Quickchat AI) thiết lập kết nối tới một hoặc nhiều server và yêu cầu thông tin hoặc hành động để thực hiện các tác vụ do người dùng đưa ra.

Server – Mỗi server có thể kết nối tới một thứ như cơ sở dữ liệu, một API (Google Drive) và định nghĩa một tập hợp các “công cụ” hoặc dữ liệu mà nó có thể cung cấp. Trong trường hợp này, server là một chương trình phơi bày các công cụ và năng lực này cho Client (ứng dụng AI).

Developer, tùy vào việc họ muốn làm gì, có thể chọn đứng ở một trong hai phía: xây dựng server để phơi bày dữ liệu, hoặc xây dựng AI client có thể giao tiếp với bất kỳ server nào. Hầu hết muốn lựa chọn thứ hai, nhưng hãy bắt đầu với phía server để hiểu MCP hoạt động từng bước như thế nào:

• Khởi tạo một MCP server. Developer hoặc quản trị viên hệ thống thiết lập một MCP server cho một công cụ hoặc nguồn dữ liệu nhất định. MCP server thường chỉ là một chương trình nhỏ triển khai đặc tả MCP. Ví dụ, có một server Google Drive MCP dựng sẵn có sẵn, biết cách tìm kiếm và lấy tài liệu.

  Khi khởi tạo server, bạn cấp cho nó quyền truy cập vào hệ thống đích (Google Drive). Sau đó server phơi bày một tập hợp công cụ tương ứng với các hành động hoặc truy vấn mà nó có thể xử lý. Về cơ bản, đây là một API adapter nói MCP ở một phía và nói giao thức dịch vụ gốc ở phía còn lại.

  Khi server đang chạy, nó chờ các request.

• Kết nối một LLM (client) tới một MCP server. Tiếp theo, ứng dụng AI (phía “client”) cần kết nối tới server đó. Trong thực tế, nếu bạn dùng một nền tảng AI hỗ trợ MCP (chẳng hạn Claude Desktop), bạn sẽ cấu hình nó bằng địa chỉ hoặc lệnh để khởi động server. Sau khi kết nối, client thiết lập một session với server theo handshake của MCP. Nếu bạn dùng giao diện của Claude, bạn sẽ thấy Claude được “connected” tới một số MCP server nhất định (UI có thể hiển thị các connector khả dụng).

Đây là giao diện trong Claude UI

• Khám phá các công cụ khả dụng. Khi kết nối đã được thiết lập, việc đầu tiên cần làm là tìm hiểu server cung cấp những gì (đôi khi việc này xảy ra tự động sau khi bạn kết nối tới server). MCP client gửi một request tools/list tới server (được định nghĩa trong giao thức). Server trả lời bằng danh sách các công cụ có sẵn, mỗi công cụ có các chi tiết như tên, mô tả và input schema.

  Ví dụ, một server có thể phản hồi rằng nó có các công cụ create_file(path, content), read_file(path), và search_files(query) khả dụng. Sau đó client cung cấp thông tin này cho LLM. Trong nhiều implementation, client sẽ định dạng các mô tả công cụ này và đưa chúng vào context của mô hình (ví dụ, thêm vào system prompt: “Bạn có quyền truy cập các công cụ sau… [danh sách công cụ]”).

Đây là một system prompt của AI cùng với tin nhắn của người dùng yêu cầu thời gian hiện tại

Khi các công cụ MCP được triển khai, một công cụ tên “get_current_time” được tích hợp, cho phép AI truy cập một tài nguyên bên ngoài và lấy thời gian chính xác ở London

Điều này nghĩa là bạn không cần suy nghĩ trước và lập trình sẵn tất cả hành động tiềm năng mà ứng dụng AI của bạn có thể cần để hoàn thành một tác vụ nào đó. Với MCP, AI có thể khám phá tất cả hành động có thể có ngay trong lúc chạy bằng cách hỏi một MCP server và chọn bất cứ thứ gì cần thiết.

• Dùng một công cụ thông qua MCP. Khi AI cần thực hiện một hành động hoặc lấy dữ liệu, nó sẽ gọi một công cụ qua MCP. Từ góc nhìn của AI (đặc biệt với các mô hình như Claude hỗ trợ native việc dùng công cụ), nó sẽ quyết định trong quá trình suy luận: “Tôi nên gọi công cụ X với các tham số này.” MCP client ghi nhận ý định đó và gửi một request tools/call theo định dạng MCP tới server phù hợp (Google Drive MCP server).

• MCP server đóng vai trò cầu nối. Nó nhận một request có cấu trúc và tuân thủ MCP từ AI agent, ánh xạ request đó tới endpoint Google Drive API đúng, viết lại request thành một Google Drive API call thực tế, thực thi request, xử lý response, sau đó định dạng lại thành một response tuân thủ MCP trước khi gửi lại cho AI agent.

  Điểm đáng chú ý là MCP server tuân theo một cách tiếp cận có cấu trúc để xử lý lỗi, đảm bảo rằng AI Agent có thể diễn giải và hành động hiệu quả dựa trên lỗi đó.

  Giả sử một AI Agent đang dùng một công cụ MCP để tìm một file trong Google Drive. Nếu request bao gồm một file ID không hợp lệ (ví dụ, một chuỗi dài năm ký tự thay vì định dạng được kỳ vọng), MCP server sẽ trả về một thông báo lỗi:

  Thay vì chỉ thất bại, AI Agent có thể lấy response có cấu trúc này và diễn đạt lại thành phản hồi thân thiện với người dùng:

  “Có vẻ như file ID bạn cung cấp quá ngắn. Google Drive file ID thường dài 28 ký tự. Bạn có thể kiểm tra lại và thử lần nữa không?”

  Cách tiếp cận này đảm bảo lỗi không dẫn tới ngõ cụt, mà trở thành cơ hội để AI Agent hướng dẫn người dùng đi tới một cách xử lý thành công.

• Trả lời câu hỏi/yêu cầu của người dùng. Khi MCP server trả về kết quả, MCP client chuyển dữ liệu đó lại cho ứng dụng AI. Sau đó mô hình đưa kết quả vào quá trình suy luận hoặc trực tiếp vào đầu ra mà nó tạo cho người dùng.

  Nếu người dùng yêu cầu tạo một file Google Sheets mới, response của server (chứa file ID và một link được tạo) sẽ được đưa vào mô hình. Sau đó mô hình sẽ trả lời người dùng: “Tin tốt, file Google Sheets mới của bạn đã sẵn sàng. Bạn có thể truy cập tại đây: [link].”

Trong suốt quá trình này, AI vẫn kiểm soát luồng: nó quyết định khi nào gọi một công cụ và cách dùng kết quả để hình thành câu trả lời. Trong khi đó, developer không phải điều phối thủ công các bước này, framework MCP và mô hình AI xử lý việc đó. Kết quả cuối cùng là người dùng có thể yêu cầu AI trả lời các câu hỏi hoặc thực hiện các tác vụ phức tạp cần thông tin hoặc hành động bên ngoài, và AI có thể tự động thực hiện chúng qua MCP rồi trả lại kết quả.

Lợi ích của việc dùng MCP

Hãy chú ý cách tiếp cận này trừu tượng hóa nhiều chi tiết: client không xử lý API key hoặc HTTP status code, các phần đó do MCP server xử lý.

Điểm chính là sự đơn giản tại điểm tích hợp: chúng ta “yêu cầu” khách hàng, và chúng ta nhận được khách hàng. Logic về cách lấy dữ liệu đó được đóng gói ở nơi khác. Điều đó nghĩa là developer làm việc ở phía AI không cần viết HTTP call mới cho từng hành động mới, họ chỉ gọi công cụ theo tên. Phần việc nặng (xác thực, gọi endpoint của Google Drive, định dạng response) được thực hiện trong code MCP server, có thể tái sử dụng và được chuẩn hóa.

Đây là tóm tắt các lợi ích chính:

• Giảm code kết nối đặc thù theo API. Trước MCP, để AI dùng một dịch vụ bên ngoài thường cần viết nhiều code “kết nối”: gọi API, chuyển đổi response thành văn bản mà mô hình có thể xử lý, rồi phân tích đầu ra của mô hình để có thể gọi một API khác, v.v. Với MCP, phần lớn lớp kết nối đó được loại bỏ. Client của mô hình và server xử lý trao đổi dữ liệu theo cách có cấu trúc, nên bạn không cần chuyển đổi thủ công các định dạng khác (như JSON) sang văn bản hoặc ngược lại, giao thức làm việc đó. Bạn cũng không cần viết logic để quyết định khi nào gọi cái gì. AI (được hướng dẫn bởi mô tả công cụ và suy luận hoặc prompt của chính nó) làm việc đó.

• Connector có thể tái sử dụng và chia sẻ, thay vì API wrapper dùng một lần. Với MCP, bạn viết một tích hợp một lần và có thể tái sử dụng nó trên nhiều dự án và hệ thống AI. Ví dụ, bạn có thể tạo một MCP server cho wiki nội bộ của công ty. Bất kỳ ứng dụng AI nào hỗ trợ MCP đều có thể kết nối tới server đó để truy vấn wiki. Bạn không cần triển khai lại “tìm kiếm wiki” cho từng chatbot AI mới hoặc từng nhà cung cấp LLM khác nhau. Khả năng tái sử dụng này là một thay đổi so với trước đây, khi mỗi đội có thể viết một tích hợp hơi khác nhau cho cùng một API. MCP khuyến khích một thư viện connector có thể được chia sẻ và cải thiện chung.

• Tích hợp plug-and-play với các LLM khác nhau. MCP độc lập với mô hình. Giao thức không quan tâm client là Claude, GPT-4, DeepSeek, hay bất kỳ mô hình tương lai nào, miễn là client có thể xử lý giao diện MCP. Trong tương lai, nếu bạn muốn chuyển sang một mô hình khác, bạn có thể làm vậy mà không cần viết lại toàn bộ tích hợp.

• Bảo trì dễ hơn. Vì đây là một tiêu chuẩn mở, có một cộng đồng ngày càng lớn đóng góp các server dựng sẵn (cho cơ sở dữ liệu, API phổ biến, v.v.) mà bạn có thể tận dụng thay vì xây dựng từ đầu. Khi bạn tích hợp thêm nhiều hệ thống, MCP giúp tránh tình trạng “spaghetti” của nhiều tích hợp điểm-điểm. Và bạn không cần theo dõi tất cả cập nhật API từ các nhà cung cấp khác.

Tích hợp API có trở nên lỗi thời không?

Cả tích hợp API truyền thống và MCP đều có vai trò riêng. Cách tiếp cận tốt nhất có thể phụ thuộc vào bản chất dự án, chuyên môn của đội và mục tiêu dài hạn.

Nếu bạn chỉ cần tích hợp với một hoặc hai dịch vụ bên ngoài và các tương tác tương đối đơn giản, tích hợp API trực tiếp thường là giải pháp nhanh nhất. Nếu web app của bạn chỉ cần xác minh một Stripe payment token ở bước checkout, gọi trực tiếp API của Stripe là đơn giản và hiệu quả. Đưa MCP vào trong tình huống này có thể là quá mức cần thiết. Bạn có thể kết nối một AI Agent với bất kỳ REST API có tài liệu nào bằng một HTTP Action đã được kiểm duyệt, hoặc dùng một tích hợp một nhấp chuột như Google Sheets để ghi lại lead và yêu cầu demo, mà không cần chạy một MCP server.

Trong các trường hợp bạn cần kiểm soát rất chặt chẽ request/response (để tối ưu hiệu năng, xử lý dữ liệu đặc biệt hoặc giao thức độc quyền), viết trực tiếp tới API có thể tốt hơn. Tích hợp truyền thống cho phép bạn dùng tất cả tính năng nâng cao của một API và điều chỉnh các call chính xác theo nhu cầu. Nếu một API có yêu cầu bất thường hoặc nếu bạn muốn tránh mọi lớp trừu tượng để có độ rõ ràng và kiểm soát tối đa, cách truyền thống là phù hợp.

Để xem một ví dụ cụ thể về cách công cụ MCP được phơi bày cho một AI Agent production cùng với các API action tùy chỉnh, hãy xem cách Quickchat AI Agents kết hợp cả hai cách tiếp cận. Phần thảo luận sâu hơn về thời điểm dùng MCP, từng AI Actions riêng lẻ hoặc “Generate from Text” nằm trong API cho AI Agent: Từ MCP đến endpoint tùy chỉnh. Để tự thử, hãy làm theo hướng dẫn từng bước để kết nối AI Agent của bạn tới một remote MCP server để nó gọi một công cụ trực tiếp giữa cuộc trò chuyện.

Danh sách MCP server hiện có

Nếu bạn muốn bắt đầu với MCP, hãy xem các thư mục MCP server bên dưới:

• https://github.com/modelcontextprotocol/servers
• https://smithery.ai

Bạn cũng có thể chạy một server mà không cần viết code: mọi Quickchat AI Agent đều có thể được chuyển thành một MCP server với một hosted URL mà Claude, ChatGPT và Cursor gọi như một công cụ. Kết nối cũng hoạt động theo chiều ngược lại: một Quickchat AI Agent có thể gọi MCP server được host bởi vendor dưới dạng công cụ của nó, đây là cách trợ lý lập lịch AI được xây dựng trên MCP server của Calendly kiểm tra tình trạng còn trống thực tế và đặt lịch họp từ chat, cũng như cách một Notion AI chatbot trả lời từ một help center trực tiếp và ghi lại yêu cầu hỗ trợ vào một cơ sở dữ liệu Notion.

Quickchat AI cũng vận hành một remote MCP server cho tài khoản riêng của bạn. Kết nối nó với ChatGPT, Claude, Cursor, hoặc Codex và bạn có thể quản lý AI Agents của mình từ đó: analytics, bản ghi cuộc trò chuyện, cập nhật knowledge base và tạo Agent mới, phía sau một lần đăng nhập OAuth duy nhất. Hướng dẫn thiết lập cho từng client nằm trong Quản lý AI Agent của bạn từ ChatGPT, Claude và Codex bằng MCP.

FAQ

Nó chỉ hoạt động với Claude sao?

MCP độc lập với mô hình. Giao thức không quan tâm client là Claude, GPT-4, một biến thể LLaMA chạy cục bộ, hay bất kỳ mô hình tương lai nào, miễn là client có thể xử lý giao diện MCP. Điều này nghĩa là bạn không bị khóa vào một nhà cung cấp AI duy nhất khi xây dựng tích hợp công cụ.

MCP khác gì so với việc cung cấp trước cho mô hình toàn bộ thông tin nó cần? Vì sao không nhồi dữ liệu vào prompt?

MCP khác về bản chất so với việc nhồi dữ liệu vào prompt của mô hình, vì nó cho phép mô hình lấy thông tin động khi cần, thay vì làm việc với một prompt tĩnh đã tải sẵn. Nhồi văn bản vào prompt gặp giới hạn, vì các mô hình AI có cửa sổ context cố định, nghĩa là quá nhiều dữ liệu có thể khiến các chi tiết quan trọng bị mất, làm chậm phản hồi và tăng chi phí API (do các mô hình định giá theo token được nhà cung cấp LLM sử dụng). Cách đó cũng chỉ cung cấp tri thức tại một thời điểm duy nhất, trong khi MCP cho phép truy cập thời gian thực vào dữ liệu bên ngoài đang hoạt động và cho phép AI thực hiện hành động, không chỉ đọc thông tin. Một AI với prompt được nạp đầy có thể biết chi tiết khách hàng nhưng không thể cập nhật bản ghi hoặc xử lý giao dịch.

Nếu chúng ta kết nối hàng chục công cụ với AI thì sao? Điều đó có làm mô hình quá tải hoặc khiến nó dùng sai công cụ không?

Điều này phụ thuộc vào implementation, nhưng đúng là các LLM hiện tại có giới hạn về mức độ phân biệt và lựa chọn giữa nhiều phương án. Nếu bạn cung cấp cho một mô hình, chẳng hạn, 50 công cụ khả dụng, có rủi ro nó có thể chọn sai công cụ. Bản thân cách tiếp cận MCP không buộc bạn tải mọi thứ cùng lúc. Bạn nên kết nối các công cụ liên quan dựa trên context. Một best practice là chỉ kết nối các công cụ cần thiết cho tác vụ/lĩnh vực hiện tại và tận dụng hợp tác đa agent, một dạng định tuyến công cụ hoặc một agent trước tiên quyết định nên xem xét tập con công cụ nào.

MCP so với Function Calling

Function calling truyền thống (như trong API của OpenAI hoặc các LLM khác) cho phép developer định nghĩa một tập hợp function, cung cấp định nghĩa của chúng cho mô hình, và để mô hình “gọi” chúng theo tên cùng với argument. Đây là một bước tiến lớn cho tích hợp AI, nhưng nó có giới hạn. Một khác biệt lớn là thời điểm và cách công cụ được định nghĩa. Trong function calling cổ điển, tất cả function khả dụng phải được khai báo trước (ở thời điểm thiết kế) trong prompt hoặc thông qua API. Mô hình chỉ có thể gọi các function cố định đó. Trong MCP, công cụ có thể được khám phá khi chạy, AI có thể truy vấn những gì đang có và thậm chí nhận công cụ mới giữa session.

MCP so với GPT Actions & Plugins

GPT Actions/Plugins đề cập tới hệ sinh thái của OpenAI, nơi bạn có thể bật plugin (như trình duyệt web hoặc trình đọc PDF) cho ChatGPT, hoặc các “GPTs” (agent ChatGPT tùy chỉnh) có thể dùng công cụ. Những thứ đó từng rất thú vị, nhưng chúng đòi hỏi phát triển tùy chỉnh cho từng plugin và bị giới hạn trong các nền tảng của OpenAI. Nếu bạn muốn có một plugin ChatGPT cho một tác vụ, bạn phải tạo một API và một manifest, rồi đi qua quy trình phê duyệt của OpenAI hoặc ít nhất bật thủ công. Mỗi plugin về cơ bản là một silo, một plugin thời tiết, một plugin du lịch, v.v., mỗi plugin có endpoint và logic riêng. MCP cải thiện khái niệm này bằng cách hợp nhất và mở nó ra.

MCP so với RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG) là một kỹ thuật trong đó LLM được bổ sung bằng một knowledge base bên ngoài. Thông thường, RAG liên quan đến một cơ sở dữ liệu vector hoặc chỉ mục tìm kiếm: truy vấn của người dùng được dùng để lấy tài liệu hoặc dữ liệu liên quan (bằng tìm kiếm ngữ nghĩa hoặc phương pháp khác), và các tài liệu đó được cung cấp cho mô hình như context bổ sung để “đọc” khi tạo câu trả lời. RAG tập trung vào việc cung cấp cho mô hình tri thức mà nó vốn không có, đặc biệt hữu ích cho hỏi đáp sự kiện hoặc thông tin đặc thù theo lĩnh vực. Tuy nhiên, RAG chỉ đọc, mô hình truy xuất các đoạn văn bản, nhưng không thực hiện hành động ngoài việc truy xuất.

Ngược lại, MCP tập trung vào thực hiện hành động hoặc thực hiện các thao tác tùy ý, không chỉ truy xuất context thông tin. Với MCP, AI có thể làm việc: ghi vào cơ sở dữ liệu, gửi email, thực thi code, v.v. Nó không bị giới hạn ở việc lấy tri thức, nó có thể kích hoạt thay đổi trong các hệ thống bên ngoài. Vì vậy, theo nhiều cách, RAG và MCP phục vụ các mục đích khác nhau.