MCP là gì? và vì sao người làm automation nên quan tâm?

MCP là gì và bài toán mà nó thực sự giải quyết

Model Context Protocol (MCP) là một tiêu chuẩn mở do Anthropic công bố chính thức vào tháng 11 năm 2024. David Soria Parra và Justin Spahr-Summers xây dựng nó với một mục tiêu rất thực dụng: chuẩn hóa cách ứng dụng AI kết nối với dữ liệu và phần mềm bên ngoài.

Nghe thì có vẻ giống một API mới. Nhưng nếu nhìn MCP như một API nữa để học, bạn sẽ bỏ qua ý nghĩa lớn nhất của nó. MCP là một lớp giao thức chung giữa AI application và thế giới công cụ: database, source code, tài liệu, chat nội bộ, browser automation, hệ thống vận hành.

Vấn đề cũ là thế này: mỗi LLM, mỗi AI Agent framework, mỗi IDE, mỗi nền tảng automation đều có cách riêng để gọi Tool, truyền context và xác nhận hành động. Bạn tích hợp GitHub cho Claude theo một cách. Muốn Agent dùng OpenAI gọi GitHub, bạn viết thêm lớp khác. Đưa nó vào Cursor, Replit, LangChain hay n8n lại có một bài toán adapter khác.

Đó là bài toán M×N integration: có M ứng dụng AI và N nguồn dữ liệu hoặc công cụ, số kết nối cần xử lý tăng rất nhanh. Đội automation nào từng tự viết Custom API Wrapper, Custom Node cho n8n, hoặc Tool schema riêng cho từng model sẽ hiểu ngay cảm giác này: logic nghiệp vụ vốn đơn giản, nhưng lớp kết nối làm dự án phình ra.

MCP đưa ra một đề nghị khá rõ ràng: thay vì để mỗi AI application nói một thứ tiếng với từng service, tất cả cùng dùng một giao thức chung dựa trên JSON-RPC 2.0. Một MCP Server có thể phơi bày dữ liệu và hành động theo chuẩn đó. Host nào hỗ trợ MCP có thể kết nối với Server ấy qua Client của nó.

Nếu REST API là cách phần mềm nói chuyện với phần mềm, MCP là cách AI application tiếp cận dữ liệu và Tools theo một giao thức thống nhất.

Nhiều người ví MCP là USB-C cho AI. So sánh này có ích nếu hiểu đúng: USB-C không khiến mọi thiết bị tự nhiên tương thích về nghiệp vụ, cũng không giải quyết quyền truy cập hay bảo mật. Nó chuẩn hóa cổng kết nối. MCP cũng vậy. Nó không biến một hệ thống dữ liệu lộn xộn thành hệ thống sạch, nhưng giảm đáng kể chi phí nối AI vào hệ thống đó.

MCP cũng được lấy cảm hứng trực tiếp từ Language Server Protocol (LSP) của Microsoft. LSP từng chuẩn hóa cách IDE tích hợp các ngôn ngữ lập trình. Nhờ đó, khả năng như autocomplete, diagnostics hay go-to-definition không phải được làm lại từ đầu cho mọi tổ hợp editor và programming language. MCP mang tinh thần tương tự sang AI: chuẩn hóa giao diện để AI application sử dụng context và khả năng hành động từ service bên ngoài.

Tôi cho rằng đây là lý do MCP đáng để người làm automation theo dõi nghiêm túc. Nó không phải phép màu thay thế API. Nó là một cách giảm ma sát kiến trúc khi automation bắt đầu có Agent, LLM và các hành động bán tự chủ.

Kiến trúc MCP: Host, Client và Server

Để hiểu MCP, đừng bắt đầu bằng danh sách SDK hay repo. Hãy giữ một mental model gồm ba thành phần: Host, Client và Server.

Host là nơi người dùng làm việc

Host là ứng dụng AI khởi tạo kết nối và điều phối trải nghiệm người dùng. Claude Desktop, Cursor và các AI IDE là ví dụ dễ hình dung. Người dùng mở Host, đặt câu hỏi, chọn workflow, xem kết quả và xác nhận hành động khi cần.

Host không nhất thiết là một chatbot. Nó có thể là IDE, AI Agent runtime, ứng dụng desktop hoặc một lớp điều phối trong sản phẩm nội bộ. Điều cần nhớ: Host là bên quyết định trải nghiệm, quyền kết nối và cách đưa thông tin từ MCP Server vào cuộc hội thoại hay workflow.

