Đặc tả Khám phá MCP Server cho Agent

TL;DR

• Agents hỗ trợ bốn vector khám phá: tệp cấu hình cục bộ (local config file), registry API, well-known URL (/.well-known/mcp.json), và điểm cuối do người dùng nhập (user-pasted endpoint).
• Mọi kết nối BẮT BUỘC PHẢI hoàn tất quy trình bắt tay khả năng (capability handshake: initialize → server.capabilities → đàm phán phiên bản) trước khi gọi bất kỳ công cụ nào.
• Quy trình xác minh độ tin cậy (Trust verification) sử dụng chữ ký manifest hoặc ghim nguồn gốc (origin pinning); các manifests không có chữ ký BẮT BUỘC PHẢI bị cách ly thông qua cơ chế phê duyệt rõ ràng từ người dùng.
• Các Manifests BẮT BUỘC PHẢI được lưu trữ đệm (cached) với một giới hạn TTL tối đa và bị vô hiệu hóa ngay lập tức nếu xảy ra sự không nhất quán trong quá trình bắt tay khả năng.

Định nghĩa

Khám phá MCP server cho agent (Agent MCP server discovery) là lớp giao thức cho phép một MCP client — thường được nhúng trong một agent runtime như Claude Desktop, ứng dụng sử dụng OpenAI Agents SDK, hoặc một hệ thống điều phối (orchestrator) tùy chỉnh — định vị một MCP server, tải bản đặc tả (manifest), đàm phán phiên bản giao thức, và xác minh độ tin cậy trước khi sử dụng bất kỳ công cụ nào do server đó cung cấp. Bản thân Model Context Protocol định nghĩa định dạng truyền tải mạng (JSON-RPC 2.0 qua stdio hoặc Streamable HTTP); lớp khám phá đảm nhiệm việc chuyển đổi một tên máy chủ (hostname) hoặc tệp nhị phân cục bộ (local binary) thành một điểm cuối (endpoint) khả dụng và đã vượt qua các kiểm tra bảo mật (Đặc tả Model Context Protocol, 2025).

Khám phá MCP server (Server discovery) hoàn toàn khác biệt với khám phá công cụ (tool discovery). Khám phá MCP server giải quyết bài toán "các máy chủ nào đang khả dụng và có thể kết nối?". Khám phá công cụ giải quyết bài toán "máy chủ này cung cấp những công cụ nào?". Hai lớp quy trình này xếp chồng lên nhau: agent trước tiên khám phá server, sau đó mới liệt kê các công cụ của server thông qua cùng một kết nối đã thiết lập. Việc nhầm lẫn giữa hai lớp này sẽ dẫn đến các kiến trúc thiếu ổn định (brittle), đòi hỏi agent phải khởi động lại mỗi khi có thêm một công cụ mới.

Tại sao điều này quan trọng

Giá trị cốt lõi của đặc tả khám phá là khả năng cho phép hệ sinh thái agent mở rộng linh hoạt mà không yêu cầu biên dịch lại (recompiling) các clients. Một nhóm phát triển có thể triển khai một MCP server mới, đăng ký qua /.well-known/mcp.json hoặc một registry API, và cho phép các agents tuân thủ chuẩn (compliant agents) tự động nhận diện trong chu kỳ khám phá tiếp theo. Nếu thiếu đặc tả khám phá, mỗi server mới sẽ yêu cầu một cấu hình được mã hóa cứng (hard-coded) trên mọi client.

Giá trị bảo mật cũng đóng vai trò trọng yếu. Các MCP servers có quyền truy cập tài nguyên nhạy cảm và thực thi hành động thay mặt người dùng. Một quy trình khám phá bắt buộc phải tích hợp bước bắt tay khả năng, đàm phán phiên bản và xác minh độ tin cậy nhằm ngăn chặn agent kích hoạt các công cụ chưa được xác minh ngữ nghĩa. Nếu bỏ qua các lớp kiểm tra này, một agent dù kết nối thành công tới một server không xác định vẫn có nguy cơ bị thao túng để thực thi các lệnh gọi công cụ mang tính phá hủy.

