MCP 服务器上线前审核

上游 MCP 服务器是 Agent 将携带调用方上下文调用的任意远程代码。在 AISIX 中，注册 MCP 服务器与将其发布到网关是两个独立动作：每个 MCP 服务器都有 approval_status，只有已批准的服务器才会下发到网关。

等待审核或已被拒绝的服务器不会出现在网关上。即使调用方 API Key 明确将其工具加入白名单，该服务器也不会出现在 tools/list 中，工具也无法调用。决定服务器是否可访问的是批准状态，而不是 enabled 标记。

这带来两项保障。成员可以提交 MCP 服务器，但无权直接发布；对一个服务器的批准也不能被另一个服务器继承。已审核配置的变更要么由拥有批准权限的人直接完成，要么进入待审核状态。等待审核不会造成停机：已上线服务器会继续提供获批配置，直到新的变更也被批准。

审核状态

approval_status	网关上的状态	进入该状态的操作
pending_review	不下发	提交服务器或修改提案。
approved	下发到 allowed_environments	批准服务器，或通过 POST /mcp_servers 注册服务器。
rejected	不下发	拒绝服务器。

对已上线服务器提出变更时，其状态不会离开 approved。变更会在单独的 pending_change 字段中等待审核，其他字段仍描述网关当前提供的配置。参见对已上线服务器提出变更。

此功能推出前注册的服务器会被视为已批准，因此升级不会中断工具流量。

谁可以批准

批准和注册使用相同权限：对 mcp_servers 的 write 权限。Owner 和 Admin 拥有该权限。能够直接发布服务器的人不会因审核自己的服务器而获得额外能力，因此将两者绑定不会削弱控制；单管理员组织也可以自行批准提交。

可以分离的是另一项权限：对 mcp_server_submissions 的 write 权限。拥有该权限、但没有 mcp_servers write 权限的自定义角色，可以提交服务器、修改提案，以及对已上线服务器提出变更，但不能发布任何内容。应将此角色授予负责集成自身工具的团队。

提交服务器

本页示例使用 AISIX Cloud Admin API。按照 On-Premises AISIX Cloud 快速入门运行服务栈、创建具有写入权限的 Admin Token 和环境，然后设置：

export AISIX_CP="http://localhost:8080/api"
export AISIX_TOKEN="YOUR_ADMIN_TOKEN"
export ENV_ID="YOUR_ENVIRONMENT_ID"

通过 POST /mcp_server_submissions 提交服务器。请求体与 POST /mcp_servers 相同：

curl -sS -X POST "$AISIX_CP/mcp_server_submissions" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "runbooks",
    "url": "https://mcp.example.com/runbooks",
    "auth_type": "none",
    "allowed_environments": ["'"$ENV_ID"'"]
  }'

服务器已经注册，但尚未发布：

{
  "mcp_server": {
    "id": "6f64f080-17d7-44d9-b995-6a353e71f6bc",
    "name": "runbooks",
    "url": "https://mcp.example.com/runbooks",
    "enabled": true,
    "allowed_environments": ["YOUR_ENVIRONMENT_ID"],
    "approval_status": "pending_review",
    "submitted_at": "2026-07-29T09:30:00Z"
  }
}

请注意，虽然 enabled 为 true，且 allowed_environments 指定了环境，但任何网关都无法访问该服务器。这些字段描述服务器获批后将生效的配置。

在控制台中，MCP 服务器页面会在对应行显示 Pending review 徽标，页面顶部还会显示等待审核的服务器数量。

批准或拒绝

通过读取 GET /mcp_servers 返回的 approval_status，列出等待审核的服务器：

curl -sS "$AISIX_CP/mcp_servers" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  | jq '.data[] | select(.approval_status == "pending_review") | {id, name, url}'

批准前请检查上游。确认 URL 符合预期，名称不是现有服务器名称的近似仿冒，并确认凭证属于网关预期代表的账户。

批准服务器后，它会发布到 allowed_environments 指定的环境：

export MCP_SERVER_ID="YOUR_MCP_SERVER_ID"

curl -sS -X POST "$AISIX_CP/mcp_servers/$MCP_SERVER_ID/approve" \
  -H "Authorization: Bearer $AISIX_TOKEN"

也可以附带原因拒绝服务器。备注会随服务器返回，提交者可以据此修改：

curl -sS -X POST "$AISIX_CP/mcp_servers/$MCP_SERVER_ID/reject" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"review_notes": "Not on the trusted registry. Use the internal mirror."}'

批准已经批准的服务器或拒绝已经拒绝的服务器会返回 400。带有暂存变更的服务器属于例外，参见对已上线服务器提出变更。

修改提案

使用 PATCH /mcp_server_submissions/{id} 修正提交内容并将其重新放回审核队列：

curl -sS -X PATCH "$AISIX_CP/mcp_server_submissions/$MCP_SERVER_ID" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://mcp.internal.example.com/runbooks"}'

对于尚未发布的服务器，变更会直接应用到记录上，服务器继续留在队列中。对于已上线服务器，相同调用会暂存变更，而不会立即应用。

