Bỏ qua điều hướng

MCP Host là gì? Vai trò và cách hoạt động trong kiến trúc MCP

MCP Host đóng vai trò điều phối trong kiến trúc phi trạng thái, quản lý các kết nối Client để lấy dữ liệu từ Server và tích hợp vào cửa sổ ngữ cảnh của AI.

Tuan Tran Van
11 phút đọc
Mục lục (9 phần)
  1. MCP Host là gì?
  2. Host, Client và Server khác nhau thế nào?
  3. Host làm gì trong một vòng gọi công cụ?
  4. Vì sao consent là trách nhiệm của Host?
  5. Host cung cấp gì ngược lại cho Server?
  6. Bản spec 2026-07-28 thay đổi gì cho Host?
  7. Host xử lý hàng trăm tool bằng cách nào?
  8. Tự viết Host hay dùng Host có sẵn?
  9. Tài liệu tham khảo

MCP Host là ứng dụng AI đứng ở vị trí điều phối trung tâm trong kiến trúc Model Context Protocol.

Claude Desktop, Visual Studio Code hay các IDE (môi trường phát triển tích hợp) hiện đại đều là MCP Host, nên nếu bạn đang chat với AI ngay trong trình soạn thảo code thì bạn đang ngồi bên trong một Host. Host là bên khởi tạo kết nối và quản lý các MCP Client để lấy ngữ cảnh từ Server, sau đó nhét dữ liệu đó vào cửa sổ ngữ cảnh (context window) của mô hình ngôn ngữ lớn (Large Language Model, LLM).

Vai trò đó nặng hơn vẻ ngoài, vì Host vừa là cầu nối vừa là lớp bảo mật cuối cùng, thứ mà giới bảo mật quen gọi là "root of trust". Host là nơi hỏi ý bạn (user consent) trước khi bất kỳ hành động nào chạy, và cũng là nơi điều phối vòng đời của các tài nguyên trong một kiến trúc phi trạng thái (stateless) hoàn toàn.

Kiến trúc đó không đứng yên. MCP đánh số đặc tả kỹ thuật (specification) của mình theo ngày phát hành, và bản spec 2026-07-28 do nhóm phát triển Model Context Protocol công bố là bản mới nhất tính đến lúc bài này lên trang, cũng là bản mà toàn bộ bài viết bám theo.

Minh họa MCP Host là ứng dụng AI trung tâm điều phối nhiều kết nối tới các nguồn dữ liệu và công cụ bên ngoài

MCP Host là gì?

Dưới góc độ kỹ thuật, MCP Host là lớp ứng dụng AI chịu trách nhiệm cao nhất: nó quản lý vòng đời của mọi kết nối và bơm dữ liệu vào luồng suy luận của mô hình ngôn ngữ lớn (LLM). Trong khi Server cung cấp khả năng, Host chính là bên nắm giữ quyền truy cập và dữ liệu của người dùng. Một Host có thể chứa nhiều MCP Client, mỗi Client duy trì một kết nối riêng biệt đến một Server cụ thể, chẳng hạn Sentry, Slack hoặc Filesystem.

Kiến trúc này phân tách rõ ràng giữa tầng dữ liệu (data layer), tức giao thức JSON-RPC (chuẩn gọi hàm từ xa bằng định dạng JSON), và tầng vận chuyển (transport layer), tức Stdio hoặc HTTP. Sự tách biệt này đáng để nhớ kỹ, bởi vì MCP Client bên trong Host mới là bên gánh phần transport, tức kết nối vật lý, trong khi bản thân Host chỉ lo cửa sổ ngữ cảnh và logic ứng dụng.

Nhờ phân lớp như vậy, Host không phải biết gì về sự phức tạp của giao thức vận chuyển, nên nó chỉ cần quan tâm đến các công cụ (Tools), tài nguyên (Resources) và mẫu lời nhắc (Prompts) mà các Client mang về. Khi bạn mở Visual Studio Code, chính nó là Host, và nó có thể khởi tạo một Client kết nối với GitHub cùng một Client khác kết nối với Terminal cục bộ, nhờ đó mô hình AI hiểu được đồng thời cả code từ máy chủ từ xa (remote) lẫn log từ máy bạn.

Host, Client và Server khác nhau thế nào?

Ba cái tên này hay bị gọi lẫn lộn, nên trước khi triển khai hệ thống bạn cần phân định rõ trách nhiệm của từng bên:

  • Host là người điều phối tổng thể, quản lý giao diện người dùng (UI), điều khiển cửa sổ ngữ cảnh của mô hình ngôn ngữ lớn (LLM) và phê duyệt quyền thực thi (consent).
  • Client là thành phần trung gian nằm trong Host, chịu trách nhiệm quản lý transport và thực hiện giao tiếp JSON-RPC. Nó chuyển đổi yêu cầu (request) từ Host thành định dạng mà Server hiểu được.
  • Server là chương trình cung cấp các công cụ (Tools), tài nguyên (Resources) và mẫu lời nhắc (Prompts). Server không có UI và hoạt động theo cơ chế phi trạng thái (stateless).

