MCP (Model Context Protocol) cho tự động hoá kiểm thử: cấp công cụ cho AI agent một cách chuẩn hoá và an toàn

1. MCP là gì và vì sao QA cần quan tâm

Model Context Protocol (MCP) là một giao thức mở chuẩn hoá cách một mô hình ngôn ngữ lớn (LLM) kết nối tới các nguồn dữ liệu và công cụ bên ngoài. Thay vì mỗi lần lại viết một lớp keo riêng để agent gọi trình duyệt, đọc tệp hay bắn API, MCP định nghĩa một khuôn giao tiếp chung: server phơi bày công cụ, client (ứng dụng chứa LLM) khám phá và gọi chúng. Với đội QA, điều này biến việc trao 'tay chân' cho AI agent từ một mớ script tuỳ biến thành một hợp đồng rõ ràng, có phạm vi và có kiểm soát quyền.

Ranh giới cần nắm ngay từ đầu: MCP chỉ là kênh vận chuyển năng lực, nó không nghĩ hộ bạn oracle của bài kiểm thử. Một agent có công cụ trình duyệt mạnh vẫn có thể viết ra một bài kiểm thử vô nghĩa nếu chỉ khẳng định 'màn hình hiện thành công'. Giá trị của MCP nằm ở chỗ nó cho phép bạn giới hạn chính xác agent được làm gì (đọc DOM nhưng không xoá tệp production), và ghi lại mọi lần gọi để về sau còn truy vết. Chúng ta sẽ đi từ mô hình client/server, tới transport, thương lượng năng lực, đặc quyền tối thiểu, rồi tự dựng một MCP server cho test harness.

2. Mô hình client/server và vòng đời phiên

Trong MCP có ba vai: host (ứng dụng người dùng tương tác, ví dụ một agent kiểm thử), client (bộ kết nối bên trong host, mỗi client nối tới đúng một server), và server (tiến trình phơi bày công cụ, tài nguyên và prompt). Một host có thể mở nhiều client, mỗi client bắt tay riêng với một server riêng. Việc tách bạch này cho phép bạn chạy một server trình duyệt với quyền hẹp và một server API với quyền khác hẳn, không lẫn lộn phạm vi.

Vòng đời một phiên: client gửi initialize khai báo phiên bản giao thức và năng lực nó hỗ trợ; server trả về năng lực của mình (tools, resources, prompts, logging). Sau bắt tay, client gọi tools/list để biết có công cụ gì, rồi tools/call để chạy. Server có thể chủ động gửi thông báo (ví dụ danh sách công cụ thay đổi). Khi xong, client đóng phiên. Với QA, hiểu vòng đời này giúp bạn đặt chốt kiểm soát đúng chỗ: chặn ngay ở bước tools/list nếu công cụ nguy hiểm không nên xuất hiện.

// 1) Client → Server : initialize (bắt tay + khai báo năng lực)
{ "jsonrpc": "2.0", "id": 1, "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": { "roots": { "listChanged": true }, "sampling": {} },
    "clientInfo": { "name": "cybersoft-test-agent", "version": "1.0.0" }
  } }

// 2) Server → Client : kết quả (server công bố năng lực của nó)
{ "jsonrpc": "2.0", "id": 1, "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": { "tools": { "listChanged": true }, "resources": {}, "logging": {} },
    "serverInfo": { "name": "cybersoft-mcp-harness", "version": "0.4.0" }
  } }

// 3) Client → Server : liệt kê công cụ
{ "jsonrpc": "2.0", "id": 2, "method": "tools/list" }

3. Transport: stdio và HTTP streamable

MCP không ràng buộc một đường truyền duy nhất; nó chuẩn hoá thông điệp JSON-RPC còn transport thì có hai kiểu phổ biến. Kiểu stdio: server chạy như tiến trình con, client ghi vào stdin và đọc từ stdout. Đây là lựa chọn gọn nhẹ cho công cụ chạy cục bộ trong CI, độ trễ thấp, không cần cổng mạng. Kiểu HTTP streamable: server là một dịch vụ HTTP, phản hồi có thể stream nhiều phần qua Server-Sent Events; hợp khi server chạy từ xa, dùng chung nhiều agent, hoặc cần xác thực qua header.

• stdio: lý tưởng cho CI cục bộ, không mở cổng, quyền theo tiến trình con — dễ sandbox.
• HTTP streamable: dùng chung server từ xa, xác thực bằng Bearer token, hỗ trợ stream tiến trình dài.
• Chọn stdio khi muốn khởi động nhanh, tắt sạch sau mỗi lần chạy test; chọn HTTP khi cần audit tập trung.

// Cấu hình một agent kiểm thử nối tới hai server MCP:
// (1) Playwright MCP qua stdio  (2) test-harness server tự viết qua HTTP
{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--headless", "--isolated"]
    },
    "harness": {
      "url": "https://mcp.internal.cybersoft.test/harness",
      "transport": "http",
      "headers": { "Authorization": "Bearer ${HARNESS_TOKEN}" }
    }
  }
}

4. Thương lượng năng lực (capability negotiation)

Thương lượng năng lực là bước hai phía tuyên bố mình hỗ trợ gì để không giả định nhầm. Client khai báo các năng lực như roots (thư mục gốc mà nó cho phép truy cập) và sampling (cho server yêu cầu mô hình sinh nội dung). Server khai báo tools, resources, prompts và logging. Chỉ những gì được cả hai công bố mới được dùng. Với QA, đây là điểm chốt an toàn đầu tiên: nếu bạn không muốn agent tự ý gọi lại mô hình để 'nghĩ thêm', đừng bật sampling.

Một chi tiết dễ bỏ sót: năng lực listChanged. Nếu server bật tools.listChanged, nó có thể thêm công cụ mới giữa phiên và thông báo cho client. Điều này tiện nhưng nguy hiểm: một công cụ 'xoá tenant' xuất hiện giữa chừng có thể lọt qua nếu bạn không rà lại danh sách. Nguyên tắc: coi mỗi lần listChanged như một sự kiện cần audit, và với môi trường sản xuất hãy khoá cứng danh sách công cụ, không cho server tự thêm.