Client là đầu nối nằm trong Host

Client nằm bên trong Host và duy trì quan hệ 1:1 với một MCP Server. Đây là chi tiết kỹ thuật nhỏ nhưng rất quan trọng. Host có thể kết nối nhiều Server; mỗi kết nối được một Client quản lý.

Hãy hình dung Host là bảng điều khiển, Client là từng dây cáp, còn MCP Server là thiết bị được cắm vào. Nếu Claude Desktop kết nối GitHub MCP Server và Postgres MCP Server, Host sẽ có các Client tương ứng để giao tiếp với từng Server.

Server phơi bày dữ liệu và khả năng hành động

MCP Server là service độc lập cung cấp context hoặc khả năng thực thi cho Host. Một Server có thể kết nối Postgres, GitHub, Slack, Google Drive hoặc Puppeteer. Nó không cần biết model nào đang trả lời người dùng. Nó chỉ biết mình cần cung cấp gì qua giao thức MCP.

Đây là điểm làm kiến trúc bớt dính chặt. Logic truy vấn Postgres, đọc repository, tìm file hoặc điều khiển browser có thể nằm trong Server. Host và model thay đổi, Server không nhất thiết phải viết lại theo từng hãng LLM.

Giao tiếp dựa trên JSON-RPC 2.0 giúp các bên có một format thống nhất cho request và response. Với người làm automation, giá trị của chuẩn này nằm ở tính dự đoán được: thay vì thiết kế một format Tool Calling riêng cho từng nơi, bạn làm theo một hợp đồng giao thức đã được hệ sinh thái dùng chung.

Đừng nhầm kiến trúc này với việc MCP Server “làm AI”. Server thường không cần suy luận như LLM. Nó cung cấp dữ liệu, prompt template hoặc function để Host và model sử dụng. Sự tách biệt ấy là nền móng để Agent không bị biến thành một khối code vừa suy luận, vừa chứa credential, vừa query database, vừa điều khiển browser.

Ba MCP primitives: Resources, Prompts và Tools

Phần dễ gây nhầm lẫn nhất là nhiều người gom mọi thứ vào chữ “Tool”. MCP tách khá rõ ba nhóm khả năng từ Server: Resources, Prompts và Tools. Tách đúng ngay từ đầu sẽ giúp bạn thiết kế automation an toàn hơn.

Resources: dữ liệu thụ động do application kiểm soát

Resources là dữ liệu hoặc context theo hướng read-only. Đây có thể là nội dung tài liệu, dữ liệu từ nguồn bên ngoài hoặc thông tin mà application đọc để đưa vào tác vụ.

Từ “passive” rất quan trọng. Resource không phải lời mời cho model tự ý sửa hệ thống. Nó là thứ để đọc, tham chiếu và lập luận. Nếu Agent cần hiểu thông tin trong Google Drive, kiểm tra trạng thái từ Postgres hoặc tham khảo source code, Resource là abstraction hợp lý hơn việc biến mọi truy vấn đọc thành Tool thực thi.

Về thiết kế, tôi thích coi Resources như lớp kiến thức có địa chỉ rõ ràng. Khi context bị sai, bạn biết phải kiểm tra source nào. Khi quyền truy cập có vấn đề, bạn biết policy nằm ở resource layer thay vì lẫn trong prompt.

Prompts: workflow template do người dùng kiểm soát

Prompts là các mẫu prompt và quy trình được đóng gói sẵn, do người dùng kiểm soát. Đây là primitive khá hay vì nó thừa nhận một sự thật: nhiều workflow có cấu trúc lặp lại, và người dùng cần một cách chọn đúng quy trình mà không phải gõ lại chỉ dẫn dài.

Ví dụ, một đội vận hành có thể đóng gói prompt review incident, prompt phân tích issue từ GitHub, hoặc prompt chuẩn bị dữ liệu trước khi phản hồi khách hàng. Điều đáng giá không phải template “thông minh” hơn. Giá trị nằm ở việc workflow được mô tả rõ và có thể tái sử dụng.

Nếu bạn từng xây automation bằng n8n, hãy liên tưởng Prompts với một entry point có chủ đích. Nhưng Prompts không thay thế Workflow engine. Nó chuẩn hóa cách một MCP Server giới thiệu các quy trình tương tác cho Host.