Sơ đồ kiến trúc MCP: Host chứa nhiều Client, mỗi Client giữ một kết nối riêng tới một Server

Sự khác biệt còn thể hiện ở loại kết nối, bởi vì Host quản lý các Local Server thông qua Stdio, tức kết nối trực tiếp giữa các tiến trình trên cùng một máy, hoặc các Remote Server thông qua Streamable HTTP. Trong kiến trúc mới, một giao thức JSON-RPC thống nhất xóa nhòa ranh giới giữa cục bộ và từ xa, nhưng Host vẫn là bên giữ quyền kiểm soát cao nhất đối với mọi yêu cầu gửi đi.

Host làm gì trong một vòng gọi công cụ?

Trong một vòng gọi công cụ (tool call), Host là người gác cổng, vì mọi luồng dữ liệu đều phải đi qua tay nó. Về mặt kỹ thuật, quy trình diễn ra như sau:

  1. Khám phá (discovery): Host liệt kê danh sách công cụ hiện có thông qua lệnh tools/list.
  2. Gửi ngữ cảnh: Host gửi mô tả công cụ cùng truy vấn của bạn cho mô hình ngôn ngữ lớn (LLM).
  3. Mô hình ra quyết định: LLM phân tích và chọn công cụ cần gọi kèm theo các tham số (arguments).
  4. Chặn và thực thi: Host chặn lời gọi này, hiển thị UI để bạn xác nhận, sau đó chuyển yêu cầu đến Server thông qua Client.
  5. Trả kết quả: Host đưa kết quả từ Server ngược lại vào ngữ cảnh của mô hình để hoàn tất câu trả lời.

Năm bước của một vòng gọi công cụ MCP: khám phá, gửi ngữ cảnh, mô hình chọn công cụ, Host chặn để xác nhận, trả kết quả

Khối JSON-RPC dưới đây minh họa một lệnh tools/call trong bản spec 2026-07-28, trong đó trường _meta là bắt buộc:

json
{
  "jsonrpc": "2.0",
  "id": 105,
  "method": "tools/call",
  "params": {
    "name": "read_file",
    "arguments": {
      "path": "/src/main.py"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "senior-system-host",
        "version": "2.1.0"
      }
    }
  }
}

Nguyên tắc bảo mật cốt lõi của MCP gói trong một câu: Server không bao giờ được tự ý thực thi những hành động có tác động đến hệ thống. Ghi file, xóa dữ liệu hay gọi API bên thứ ba, mọi thao tác kiểu đó đều phải chờ người dùng phê duyệt tại tầng Host.

Vì Server hiện nay hoạt động theo cơ chế phi trạng thái (stateless), nó không biết gì về "phiên làm việc" hay danh tính thực sự của người dùng cuối, mà chỉ là một thực thể cung cấp khả năng. Nếu Host tin tưởng tuyệt đối vào mọi lời gọi từ mô hình hay từ Server, đó là một lỗ hổng bảo mật nghiêm trọng, cho nên Host phải hiển thị UI minh bạch để bạn soi lại các tham số trước khi nhấn "Run". Đặc tả nói thẳng rằng Host phải xin phép người dùng trước khi gọi bất kỳ công cụ nào và trước khi để lộ dữ liệu người dùng cho Server. Tôi cho rằng đây là chỗ dễ làm ẩu nhất khi tự viết Host, vì bỏ bước xác nhận đi thì sản phẩm chạy mượt hơn hẳn, cho đến ngày mô hình gọi nhầm một lệnh xóa.

Host cung cấp gì ngược lại cho Server?

MCP hỗ trợ cơ chế Elicitation (truy vấn ngược) cho những tình huống Server cần thêm thông tin từ người dùng, ví dụ xác nhận thanh toán hoặc điền nốt một trường còn thiếu. Trong kiến trúc phi trạng thái của bản spec 2026-07-28, việc này được thực hiện qua mô hình Multi Round-Trip Requests (MRTR), tức nhiều lượt trao đổi qua lại cho cùng một yêu cầu.

Luồng Multi Round-Trip Requests: Server trả về InputRequiredResult, Host hỏi người dùng rồi gửi lại yêu cầu ban đầu

Thay vì gửi một yêu cầu độc lập, Server sẽ trả về một InputRequiredResult. Host nhận kết quả này, hiển thị UI cho bạn nhập liệu, sau đó thử lại, tức gửi lại yêu cầu ban đầu kèm theo các phản hồi đã thu thập.