Cuối cùng, quy trình khám phá trực tiếp định hình trải nghiệm người dùng. Bốn vector tương ứng với bốn kịch bản người dùng điển hình: "hệ thống doanh nghiệp đã cấu hình sẵn" (config file), "cài đặt từ một hệ sinh thái ứng dụng" (registry API), "trang web cung cấp một điểm cuối MCP" (well-known URL), và "chia sẻ liên kết nội bộ" (user-paste). Việc chuẩn hóa hỗ trợ cả bốn vector này đảm bảo agent vận hành chính xác tại mọi điểm tiếp xúc.

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

Luồng khám phá là một chuỗi gồm bốn giai đoạn: định vị (locate), tìm nạp (fetch), bắt tay (handshake), và xác minh (verify).

[[CODE_FENCE_LANG=mermaid]]

flowchart LR

A["Agent runtime"] --> B["Locate (4 vectors)"]

B --> B1["Config file"]

B --> B2["Registry API"]

B --> B3["/.well-known/mcp.json"]

B --> B4["User-paste endpoint"]

B1 --> C["Fetch manifest"]

B2 --> C

B3 --> C

B4 --> C

C --> D["initialize"]

D --> E["server.capabilities"]

E --> F["version negotiation"]

F --> G{"Trust check"}

G -- "signed or pinned" --> H["Connection ready"]

G -- "unsigned" --> I["User consent gate"]

I -- "approve" --> H

I -- "deny" --> J["Reject"]

[[/CODE_FENCE]]

Giai đoạn 1: Định vị (Locate)

Agent xác định các ứng viên MCP servers thông qua một hoặc nhiều trong bốn vector khám phá. Vector tệp cấu hình (config file) trích xuất dữ liệu từ một tệp JSON cục bộ (thường là ~/.config/<agent>/mcp.json) chứa danh sách các điểm cuối server đã được cấu hình từ trước. Vector registry API truy vấn một HTTP registry để truy xuất danh sách các servers và siêu dữ liệu (metadata) của chúng. Vector well-known URL thực hiện truy vấn /.well-known/mcp.json từ một máy chủ (dựa trên ngữ nghĩa của RFC 8615 well-known URI) nhằm xác minh xem origin đó có cung cấp điểm cuối MCP hay không. Vector do người dùng nhập (user-paste) cho phép tiếp nhận một URL endpoint hoặc một lệnh thực thi cục bộ do người dùng cung cấp thủ công.

Giai đoạn 2: Tải bản đặc tả (Fetch manifest)

Đối với mỗi ứng viên, agent sẽ tiến hành tải bản đặc tả (manifest) của server. Đối với các servers sử dụng giao thức truyền tải HTTP, manifest được tải qua HTTPS; đối với các servers sử dụng stdio, manifest được trích xuất trực tiếp từ phản hồi initialize của server. Manifests sẽ công bố tên, phiên bản, các giao thức truyền tải (transports) được hỗ trợ, các khả năng hiện có, danh sách công cụ được khai báo (hoặc con trỏ tham chiếu để liệt kê ở thời gian chạy), và các yêu cầu xác thực (authentication requirements) của server.

Giai đoạn 3: Bắt tay khả năng (Capability handshake)

Agent phát ra yêu cầu initialize, qua đó công bố phiên bản giao thức của agent và các khả năng client hiện đang hỗ trợ. Server sẽ phản hồi bằng server.capabilities, liệt kê các tính năng tùy chọn (lấy mẫu/sampling, tài nguyên, prompts, công cụ, completions) được hỗ trợ. Cả hai bên sau đó tiến hành đàm phán phiên bản giao thức: phiên bản cao nhất tương thích cho cả hai bên sẽ được thiết lập. Nếu không tìm thấy phiên bản tương thích, client BẮT BUỘC PHẢI hủy kết nối và báo cáo lỗi không tương thích (mismatch) này cho người dùng (Đặc tả ủy quyền MCP, 2025).