对已上线服务器提出变更

只拥有 mcp_server_submissions write 权限的角色不能发布内容，因此它对已上线服务器的修改不能自行生效；但变更等待审核期间也不能让服务器下线，所以 PATCH /mcp_server_submissions/{id} 会暂存该变更：

curl -sS -X PATCH "$AISIX_CP/mcp_server_submissions/$MCP_SERVER_ID" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://mcp.internal.example.com/runbooks"}'

响应会返回服务器当前状态，并在旁边显示提案：

{
  "mcp_server": {
    "id": "6f64f080-17d7-44d9-b995-6a353e71f6bc",
    "name": "runbooks",
    "url": "https://mcp.example.com/runbooks",
    "approval_status": "approved",
    "pending_change": {
      "changes": { "url": "https://mcp.internal.example.com/runbooks" },
      "submitted_by": "YOUR_USER_ID",
      "submitted_at": "2026-07-30T09:30:00Z"
    }
  }
}

pending_change 以外的每个字段都描述网关当前提供的配置。在整个审核窗口内，Agent 仍可列出并调用该服务器的现有工具。

提案会在提交时验证，无效变更会在此时被拒绝，而不会等到批准阶段。提议的凭证与正式凭证一样会加密存储且不会返回；pending_change.secret_set 用于表示提案设置了凭证。同一时间只保留一个提案，再次修改会替换它。

批准操作会在一个步骤中应用并发布暂存变更：

curl -sS -X POST "$AISIX_CP/mcp_servers/$MCP_SERVER_ID/approve" \
  -H "Authorization: Bearer $AISIX_TOKEN"

批准时会再次检查提案指定的环境。如果某个环境在等待期间被删除，变更会被拒绝，而不会只应用一部分。

拒绝操作会丢弃提案。服务器保持 approved 并继续提供原有配置，网关不会发生任何变化：

curl -sS -X POST "$AISIX_CP/mcp_servers/$MCP_SERVER_ID/reject" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"review_notes": "Point it at the internal mirror instead."}'

在控制台中，带有暂存变更的记录会显示变更涉及哪些字段。状态筛选器的 Awaiting review 选项会同时列出未发布的提交和等待变更审核的已上线服务器。

修改已批准服务器

PATCH /mcp_servers/{id} 需要 mcp_servers write 权限，与批准服务器的权限相同。通过该端点进行的编辑本身就是一次发布：服务器继续提供服务，新配置会在调用返回后立即下发到网关。如果要求再次批准，只会让服务器下线，等待同一个人确认自己的变更，因此该端点不会触发重新审批。轮换上游凭证也不会造成工具流量中断。

是否视为新审核取决于变更的字段。修改以下任一字段都会把 reviewed_by 和 reviewed_at 更新为执行变更的人，使记录始终指出是谁对当前上线的上游、凭证和暴露范围负责：

• name：Agent 用来寻址工具的命名空间
• url：上游本身
• transport
• auth_type、secret、client_id、token_url、scopes：凭证及其提交位置
• allowed_environments：服务器暴露到哪些环境
• OpenAPI 后端服务器上的 spec_content、spec_url 和 api_key_header：工具范围

enabled 和 timeout_ms 是已审核配置中的运维参数。修改它们不构成新审核，因此不会改变 reviewed_by 和 reviewed_at。

缩小 allowed_environments 会立即生效：服务器会从不再列出的所有环境中撤回。

仅拥有 mcp_server_submissions write 权限的角色不能使用该端点；其变更会进入审核队列，参见对已上线服务器提出变更。如需让已上线服务器退出网关，请拒绝该服务器。

撤销批准

拒绝没有暂存变更的已批准服务器，会撤销服务器本身的批准：服务器从所有正在提供服务的环境中撤回，调用方将失去其工具。当上游不再可信时使用此操作。

curl -sS -X POST "$AISIX_CP/mcp_servers/$MCP_SERVER_ID/reject" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"review_notes": "Upstream credential compromised."}'

撤销会在数秒内下发到网关，无需重启网关。如需彻底移除注册项，请删除服务器。

拒绝带有暂存变更的服务器时，会先丢弃该变更。要撤销此类服务器，需要调用两次：第一次丢弃提案，第二次撤回服务器。

审计记录

每一步都会记录在组织审计日志中，包括操作用户、时间以及服务器变更前后的状态：

操作	记录时机
submit	提交服务器进行审核，或对已上线服务器提出变更。
create	直接注册并发布服务器。
approve	批准服务器，或应用暂存变更。
reject	拒绝服务器、撤销批准或丢弃暂存变更。
update	修改服务器配置。
delete	删除服务器。

可以在控制台的审计日志中查看这些记录，也可以调用 GET /audit_events?resource_type=mcp_server。

相关内容

• MCP 网关概览：注册服务器并连接客户端
• 控制工具访问权限：调用方 API Key 可以调用哪些工具
• 使用策略管理访问权限：环境级和团队级工具授权