Tools: hàm để model chủ động kích hoạt

Tools là các hàm thực thi mà AI Model có thể chủ động gọi. Đây là nơi Agent chuyển từ trả lời sang hành động: tìm kiếm, truy vấn, gửi yêu cầu hoặc thực hiện tác vụ mà Server cho phép.

Tool là primitive mạnh nhất và cũng nguy hiểm nhất. Một Tool đọc dữ liệu khác hoàn toàn một Tool tạo ticket, sửa nội dung hay điều khiển browser. Người làm automation không nên vì thấy model gọi được Tool mà cấp quyền rộng cho nó. Model có thể suy luận sai, hiểu sai yêu cầu hoặc bị context dẫn lệch. Quyền hành động phải được thiết kế theo mức rủi ro.

MCP còn có các khả năng phía Client như Sampling, cho phép Server yêu cầu Host thực hiện suy luận LLM lặp; Roots, dùng để giới hạn phạm vi thư mục hoặc URI an toàn; và Elicitation. Những khái niệm này cho thấy MCP không chỉ là một catalog Tool. Nó là giao thức có chủ đích về ranh giới giữa Host, Server, user và model.

Vì sao người làm automation nên quan tâm ngay bây giờ

Người làm automation thường xuất phát từ trigger, action, webhook, API và workflow. Khi thêm LLM vào, cách nghĩ cũ vẫn hữu ích nhưng chưa đủ. LLM không chỉ nhận payload rồi trả payload. Nó cần context, có thể chọn Tool, cần bị giới hạn quyền và cần được theo dõi khi thực hiện chuỗi hành động.

MCP đưa một lớp chuẩn hóa vào đúng chỗ mà automation đang đau: đoạn giữa Agent và hệ thống doanh nghiệp.

Viết một integration, dùng cho nhiều AI application

Trước MCP, một Custom Wrapper thường dính với một runtime cụ thể. Bạn có thể viết function schema cho một LLM, sau đó lại tạo adapter khác khi đổi framework hoặc AI application. Cách này vẫn chạy được, nhất là với prototype. Vấn đề xuất hiện khi doanh nghiệp có nhiều Agent hoặc cần thay model theo chi phí, chất lượng, policy hay yêu cầu sản phẩm.

Với MCP, kỹ sư có thể dựng một MCP Server cho một capability. Các Agent và application có hỗ trợ MCP có thể gọi Tools và đọc Resources theo giao diện đồng nhất. Claude, OpenAI Agents SDK, Zed, Replit, Cursor và các hệ thống n8n hoặc LangChain hỗ trợ MCP là những ví dụ trong hệ sinh thái này.

Đây không có nghĩa “viết một lần là xong mãi mãi”. API của GitHub vẫn đổi, auth vẫn phải quản lý, business rule vẫn phải bảo trì. Nhưng thay vì bảo trì nhiều lớp adapter đặc thù model, bạn có một bề mặt tích hợp chung hơn.

Tách logic nghiệp vụ khỏi model layer

Một Agent tốt cần thay model được mà không kéo sập logic nghiệp vụ. Nếu quy tắc phân quyền, cách query dữ liệu, validation và action nằm chặt trong prompt hoặc function wrapper của một model, hệ thống rất khó phát triển bền vững.

MCP khuyến khích tách các phần đó. Server nắm capability. Host quản lý trải nghiệm và kết nối. Model dùng capability theo giao thức. Cách chia này không tự động tạo ra kiến trúc tốt, nhưng nó buộc đội kỹ thuật nghĩ rõ hơn về ranh giới.

Tôi nghĩ đây là lợi ích thực tế nhất cho người làm automation: bạn bắt đầu thiết kế “capability có thể tái sử dụng”, thay vì thiết kế một prompt biết gọi vài API. Hai cách nhìn này dẫn đến chất lượng hệ thống khác nhau.

Tương thích chéo có ý nghĩa chiến lược

Block, Apollo, Codeium, Sourcegraph, Replit và OpenAI đã chuẩn hóa nền tảng theo MCP. CTO của Block, Dhanji R. Prasanna, nhấn mạnh MCP mở ra kỷ nguyên Agentic systems và loại bỏ gánh nặng cơ học trong tích hợp. Tôi không đọc câu đó như một lời hứa rằng Agent sẽ tự vận hành doanh nghiệp. Tôi đọc nó như một tín hiệu thị trường: phần “dây điện” giữa Agent và toolchain đang được chuẩn hóa.

