Tools Invoke (HTTP)
OpenClaw’s Gateway exposes a simple HTTP endpoint for invoking a single tool directly. It is always enabled and uses Gateway auth plus tool policy. Like the OpenAI-compatible/v1/* surface, shared-secret bearer auth is treated as trusted operator access for the whole gateway.
POST /tools/invoke- Same port as the Gateway (WS + HTTP multiplex):
http://<gateway-host>:<port>/tools/invoke
Authentication
Uses the Gateway auth configuration. Common HTTP auth paths:- shared-secret auth (
gateway.auth.mode="token"or"password"):Authorization: Bearer <token-or-password> - trusted identity-bearing HTTP auth (
gateway.auth.mode="trusted-proxy"): route through the configured identity-aware proxy and let it inject the required identity headers - private-ingress open auth (
gateway.auth.mode="none"): no auth header required
- When
gateway.auth.mode="token", usegateway.auth.token(orOPENCLAW_GATEWAY_TOKEN). - When
gateway.auth.mode="password", usegateway.auth.password(orOPENCLAW_GATEWAY_PASSWORD). - When
gateway.auth.mode="trusted-proxy", the HTTP request must come from a configured non-loopback trusted proxy source; same-host loopback proxies do not satisfy this mode. - If
gateway.auth.rateLimitis configured and too many auth failures occur, the endpoint returns429withRetry-After.
Security boundary (important)
Treat this endpoint as a full operator-access surface for the gateway instance.- HTTP bearer auth here is not a narrow per-user scope model.
- A valid Gateway token/password for this endpoint should be treated like an owner/operator credential.
- For shared-secret auth modes (
tokenandpassword), the endpoint restores the normal full operator defaults even if the caller sends a narrowerx-openclaw-scopesheader. - Shared-secret auth also treats direct tool invokes on this endpoint as owner-sender turns.
- Trusted identity-bearing HTTP modes (for example trusted proxy auth or
gateway.auth.mode="none"on a private ingress) honorx-openclaw-scopeswhen present and otherwise fall back to the normal operator default scope set. - Keep this endpoint on loopback/tailnet/private ingress only; do not expose it directly to the public internet.
gateway.auth.mode="token"or"password"+Authorization: Bearer ...- proves possession of the shared gateway operator secret
- ignores narrower
x-openclaw-scopes - restores the full default operator scope set:
operator.admin,operator.approvals,operator.pairing,operator.read,operator.talk.secrets,operator.write - treats direct tool invokes on this endpoint as owner-sender turns
- trusted identity-bearing HTTP modes (for example trusted proxy auth, or
gateway.auth.mode="none"on private ingress)- authenticate some outer trusted identity or deployment boundary
- honor
x-openclaw-scopeswhen the header is present - fall back to the normal operator default scope set when the header is absent
- only lose owner semantics when the caller explicitly narrows scopes and omits
operator.admin
Request body
tool(string, required): tool name to invoke.action(string, optional): mapped into args if the tool schema supportsactionand the args payload omitted it.args(object, optional): tool-specific arguments.sessionKey(string, optional): target session key. If omitted or"main", the Gateway uses the configured main session key (honorssession.mainKeyand default agent, orglobalin global scope).dryRun(boolean, optional): reserved for future use; currently ignored.
Policy + routing behavior
Tool availability is filtered through the same policy chain used by Gateway agents:tools.profile/tools.byProvider.profiletools.allow/tools.byProvider.allowagents.<id>.tools.allow/agents.<id>.tools.byProvider.allow- group policies (if the session key maps to a group or channel)
- subagent policy (when invoking with a subagent session key)
- Exec approvals are operator guardrails, not a separate authorization boundary for this HTTP endpoint. If a tool is reachable here via Gateway auth + tool policy,
/tools/invokedoes not add an extra per-call approval prompt. - Do not share Gateway bearer credentials with untrusted callers. If you need separation across trust boundaries, run separate gateways (and ideally separate OS users/hosts).
exec— direct command execution (RCE surface)spawn— arbitrary child process creation (RCE surface)shell— shell command execution (RCE surface)fs_write— arbitrary file mutation on the hostfs_delete— arbitrary file deletion on the hostfs_move— arbitrary file move/rename on the hostapply_patch— patch application can rewrite arbitrary filessessions_spawn— session orchestration; spawning agents remotely is RCEsessions_send— cross-session message injectioncron— persistent automation control planegateway— gateway control plane; prevents reconfiguration via HTTPnodes— node command relay can reach system.run on paired hostswhatsapp_login— interactive setup requiring terminal QR scan; hangs on HTTP
gateway.tools:
x-openclaw-message-channel: <channel>(example:slack,telegram)x-openclaw-account-id: <accountId>(when multiple accounts exist)
Responses
200→{ ok: true, result }400→{ ok: false, error: { type, message } }(invalid request or tool input error)401→ unauthorized429→ auth rate-limited (Retry-Afterset)404→ tool not available (not found or not allowlisted)405→ method not allowed500→{ ok: false, error: { type, message } }(unexpected tool execution error; sanitized message)