Giai đoạn 4: Xác minh độ tin cậy (Trust verification)

Trước khi xác nhận kết nối khả dụng, agent sẽ tiến hành quy trình xác minh độ tin cậy thông qua một trong hai phương thức. Ký manifest (Manifest signing) sẽ xác thực một chữ ký tách rời (detached signature) bằng cách đối chiếu với khóa (key) của một nhà phát hành (publisher) đã được xác nhận; nếu chữ ký hợp lệ, server sẽ kế thừa cấp độ tin cậy của nhà phát hành đó. Ghim nguồn gốc (Origin pinning) ràng buộc danh tính của server với chứng chỉ TLS và nguồn gốc (origin) của nó; các kết nối tiếp theo tới origin này bắt buộc phải cung cấp chuỗi chứng chỉ (certificate chain) đã được ghim. Nếu cả hai phương thức xác minh đều thất bại, agent NÊN yêu cầu người dùng phê duyệt quyền truy cập rõ ràng và tiến hành cách ly server trong một chế độ đặc quyền giới hạn (low-privilege mode), vô hiệu hóa mọi công cụ có tính chất phá hủy.

Ứng dụng thực tiễn

Một kiến trúc triển khai client tham chiếu cần tuân thủ bảy bước chuẩn sau:

1. Khởi tạo bộ đệm khám phá (discovery cache) với TTL cấu hình từ 300 đến 3.600 giây đối với các manifests tĩnh; vô hiệu hóa lập tức khi hệ thống ghi nhận không tương thích ở quy trình bắt tay.
2. Sắp xếp các vectors khám phá theo độ ưu tiên: config file (cao nhất), registry API, well-known URL, user-paste (thấp nhất), và tiến hành khử trùng lặp (de-duplicating) dựa trên các điểm cuối chuẩn tắc (canonical endpoints).
3. Tải (Fetch) các manifests theo luồng song song, áp dụng thời gian chờ (timeout) cho mỗi request (khuyến nghị 5-10 giây) và sử dụng thuật toán backoff hàm mũ cho các lỗi tạm thời (ví dụ: 1s, 2s, 4s, kết hợp jitter).
4. Xác thực lược đồ (schema) của manifest dựa trên JSON Schema chính thức trước khi thực thi xử lý chuyên sâu; từ chối ngay lập tức các manifests sai định dạng (malformed).
5. Thực thi quy trình bắt tay khả năng (capability handshake) cho từng ứng viên hợp lệ; lưu trữ cấu hình phiên bản giao thức và các khả năng đã đàm phán vào hồ sơ kết nối (connection record).
6. Xác minh độ tin cậy (trust) thông qua chữ ký mật mã hoặc ghim origin; định tuyến các servers chưa được ký vào cơ chế phê duyệt xác thực từ người dùng và tự động cắt giảm phạm vi đặc quyền (privilege scope).
7. Ràng buộc các phạm vi xác thực (auth scopes) tương ứng với từng công cụ cụ thể, tuyệt đối không phân quyền theo cấp server; agent NÊN tương thích với các OAuth 2.1 bearer tokens đi kèm chuỗi phạm vi (scope strings) do server khai báo trong từng định nghĩa công cụ.

Ngữ nghĩa xử lý lỗi (Failure semantics): Một chu kỳ khám phá thất bại ở bất kỳ giai đoạn nào BẮT BUỘC PHẢI được ghi log chi tiết, bao gồm vị trí giai đoạn lỗi, điểm cuối ứng viên (candidate endpoint), và mã lỗi lõi (underlying error). Quy trình thử lại (retries) phải tuân theo mô hình ngắt mạch (circuit-breaker pattern) — hệ thống sẽ chặn kết nối và áp dụng khoảng thời gian làm mát (cooldown) 5 phút sau ba lần thử nghiệm thất bại liên tiếp.