Automation specialist không cần chạy theo mọi giao thức mới. Nhưng khi một chuẩn được các AI application, IDE và Agent framework cùng hỗ trợ, bỏ qua nó có thể khiến bạn tiếp tục đầu tư vào các wrapper ngắn hạn.

Nếu bạn đang đi từ spreadsheet và workflow cơ bản sang hệ thống tự động hóa có AI, bài Từ Excel đến n8n: Lộ trình automation thực dụng cho SME Việt là nền tảng tốt để nhìn MCP đúng vị trí. MCP không chữa được dữ liệu bẩn, workflow thiếu owner hay quy trình không có rule rõ ràng.

MCP khác gì REST API, Webhook và Function Calling?

MCP không thay thế REST API. Tôi nhắc điều này vì các bài giới thiệu thường làm MCP nghe như một cuộc thay máu toàn bộ hạ tầng. Thực tế, MCP Server vẫn cần kết nối với hệ thống bên dưới, và REST API thường là cách để Server nói chuyện với GitHub, Slack, database gateway hay SaaS.

MCP và REST API

REST API là giao diện phổ quát cho phần mềm gọi phần mềm. Webhook là cơ chế gửi sự kiện. Chúng giải quyết transport và integration ở lớp ứng dụng theo cách quen thuộc.

MCP là giao thức hướng tới việc AI application lấy context, dùng prompt template và gọi action thông qua primitives thống nhất. REST API có thể là implementation detail phía sau MCP Server. Vì vậy, câu hỏi đúng không phải “chọn MCP hay REST API”, mà là “capability nào cần được AI application sử dụng theo chuẩn MCP, capability nào chỉ cần API nội bộ bình thường?”

MCP và Function Calling riêng của từng hãng

Function Calling hoặc Tool Calling của từng LLM rất hữu ích. Chúng giúp model biểu đạt ý định gọi hàm. Nhưng mỗi hãng có schema, runtime convention và integration path riêng. MCP đưa ra lớp giao thức chung hơn giữa Host và Server.

Điểm khác biệt cần nhớ: Function Calling thường xoay quanh model gọi một function; MCP bao gồm Resources, Prompts, Tools và các khả năng tương tác rộng hơn giữa Client với Server. Vì vậy, MCP không phủ nhận Function Calling. Nó đặt Function Calling vào một cấu trúc tích hợp có tính chuẩn hóa hơn.

MCP và Custom Tools trong framework

LangChain Custom Tools hay Custom Node của n8n vẫn có chỗ dùng. Chúng nhanh, tiện và sát với framework. Nếu workflow chỉ sống trong một hệ thống, custom integration có thể là lựa chọn hợp lý.

Nhưng khi capability cần xuất hiện trong nhiều Host hoặc nhiều Agent, Custom Tool bắt đầu tạo nợ kỹ thuật. MCP giúp bạn chuyển phần capability ấy ra một Server độc lập. Framework vẫn quản lý orchestration nếu cần, còn Server giữ một interface chung.

MCP và Agent-to-Agent

MCP tập trung vào kết nối AI application với dữ liệu và Tools. Nó không phải giao thức Agent-to-Agent. Đừng trộn hai lớp này vào một khái niệm. Một Agent có thể sử dụng MCP để đọc dữ liệu và gọi hành động; chuyện Agent giao tiếp, thương lượng hoặc phân chia công việc với Agent khác là bài toán khác.

Ba kịch bản MCP đáng làm thử

DevSecOps và coding workflow

Một AI IDE có thể kết nối với GitHub, Git repository và Postgres thông qua MCP Server. Agent có thể đọc context từ code hoặc dữ liệu, sau đó gọi Tools theo phạm vi được cấp. Giá trị không nằm ở việc “AI tự code”. Giá trị là rút ngắn đoạn chuyển ngữ cảnh giữa IDE, repository, database và trao đổi kỹ thuật.

Nhưng tôi sẽ không cấp cho Tool quyền chỉnh sửa rộng chỉ vì demo trông ấn tượng. DevSecOps có hậu quả thật. Bạn cần phân biệt Tool đọc, Tool đề xuất và Tool thực thi; mỗi loại cần mức kiểm soát khác nhau.

