工具权限检查

配置管理员可在管理界面进入 工具权限，选择 MCP 后端或 HTTP 工具组，统一查看已发布和未发布的工具、最终读写类型、所需 Scope、参数资源限制与审批要求。可搜索工具，筛选未分类或未发布的项目。读取目录不会执行工具；HTTP 工具组状态仅表示是否启用，不代表已探测上游连通性。

编辑工具规则 修改当前工具的精确名称规则；MCP 后端的发布状态在同一版本中保存。其他匹配规则继续生效，精确 read 不能覆盖通配 write 或审批规则。表单支持 Scope、JSON Pointer 资源允许值、审批人 Subject、审批人数和加强认证，并保留已有高级审批字段。HTTP 工具发布仍通过现有工具／工具组或 OpenAPI 导入编辑器管理。保存沿用现有版本冲突检查；启用配置审批时，仍须经过审批才生效。

权限检查 逐项解释发布、就绪状态、Scope、资源、客户端 Grant 和审批条件，不调用工具、不运行预览、不创建审批、不占用执行额度。可以选择验收用户，自动载入其当前有效 Scope，再选择该用户在当前服务的有效客户端授权。用户停用或企业组验证过期会给出提示。Scope 仍可手动修改为假设条件；高级选项保留精确 Subject 和 Grant ID 输入。有效 Scope 取用户与授权交集。检查通过不授予执行权：参数 Schema、实时限流、资源版本、预览和上游权限仍在实际执行时校验。仅配置管理员可访问 GET /api/v1/tool-policies?endpoint=<id> 与 POST /api/v1/access-check，后者请求示例：

{"endpoint":"projects","tool":"get_project","scopes":["projects:read"],"arguments":{"project":"work"}}

显式发布与资源范围

工具默认不发布。在后端管理页面/API 中逐项填写获准开放的原始工具名；scope 规则不等于发布名单。名单省略或为空时，工具不出现在目录，也无法直接调用。目录刷新发现新工具时仍默认关闭。手工 HTTP 工具默认禁用，审核后启用；OpenAPI 导入中明确选择要发布的操作。

published_tools: [search]
required_scopes: [mcp:read]
tool_rules:
  - match: search
    effect: read
    required_scopes: [projects:read]
    resource_rules:
      - argument: /project
        allowed_values: [work, sandbox]
      - argument: /body/database
        allowed_values: [reports]

调用必须同时满足当前发布/启停状态、全部所需 scope 和每条匹配的资源规则。argument 是相对于原始 tools/call.arguments 的对象键 JSON Pointer，HTTP 工具的请求体可使用 /body/...（~1 表示 /，~0 表示 ~）。参数必须是允许的字符串，或非空且每项均被允许的字符串数组；缺失、null、数字等类型均拒绝。同一参数的多条规则取交集，一条规则中的多个允许值为任选其一。未配置资源规则时不追加参数资源限制。

允许值精确匹配并区分大小写，不做通配、前缀、目录遍历、URL 解码、文件系统或 SQL 语义判断。应限制工具真正使用的资源选择参数。这是工具共享的允许范围，不会根据用户 claim 判断资源归属；嵌入查询、别名、符号链接和其他资源选择参数仍需后端授权。资源越界返回 MCP 工具错误（isError: true），不会转发，也不会关闭客户端连接。带资源规则的参数会在转发前规范化，消除重复 JSON 键的解析歧义并保留数字精度。

发布、撤销和规则沿用管理 API 的 revision、SQLite/PostgreSQL 持久化；YAML 模式使用 SIGHUP。客户端缓存的目录不代表授权，转发前重新检查当前工具、scope 和资源参数；HTTP 工具管理器替换后，旧处理器不能接纳新调用。已经接纳的调用可能完成，撤销策略不会回滚上游操作。连接测试会返回发现的原始工具名，不会自动将其加入发布名单。

后端本地 tool 规则

tool_rules 按 backend 分别评估，发生在配置的 ID 加到公开 tool name 之前。规则的 match 使用 Go path.Match 匹配原始后端 tool name：整串匹配且区分大小写，因此 admin.* 不会匹配 Admin.Read 或字符串中的子串。每条匹配规则贡献自己的 required_scopes；MCPHub 会合并去重这些 scope，并要求它们与 backend 级 required_scopes 一起全部满足。

配置校验会对 match 和规则 scope 字符串执行现有 ${ENV} 展开；每个 match 必须非空且是有效的 Go path.Match 模式，每条规则必须至少声明 effect、approval、required_scopes、resource_rules 之一；scope 项必须非空，不能含空白或重复，同一 backend 内重复的 match 会被拒绝。

不满足策略的 tool 不会出现在 tools/list。客户端直接调用已知但缺少所需 scope 的 tool 时，MCPHub 返回 403，并给出精确的 WWW-Authenticate challenge，其中包含 error="insufficient_scope"、路径感知的 resource_metadata URL，以及列出缺失 scope 的空格分隔 scope 值。当前目录 generation 没有匹配 tool 的规则会发出一次 warning，但配置仍有效，后续目录刷新出现匹配 tool 后即可生效。tool_rules 支持通过 SIGHUP 热重载，并随重载后的 backend policy 生效。

Backend ID 的唯一性按大小写不敏感检查。tool/prompt 名称保留配置中的 ID；所有公开 resource 或 resource-template URI 使用小写 authority，并解析回配置中的 ID。