Một lưu ý tiết kiệm cho bạn vài ngày công: spec 2026-07-28 chính thức đánh dấu RootsSampling là deprecated, tức không dùng nữa. Vì vậy đừng triển khai chúng, trừ khi bạn phải đỡ một hệ thống cũ; thay vào đó hãy truyền thẳng những thông tin này qua tham số của công cụ.

Ví dụ về cấu trúc InputRequiredResult mà Host nhận được từ Server:

json
{
  "jsonrpc": "2.0",
  "id": 105,
  "result": {
    "resultType": "input_required",
    "inputRequests": [
      {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Vui lòng nhập mã OTP để xác nhận giao dịch:",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "otp_code": { "type": "string", "pattern": "^[0-9]{6}$" }
            },
            "required": ["otp_code"]
          }
        }
      }
    ]
  }
}

Bản spec 2026-07-28 thay đổi gì cho Host?

Bản spec 2026-07-28 chuyển hẳn sang mô hình phi trạng thái (stateless), vì vậy nó bỏ luôn giai đoạn bắt tay khởi tạo (handshake) initialize và header Mcp-Session-Id. Mọi yêu cầu giờ đây phải tự chứa đủ thông tin (self-contained).

Đổi lại, Host phải tự đính kèm thông tin giao thức trong trường _meta của mỗi yêu cầu. Để hỗ trợ định tuyến hiệu quả, Host cũng phải gửi kèm các header chuẩn khi giao tiếp qua HTTP, nhờ đó gateway hoặc bộ cân bằng tải (load balancer) có thể nhìn vào HTTP header để điều hướng thay vì phải bóc tách body JSON:

text
POST /mcp-endpoint
Mcp-Method: tools/call
Mcp-Name: write_database

So sánh mô hình có trạng thái trước đây và mô hình phi trạng thái của bản spec 2026-07-28

Đây mới là lý do thật sự của cả thay đổi này, vì nhờ nó Host có thể mở rộng quy mô thoải mái phía sau bộ cân bằng tải mà không cần duy trì phiên làm việc (session) tập trung. Nếu cần giữ trạng thái giữa các lần gọi, Server sẽ trả về một handle (định danh), rồi Host truyền handle đó ngược lại trong đối số của lần gọi công cụ tiếp theo.

Host xử lý hàng trăm tool bằng cách nào?

Khi cắm hàng chục Server cùng lúc, Host sẽ cạn token nếu nhồi hết định nghĩa công cụ vào mô hình. Để giữ độ trễ và bộ nhớ ở mức chịu được, Host cần triển khai các chiến lược sau:

  1. Progressive Tool Discovery (khám phá công cụ theo lớp): Host chỉ cung cấp một danh mục rút gọn (catalog), và khi mô hình cần thì nó gọi công cụ đó để xem chi tiết (inspect), cuối cùng mới thực thi (execute).
  2. Caching hints (gợi ý bộ nhớ đệm): tận dụng trường ttlMscacheScope trong kết quả từ Server để lưu tạm danh sách công cụ, nhờ đó tránh gọi tools/list liên tục.
  3. Programmatic Tool Calling (gọi công cụ bằng code, còn gọi là code mode): Host cho phép mô hình viết script để gọi nhiều công cụ cùng lúc trong một môi trường cách ly (sandbox) an toàn, rồi chặn các lời gọi từ sandbox này để chuyển tiếp đến Server tương ứng, nhờ đó giảm số lượt trao đổi giữa mô hình và Host.

Ba lớp của Progressive Tool Discovery: danh mục rút gọn, xem chi tiết, rồi mới thực thi

Tự viết Host hay dùng Host có sẵn?

Nếu bạn chỉ cần mở rộng khả năng cho các tác vụ cá nhân, hãy dùng Host có sẵn như Claude Desktop hay VS Code, bởi vì phần giao diện và bảo mật ở đó đã có người làm hộ, và đó cũng là nơi hầu hết AI Agent thực tế đang chạy.

Ngược lại, nếu bạn cần xây dựng ứng dụng AI chuyên biệt cho doanh nghiệp, nơi yêu cầu kiểm soát dữ liệu khắt khe hoặc tích hợp sandbox riêng, thì bạn nên tự viết Host. Khi đó hãy dùng các SDK chính thức (Python, TypeScript, Go, C#) để bám đúng chi tiết kỹ thuật của bản spec 2026-07-28 và giảm rủi ro khi giao thức tiếp tục thay đổi. Tự viết Host là cam kết dài hạn chứ không phải việc của một buổi chiều, vì chỉ trong một bản spec giao thức đã bỏ cả initialize lẫn Mcp-Session-Id, và nó sẽ còn đổi nữa.

Tài liệu tham khảo

Chia sẻ bài viết

X / TwitterFacebookLinkedIn