So sánh với các sổ đăng ký công cụ tĩnh (static tool registries)

Các sổ đăng ký công cụ tĩnh (static tool registries) thực thi việc mã hóa cứng (hard-code) các định nghĩa công cụ trực tiếp vào kiến trúc agent. Phương pháp này giảm tải độ phức tạp hệ thống và loại bỏ quy trình khám phá trong thời gian chạy (runtime discovery), nhưng lại mất đi khả năng mở rộng linh hoạt mà không yêu cầu cập nhật phiên bản client. Khám phá MCP server đánh đổi một phần độ trễ khởi động (startup latency) và độ phức tạp trong xác minh bảo mật để thiết lập khả năng mở rộng tức thời cho agent (runtime extensibility). Đối với các agents tiêu dùng (như Claude Desktop, ChatGPT desktop), khả năng mở rộng runtime là yêu cầu bắt buộc; đối với các agents dạng phân mảnh hẹp (vertical agents) có tập công cụ đóng, sổ đăng ký tĩnh là giải pháp tối ưu. Hai mô hình này có thể hoạt động song song: sổ đăng ký tĩnh xử lý bộ công cụ hệ thống (core registry), trong khi khám phá MCP đảm nhiệm tích hợp các servers ngoại vi do người dùng hoặc workspace cài đặt.

Các lỗi chống mẫu (Anti-patterns) thường gặp

• Chấp nhận vô điều kiện manifests không chữ ký. Một sai lầm bảo mật phổ biến là vô hiệu hóa xác minh chữ ký do hầu hết các public servers chưa áp dụng. Phương pháp chuẩn mực là cách ly các servers chưa ký, đồng thời thiết lập rào chắn phê duyệt từ người dùng đối với các công cụ nhạy cảm; việc bỏ qua hoàn toàn bước xác minh này sẽ tạo ra lỗ hổng mạo danh server thông qua kỹ thuật tiêm prompt (prompt-injection).
• Thiếu cơ chế ghim phiên bản (Version pinning). Các clients ngầm định luôn hỗ trợ phiên bản giao thức mới nhất sẽ gặp lỗi (break) khi giao tiếp với các servers kế thừa (legacy servers). Bắt buộc ghim (pin) phiên bản đã đàm phán vào hồ sơ kết nối và từ chối các lời gọi khả năng vượt quá ranh giới đã giao ước.
• Vòng lặp tải lại manifest vô hạn. Nếu thiếu cấu hình TTL và thuật toán ngắt mạch (circuit breaker), một vòng lặp khám phá lỗi có thể gửi request ồ ạt tới endpoint well-known trên mọi hành động. Phải kiểm soát tần suất tìm nạp lại (re-fetch frequency) và thực thi thời gian làm mát (cooldown) đối với các lỗi liên tiếp.
• Rò rỉ Auth tokens. Các Bearer tokens BẮT BUỘC PHẢI được giới hạn phạm vi (scoped) trên từng server riêng biệt và nghiêm cấm tái sử dụng chéo. Việc cấu hình một token toàn cục (global token) cho agent trên toàn bộ các kết nối MCP là một lỗi bảo mật mức độ cực kỳ nghiêm trọng.

FAQ

Q: Agents thực thi xác thực (authenticate) với MCP servers bằng phương thức nào?

A: Đặc tả ủy quyền MCP (MCP Authorization Specification) khuyến nghị triển khai OAuth 2.1 kết hợp bearer tokens đối với các HTTP-transport servers, và ứng dụng danh tính cấp quy trình (process-level identity) đối với các stdio servers (Đặc tả ủy quyền MCP, 2025). Bearer tokens phải được phân bổ giới hạn phạm vi (scoped) theo từng server thay vì ở cấp agent. Các tools sẽ công bố yêu cầu phạm vi (scope requirements) thông qua manifest, đảm bảo client chỉ yêu cầu xác thực các quyền thực sự cần thiết. Tái sử dụng một token toàn cục cho đa hệ thống servers là một lỗ hổng thiết kế (anti-pattern) có mức độ rủi ro tối đa.

