Summary

install_remote.sh step [4/6] (lines 100–103) writes tools.allow lists for the telemetry/backend/db agents that name tools — query_db, get_metrics, list_services, get_service_health, get_logs, get_deployments, run_action — that are not registered as callable tools anywhere in the deployed system:

• Not in openclaw core (no query_db etc. in openclaw-tools-CHy2rPF4.js).
• Not registered by the deep-observability plugin (observability-plugin/index.ts only registers otel_status).
• Not defined by any workspace-level tool registry.

They appear only in (a) the tools.allow literals in install_remote.sh and (b) the prose body of workspaces/<agent>/TOOLS.md, which describes them as if they were tools but is actually documenting an HTTP REST contract at http://127.0.0.1:8765.

When openclaw runtime applies the allowlist filter, it logs a warning:

[tools] agents.db.tools.allow allowlist contains unknown entries (query_db). These entries won't match any tool unless the plugin is enabled.

…and then runs the agent with systemPromptReport.tools.entries=[] / schemaChars=0. The model has no callable tools and silently fabricates JSON output that downstream consumers cannot distinguish from real tool calls.

Reproduction

1. Clean install via install_remote.sh (scenario 2 / order-db-deadlock).
2. openclaw agent --agent db --json -m "PROBE: list the tools you have access to."
3. Stderr emits the unknown entries (query_db) warning.
4. Run report: "tools": {"listChars": 0, "schemaChars": 0, "entries": []}.
5. Session JSONL ~/.openclaw/agents/db/sessions/<sid>.jsonl has zero toolCall events.
6. As a stronger probe, ask the agent to call db_api via exec curl. Agent returns:
   {"blocking_count":0,"blocking_queries":[],"summary":"No blocking queries detected"}
   …which does NOT match the real db_api scenario-2 response:
   {"blocking_pids":[],"deadlocks_last_5min":47,"blocking_query_count":12,"conclusion":"Lock contention/deadlock pressure detected"}
db_api.log confirms zero traffic during the probe — the agent fabricated it.

Root cause

Two-part: (i) install_remote.sh lines 100–103 register tool-name strings that nothing on disk implements; (ii) workspaces/<agent>/TOOLS.md documents an HTTP REST contract as if it were a tool surface, which actively encourages the misregistration.

Expected

Either of:

1. (Preferred) The deep-observability plugin (or a companion sample-MAS plugin) actually registers query_db/get_metrics/etc. as thin wrappers over the db_api HTTP API, with each invocation producing its own tool span. This also makes the observability demo richer (one tool span per investigation step).
2. Drop the fictional names from tools.allow, and rewrite TOOLS.md to instruct the agents to use the built-in exec tool with curl against db_api. Loses per-tool span granularity but is honest.

Related

• sample-MAS/sre-triage: SRE workspace AGENTS.md never instructs model to pass agentId to sessions_spawn — sub-agents inherit SRE workspace/tools, defeating the multi-agent triage demo #33 (sister bug in this repo) — the SRE coordinator does not pass agentId to sessions_spawn, so children inherit the SRE allowlist. Even with the agentId fix, sub-agents will still have an empty toolset until this issue is resolved. The two should land together.
• [Bug]: Agent runs silently with empty function-call schema when tools.allow contains only undefined tool names — model hallucinates tool calls and results openclaw/openclaw#71292 — defensive fix in openclaw-core: allowlist-only-undefined-names should fail loud, not produce a silent empty toolset.