Vận hành doanh nghiệp với Slack, Google Drive và Jira

Một Agent vận hành có thể đọc tài liệu từ Google Drive, tìm trao đổi trong Slack và kết nối các công cụ quản lý công việc như Jira. Nếu các capability này được phơi bày thống nhất, Host khác có thể dùng lại mà không yêu cầu đội automation tạo một bộ connector riêng cho từng Agent.

Đây là chỗ MCP hợp với doanh nghiệp có nhiều SaaS. Song đừng vội nối tất cả vào một Agent. Bắt đầu từ một luồng có owner, input rõ và tiêu chí kết quả rõ. Một Agent biết quá nhiều nhưng không có guardrail thường tạo ra ảo giác kiểm soát.

Browser automation bằng Puppeteer

Puppeteer là ví dụ trực quan vì browser automation vốn dễ biến thành một “con dao đa năng” nguy hiểm. MCP Server có thể phơi bày khả năng browser navigation cho Agent. Agent dùng Tool để thực hiện tác vụ trên web thay vì chỉ trả lời văn bản.

Use case này hấp dẫn, nhưng là nơi bạn phải nghiêm khắc nhất với scope, credential và xác nhận hành động. Browser có thể chạm vào dữ liệu nhạy cảm, form thay đổi trạng thái và nhiều thao tác không đảo ngược được. Nếu bạn quan tâm tới ranh giới an toàn của hệ thống AI tự chủ, hãy đọc thêm bài Khi Sandbox AI Không Còn An Toàn.

Bảo mật: MCP không làm rủi ro biến mất

MCP giúp chuẩn hóa kết nối, không chuẩn hóa sự khôn ngoan của đội triển khai. Một MCP Server cấp Tool thực thi mạnh có thể tạo rủi ro thực thi hành động không mong muốn. Đây là vấn đề nền tảng của Agentic automation: model có quyền hành động thì lỗi không còn dừng ở một câu trả lời sai.

Thiết kế quyền theo capability

Đừng cấp một credential toàn quyền rồi hy vọng prompt sẽ giữ model ngoan. Hãy chia capability theo hành động cụ thể. Tool đọc dữ liệu, Tool tạo draft và Tool thực thi thay đổi nên là các lớp khác nhau. Hành động nhạy cảm cần có xác nhận của người dùng khi phù hợp.

Human-in-the-Loop không phải dấu hiệu hệ thống yếu. Trong nhiều workflow, nó là quyết định đúng để giữ con người ở điểm chịu trách nhiệm. Automation tốt không đồng nghĩa mọi bước đều tự động.

Giới hạn dữ liệu và phạm vi truy cập

Resources có thể mang dữ liệu vào context của LLM. Vì vậy, cần biết resource nào được phép đọc, ai được quyền kích hoạt và dữ liệu nào không nên đưa vào cuộc hội thoại. Roots hỗ trợ giới hạn phạm vi thư mục hoặc URI an toàn; đây là một ví dụ về việc giao thức có ý thức về boundary.

Privacy và user consent không thể giải quyết bằng một checkbox. Nếu Server có access tới Google Drive, Slack hoặc Postgres, đội triển khai phải hiểu chính xác quyền nào đang được cấp. “Agent chỉ đọc thôi” vẫn là một rủi ro nếu nó đọc nhầm dữ liệu.

Quan sát workflow trước khi mở rộng

Khi Agent gọi nhiều Tools, lỗi khó nhìn hơn workflow tuyến tính. Bạn cần biết Agent đã gọi gì, thứ tự thế nào, nhận về dữ liệu gì và vì sao nó chọn hành động đó. Rate limit, độ trễ và lỗi từ remote service cũng sẽ ảnh hưởng trực tiếp chất lượng trải nghiệm.

Quan điểm của tôi: đừng triển khai MCP Server như một hộp đen. Hãy coi nó là một service sản xuất, có log, kiểm soát access, policy và quy trình xử lý lỗi. Những nguyên tắc này giống tư duy compliance-by-design khi đưa hệ thống thông minh vào môi trường có ràng buộc; bài Physical AI vào EU: Robot thông minh giờ phải chứng minh mình an toàn có một góc nhìn đáng tham khảo về chuyện thiết kế an toàn từ đầu.