Q: Kịch bản xử lý khi một MCP server rơi vào trạng thái ngoại tuyến (offline)?

A: Client NÊN kích hoạt các quy tắc ngắt mạch (circuit-breaker pattern) đã được tài liệu hóa: ba lần kết nối thất bại liên tiếp sẽ đưa endpoint vào trạng thái làm mát (cooldown) bắt buộc kéo dài 5 phút. Trong suốt thời gian làm mát, hệ thống sẽ đánh dấu các tools thuộc server đó ở trạng thái "không khả dụng" thay vì bỏ qua một cách âm thầm (silently ignore) — người dùng có quyền và cần được thông báo rõ ràng về các năng lực (capabilities) đang bị gián đoạn.

Q: Agents có nên thiết lập độ tin cậy tự động (auto-trust) đối với các well-known MCP registries không?

A: Tuyệt đối không. Một well-known URL chỉ đóng vai trò xác thực việc origin đang cung cấp một điểm cuối MCP; cơ chế này hoàn toàn không định danh nhà phát hành (publisher identity). Quy trình tự động tin cậy (Auto-trust) chỉ được phép kích hoạt đối với các servers sở hữu manifests được ký (signed manifests) bởi một khóa bảo mật (key) đã được agent xác minh trước đó, hoặc khi origin đã được ghim tường minh (explicitly pinned) thông qua thiết lập của người dùng hoặc quản trị viên hệ thống.

Q: Cơ chế lưu trữ đệm (cache) và vô hiệu hóa (invalidate) manifests của MCP server hoạt động ra sao?

A: Cấu hình phòng thủ tiêu chuẩn sẽ lưu trữ đệm các manifests tĩnh trong khung thời gian 300-3.600 giây và tự động kích hoạt vô hiệu hóa (invalidation) ngay khi phát hiện bất kỳ sự không đồng nhất nào tại bước bắt tay khả năng (nơi server phản hồi các tính năng sai lệch so với bản manifest được lưu). Các manifests truy xuất từ /.well-known/ nên ưu tiên xử lý header Cache-Control từ HTTP response; trong trường hợp khuyết header này, hệ thống sẽ tự động chuyển đổi sang giá trị mặc định của agent.

Q: Đâu là ranh giới kỹ thuật giữa khám phá MCP server và khám phá công cụ (tool discovery)?

A: Khám phá server giải quyết bài toán "hệ thống có thể định tuyến đến những MCP servers nào?" thông qua quá trình định vị endpoints qua bốn vectors và xác thực kết nối bằng quy trình bắt tay (handshake). Trong khi đó, khám phá công cụ trả lời câu hỏi "server này cung cấp các công cụ chức năng nào?" bằng cách truy vấn danh sách công cụ (thường qua API tools/list) sau khi kết nối đã được thiết lập thành công. Khám phá server chỉ thực thi một lần duy nhất cho mỗi vòng đời kết nối; khám phá công cụ có thể được kích hoạt nhiều lần trên cùng một phiên kết nối.

Q: Đàm phán khả năng (capability negotiation) giải quyết các xung đột phiên bản giao thức như thế nào?

A: Lệnh initialize sẽ trả về phiên bản giao thức cao nhất được hỗ trợ tương thích từ cả hai phía. Nếu yêu cầu phiên bản tối thiểu của agent và giới hạn hỗ trợ tối đa của server không có vùng giao thoa (overlap), client BẮT BUỘC PHẢI hủy tiến trình kết nối và đẩy cảnh báo lỗi tường minh lên giao diện người dùng, tuyệt đối không thực thi các nỗ lực hạ cấp không đồng bộ (best-effort downgrades). Các tiến trình hạ cấp âm thầm sẽ che giấu sự trôi dạt giao thức (protocol drift), dẫn đến các lỗi runtime có độ phức tạp gỡ lỗi (hard-to-debug) cực kỳ cao.