Chuyển đến nội dung chính
Bạn muốn các agent của mình dùng một Model Context Protocol (MCP) server — server từ xa của riêng bạn, hoặc server đóng gói sẵn — nhưng bạn muốn mọi lời gọi tool mà nó phơi bày đều chạy phía sau một điểm nghẽn được audit duy nhất. Bước đầu tiên là đăng ký server trong workspace của bạn: một name, một endpoint, một auth mode, và các credential của nó. Một khi nó được đăng ký, MCP gateway quảng bá các tool của nó dưới một kết nối duy nhất và đánh giá mọi tools/call qua chính sách firewall của bạn trước khi nó đến được server thật. Trang này đề cập một nhiệm vụ đó — kết nối và cấu hình một bản ghi server. Về hành vi runtime của gateway và các verdict theo từng cuộc gọi, xem MCP reference; để có bức tranh lớn hơn, bắt đầu từ tổng quan bảo mật MCP.
Đăng ký là một hành động console (các route /api/workspace/firewall/* xác thực bằng session / access token của bạn, không phải một relay key sk-orca-…). Việc ghi yêu cầu vai trò Developer+; bất kỳ thành viên nào cũng có thể liệt kê các server.

​
1. Cách kết nối một MCP server

Mở Firewall → MCP Servers trong console và thêm một server, hoặc gọi trực tiếp workspace API. Một đăng ký mang theo bốn thứ quan trọng:

name

Duy nhất theo workspace. Nó trở thành tiền tố namespace <server>.<tool>, nên một name trùng lặp trong cùng một workspace bị từ chối với HTTP 409.

endpoint

URL của MCP server từ xa của bạn. Để trống để đăng ký server in-process đóng gói sẵn sao cho nó hiển thị và có thể kiểm soát.

auth_mode

Cách gateway xác thực tới server của bạn: none, bearer, oauth, hoặc basic.

credentials

Secret đặc thù theo mode. Được lưu mã hóa lúc nghỉ và masked khi đọc — nó không bao giờ đến được mô hình hoặc client.
Một server khởi đầu ở trạng thái enabled và bị loại khỏi gateway hoàn toàn ngay khoảnh khắc bạn tắt nó — đó là công tắc off, và các credential của một server bị tắt không bao giờ được giải mã.

​
2. Một ví dụ cụ thể

Đăng ký một GitHub MCP server từ xa với một bearer token. Đây là một REST call tương đương console; các tên trường chính xác là những gì biểu mẫu ghi ra. 
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-session-or-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'
Hình dạng credential phụ thuộc vào auth_mode:
{"token":"…"} — gửi như một bearer token tới server của bạn.
{"access_token":"…"} — một access token tĩnh mà gateway gửi như một bearer header. Việc trao đổi client-credentials tự động chưa được hỗ trợ; không có một access_token đã lưu, một probe mode oauth thất bại thay vì kết nối mà không xác thực.
{"username":"…","password":"…"}.
Một chuỗi rỗng. Không có credential nào được đính kèm.
Khi đọc, cả credential lẫn endpoint đều bị masked — API trả về các placeholder sentinel, không phải giá trị thô. Khi bạn cập nhật một server, echo các placeholder đó trở lại nguyên văn để giữ các giá trị đã lưu; gửi một auth_json mới chỉ khi bạn thực sự đang xoay vòng secret. Xem xoay vòng credential.

​
3. Probe sức khỏe của nó

Trước khi bạn có thể viết các quy tắc firewall đối với các tool của một server, bạn cần biết chúng có thể tiếp cận được và chúng được gọi là gì. Probe server — gateway chạy một cái bắt tay MCP initialize + tools/list dùng các credential đã giải mã, ghi lại khả năng tiếp cận, và trả về các tool được quảng bá: 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-or-access-token>"

{
  "status": "ok",
  "last_checked_at": 1700000000,
  "tools": [
    { "name": "create_issue", "description": "…", "input_schema": {} }
  ]
}
status đáp xuống bản ghi server và điều khiển chỉ báo sức khỏe:
statusÝ nghĩa
okCó thể tiếp cận; các tool được gateway phục vụ.
degradedCó thể tiếp cận, nhưng cái bắt tay chỉ một phần.
downKhông thể tiếp cận ở lần probe gần nhất; server bị bỏ qua.
Một server down bị để ngoài khi gateway xây dựng tập tool của nó, nên một gián đoạn thoáng qua suy giảm một cách nhẹ nhàng thay vì làm hỏng dispatch. Một probe trả về kết quả của nó bất kể outcome — một probe thất bại quay lại như một 200 với status: down và một lý do đã được làm sạch, không phải một lỗi truyền tải.
Server in-process đóng gói sẵn (endpoint rỗng) dispatch cục bộ và không probe được — việc probe nó bị từ chối với một lỗi giải thích rằng đăng ký không có endpoint. Bạn chỉ probe các server BYO có một URL.
Mọi thay đổi đăng ký đều vô hiệu hóa cache tool theo từng workspace của gateway ngay lập tức, nên một server vừa được kết nối, bị tắt, hoặc được probe lại có hiệu lực ở lần kết nối kế tiếp thay vì sau một cửa sổ cache.

​
4. Sau khi nó được kết nối

Một khi một server được đăng ký và probe ok, các tool của nó được kiểm soát:
  • Mọi cuộc gọi được đánh giá. Mỗi tools/call chạy qua chính sách firewall của bạn trên bề mặt mcp trước khi nó đến được server của bạn. Thu hẹp phạm vi các quy tắc bằng tool_name_glob: github.* giờ khi bạn đã biết tên các tool.
  • Khóa chặt bề mặt. Mặc định từ chối các tool mà bạn không cho phép tường minh — xem allow-list các tool MCP.
  • Kiểm soát nơi nó vươn tới. Soạn một quy tắc egress để một tool không thể fetch các host tùy ý.
  • Theo dõi các thay đổi. Một server bạn đã tin tưởng có thể thay đổi các định nghĩa tool của nó sau đó; phòng vệ rug-pull gắn cờ trôi dạt đó.

​
5. Tham chiếu API

Tất cả các route console đều theo phạm vi workspace và xác thực bằng session / access token của bạn. Việc đọc danh sách mở cho bất kỳ Member nào (secrets masked); mọi việc ghi yêu cầu Developer+.
Method & pathVai tròMục đích
GET /api/workspace/firewall/mcp_serversMemberLiệt kê các server (secrets + endpoint masked).
GET /api/workspace/firewall/mcp_servers/:idMemberMột server đơn lẻ, masked.
POST /api/workspace/firewall/mcp_serversDeveloper+Đăng ký một server (409 khi name trùng lặp).
PUT /api/workspace/firewall/mcp_serversDeveloper+Cập nhật một server (id trong body).
DELETE /api/workspace/firewall/mcp_servers/:idDeveloper+Soft-delete; giải phóng name.
POST /api/workspace/firewall/mcp_servers/:id/probeDeveloper+Probe khả năng tiếp cận + khám phá các tool.
Một SDK proxy của agent đọc registry runtime qua token có phạm vi gateway tại GET /api/v1/firewall/mcp_servers (chỉ các server đã bật). Về cách xác thực phía đó, xem xác thực MCP gateway.
Tại sao lại kết nối qua OrcaRouter? Để một nơi duy nhất thấy mọi lời gọi tool — một kết nối, một chính sách, một log được audit, và credential được tiêm vào lúc dispatch thay vì rải rác khắp các config agent. Đọc bảo mật AI agent và mối đe dọa đầu độc tool MCP để biết động lực.

​
Liên quan

Tổng quan bảo mật MCP

Toàn bộ mô hình quản trị MCP, từ đầu đến cuối.

Firewall: các MCP server

Hành vi runtime của gateway và các verdict theo từng cuộc gọi.

Xác thực gateway

Phát hành và thu hẹp phạm vi token mà agent của bạn kết nối với.

Checklist tin cậy

Mọi thứ cần xác minh trước khi bạn tin tưởng một server mới.