Lộ trình thực dụng để bắt đầu với MCP

Đừng bắt đầu bằng việc xây một Agent “tự vận hành công ty”. Hãy bắt đầu bằng một MCP Server cho một capability nhỏ, có dữ liệu rõ và rủi ro thấp.

• Bước một: trải nghiệm các pre-built MCP Server trên một Host hỗ trợ MCP như Claude Desktop. Mục tiêu là hiểu Server xuất hiện thế nào, Resources khác Tools ra sao và Host hiển thị quyền truy cập như thế nào.
• Bước hai: chọn một integration bạn đang duy trì bằng wrapper thủ công. Có thể là GitHub, Postgres, Slack, Google Drive hoặc Puppeteer. Viết MCP Server bằng TypeScript hoặc Python SDK để phơi bày một số capability nhỏ.
• Bước ba: thiết kế Tool theo nguyên tắc tối thiểu. Bắt đầu bằng read-only. Nếu cần hành động, tách Tool tạo đề xuất khỏi Tool thực thi thay đổi.
• Bước bốn: kết nối Server với Host hoặc Agent runtime mà đội đang dùng. Thử cùng một capability qua các Host khác nhau nếu hệ sinh thái của bạn có nhu cầu đó.
• Bước năm: đưa vào workflow doanh nghiệp với quan sát, giới hạn quyền và người chịu trách nhiệm cụ thể. Đừng lấy demo thành production chỉ vì nó chạy được vài lần.

Một bài test tốt là chọn workflow mà hiện tại bạn phải viết nhiều adapter cho các LLM hoặc framework khác nhau. Nếu MCP giúp giảm phần code lặp mà vẫn giữ được kiểm soát, bạn đang dùng nó đúng chỗ.

Ngược lại, nếu bạn chỉ có một workflow webhook đơn giản giữa hai SaaS và không hề có Agent cần context hay Tool selection, MCP có thể là over-engineering. Không phải công nghệ mới nào cũng cần kéo vào stack.

Câu hỏi thường gặp

MCP có thay thế hoàn toàn REST API và Webhook trong automation không?

Không. REST API và Webhook vẫn là nền tảng kết nối giữa các hệ thống phần mềm. MCP là lớp giao thức để AI application tiếp cận Resources, Prompts và Tools theo chuẩn chung. Một MCP Server có thể dùng REST API ở phía sau để nói chuyện với SaaS hoặc hệ thống nội bộ.

Tôi có thể dùng MCP với Local LLM hay không?

MCP mô tả cách Host, Client và Server giao tiếp; nó không đồng nhất với một model cụ thể. Điều cần kiểm tra là Host hoặc Agent runtime bạn dùng có hỗ trợ MCP hay không. Đừng giả định rằng dùng Local LLM tự động đồng nghĩa có toàn bộ trải nghiệm MCP.

Khác biệt quan trọng nhất giữa Resources và Tools là gì?

Resources cung cấp dữ liệu hoặc context theo hướng read-only, phù hợp cho việc đọc và tham chiếu. Tools là hàm thực thi mà model có thể chủ động gọi để làm tác vụ. Khi thiết kế Server, hãy xem một capability là dữ liệu cần đọc hay hành động cần thực hiện. Sai ranh giới này thường dẫn tới quyền quá rộng.

MCP có khiến AI Agent tự động hóa an toàn hơn không?

MCP tạo cấu trúc rõ hơn cho capability, quyền truy cập và ranh giới Host-Server. Nhưng an toàn vẫn phụ thuộc vào Tool design, credential, user consent, scope của dữ liệu, Human-in-the-Loop và observability. Giao thức tốt không cứu được một Server cấp quyền sai.

Khi nào dân automation nên ưu tiên học MCP?

Hãy ưu tiên khi bạn đang xây Agent dùng nhiều dữ liệu và công cụ, phải hỗ trợ nhiều AI application, hoặc đã mệt với việc duy trì Custom Wrapper riêng cho từng model hay framework. Nếu automation hiện tại chỉ là trigger-action tuyến tính, hãy chuẩn hóa dữ liệu và workflow trước. MCP không thay thế nền móng vận hành yếu.

Nguồn tham khảo: MCP Là Gì? Toàn Tập Về Model Context Protocol Và Lý Do Dân Automation Bắt Buộc Phải Làm Chủ