调一个没注册的工具。直接被拒

故意请求未登记的工具：

{
"tool"这方面，"delete_everything","arguments": {}
}

Gateway 返回 "TOOL_NOT_FOUND",而且不做任何模糊匹配或交给模型自行处理。

痛点：The system used to “pretend it knows everything”. Without a whitelist,a model could fabricate an arbitrary tool name and rely on ad‑hoc server logic—introducing security holes. 注册表强制所有可调用工具必须来源于白名单。

参数校验必须压在服务端

note_search` 要求传入 "query". 若省略则返回 "ARGUMENT_MISSING: query";补全后才会正常运行，

This validation lives on server side;front‑end may provide friendly hints but cannot be sole defense line. 任意入口只要能够到达 Gateway。就必须统一使用同一套 schema 校验，否则就会出现“页面绕过校验”的漏洞。

注册表让端侧知道需要哪些参数

The UI reads same alert.inputSchema,renders required fields automatically,and informs users that “ boundary comes from server。not hard‑coded buttons”.

鸿蒙端从注册表把能力列表生成出来

The page no longer hard‑codes a static array of tools. Core logic:

async loadTools {
const resp = await fetch;
this.tools = await resp.json;
// @State tools
}

The UI becomes a lightweight capability console:

The numbers displayed are computed from returned registration table—not hard‑coded constants.

执行结果回到同一个面板

User clicks execution button of time_now. The front‑end builds a request with a unique "tool-registry-" + timestamp + requestId,POSTs to /tools/call。and renders JSON response in a “Recent Execution” panel.

This keeps whole interaction in one page—no navigation,no modal pop‑ups—making it easy to correlate “which tool was clicked” with “what result was returned”. Low‑risk tools like time_now serve as quick sanity checks for end‑to‑end flow.

端侧又压了一层比风险等级更保守的白名单

The registration table lists *N* tools,*M* marked low risk. However,front‑end applies an additional whitelist in its `canRun` logic:

canRun: boolean {
return!tool.needConfirm &&;}

This means that even if a tool is labeled low risk by server,only those explicitly verified on this client version are actually clickable. Ors appear as “read‑only”。while tools requiring confirmation show as “locked”. Thus client adds an extra safety layer: **prefer fewer open actions over potential overexposure**.

三种状态统一处理

• If `canRun` → render an active button;
• If `tool.needConfirm` → render a locked button with tooltip “requires confirmation”;不过，

能力边界这样就定住了

The workflow now clearly defines boundaries on both sides:

• The model can only pick tools listed in `/tools`;其实，
• The server rejects any request with missing/invalid parameters;
• The registration table marks which tools need user confirmation;
.
• The client enforces an additional whitelist so that only vetted low‑risk tools are truly executable.

This turns what used to be “modify two code bases every time we add a capability” into “update one JSON registration file and reload”. The register captures all essential metadata—description,trigger conditions,required parameters。risk level and sample response—so nothing is left to guesswork.

Pain Point Summary:

• No visibility of available capabilities → solved by dynamic `/tools` loading.
• Poor risk awareness → solved by `riskLevel` & UI labeling.
• Poor traceability → solved by unified `requestId`.
• Potential for arbitrary tool injection → solved by strict whitelist enforcement.

This registration‑driven approach ensures that adding or updating abilities becomes a single configuration change rar than scattered code edits across frontend and backend.