Skip to main content
O Gateway do OpenClaw expõe um endpoint HTTP para invocar diretamente uma única ferramenta. Ele está sempre habilitado e usa a autenticação do Gateway juntamente com a política de ferramentas. Assim como na interface compatível com OpenAI /v1/*, a autenticação bearer por segredo compartilhado é tratada como acesso confiável de operador a todo o Gateway.
  • POST /tools/invoke
  • Mesma porta que o Gateway (multiplexação de WS + HTTP): http://<gateway-host>:<port>/tools/invoke
  • Tamanho máximo padrão do corpo da solicitação: 2 MB

Autenticação

Usa a configuração de autenticação do Gateway. Caminhos comuns de autenticação HTTP:
  • autenticação por segredo compartilhado (gateway.auth.mode="token" ou "password"): Authorization: Bearer <token-or-password>
  • autenticação HTTP confiável com identidade (gateway.auth.mode="trusted-proxy"): encaminhe pelo proxy configurado com reconhecimento de identidade e permita que ele injete os cabeçalhos de identidade necessários
  • autenticação aberta em entrada privada (gateway.auth.mode="none"): nenhum cabeçalho de autenticação é necessário
Observações:
  • mode="token" usa gateway.auth.token (ou OPENCLAW_GATEWAY_TOKEN).
  • mode="password" usa gateway.auth.password (ou OPENCLAW_GATEWAY_PASSWORD).
  • mode="trusted-proxy" exige que a solicitação HTTP venha de uma origem de proxy confiável configurada; proxies local loopback no mesmo host exigem gateway.auth.trustedProxy.allowLoopback = true explicitamente.
  • Chamadores internos no mesmo host que contornam o proxy podem usar gateway.auth.password / OPENCLAW_GATEWAY_PASSWORD como alternativa direta local. Qualquer evidência dos cabeçalhos Forwarded, X-Forwarded-* ou X-Real-IP mantém a solicitação no caminho do proxy confiável.
  • Se gateway.auth.rateLimit estiver configurado e ocorrerem muitas falhas de autenticação, o endpoint retornará 429 com Retry-After.

Limite de segurança (importante)

Trate este endpoint como uma interface de acesso total de operador para a instância do Gateway.
  • A autenticação bearer HTTP aqui não é um modelo de escopo restrito por usuário.
  • Um token/senha válido do Gateway para este endpoint deve ser tratado como uma credencial de proprietário/operador.
  • Nos modos de autenticação por segredo compartilhado (token e password), o endpoint restaura os padrões normais de operador com acesso total, mesmo que o chamador envie um cabeçalho x-openclaw-scopes mais restrito.
  • A autenticação por segredo compartilhado também trata invocações diretas de ferramentas neste endpoint como turnos enviados pelo proprietário.
  • Os modos HTTP confiáveis com identidade (autenticação por proxy confiável ou gateway.auth.mode="none" em uma entrada privada) respeitam x-openclaw-scopes quando presente e, caso contrário, recorrem ao conjunto normal de escopos padrão do operador.
  • Mantenha este endpoint apenas em local loopback, tailnet ou entrada privada; não o exponha diretamente à internet pública.
Matriz de autenticação:

Corpo da solicitação

Campos:
  • tool / name (string, obrigatório): nome da ferramenta a ser invocada. name tem precedência se ambos forem enviados.
  • action (string, opcional): incorporado a args.action se o esquema da ferramenta aceitar uma propriedade action e args ainda não tiver definido uma.
  • args (objeto, opcional): argumentos específicos da ferramenta.
  • sessionKey (string, opcional): chave da sessão de destino. Se for omitida ou for "main", o Gateway usará a chave configurada da sessão principal (respeita session.mainKey e o agente padrão, ou global no escopo de sessão global).
  • agentId (string, opcional): resolve a chave de sessão desse agente. Retorna erro 400 se houver conflito com um sessionKey explícito que já esteja associado a outro agente.
  • idempotencyKey (string, opcional): usado para derivar um ID estável de chamada de ferramenta para a invocação.
  • dryRun (booleano, opcional): reservado para uso futuro; atualmente ignorado.

Comportamento de política e roteamento

A disponibilidade das ferramentas é filtrada pela mesma cadeia de políticas usada pelos agentes do Gateway:
  • tools.profile / tools.byProvider.profile
  • tools.allow / tools.byProvider.allow
  • agents.<id>.tools.allow / agents.<id>.tools.byProvider.allow
  • políticas de grupo (se a chave da sessão estiver associada a um grupo ou canal)
  • política de subagente (ao invocar com a chave de sessão de um subagente)
Se uma ferramenta não for permitida pela política, o endpoint retornará 404. Observações importantes sobre os limites:
  • As aprovações de execução são proteções operacionais, não um limite de autorização separado para este endpoint HTTP. Se uma ferramenta estiver acessível aqui por meio da autenticação do Gateway e da política de ferramentas, /tools/invoke não adicionará uma solicitação extra de aprovação por chamada.
  • Se exec estiver acessível aqui, trate-o como uma interface de shell com capacidade de alteração. Negar write, edit, apply_patch ou ferramentas HTTP de gravação no sistema de arquivos não torna a execução do shell somente leitura.
  • Não compartilhe credenciais bearer do Gateway com chamadores não confiáveis. Se precisar separar limites de confiança, execute gateways distintos (idealmente sob usuários ou hosts distintos do sistema operacional).
O HTTP do Gateway também aplica por padrão uma lista rígida de bloqueio (mesmo que a política da sessão permita a ferramenta): cron, gateway e nodes também são exclusivos do proprietário: mesmo fora dessa lista de bloqueio padrão, chamadores que não sejam proprietários não podem invocá-los por esta interface. Personalize a lista geral de bloqueio por meio de gateway.tools:
gateway.tools.allow é uma substituição de exposição, não uma elevação de escopo. Nos modos HTTP com identidade, cron, gateway e nodes permanecem indisponíveis para chamadores sem identidade de proprietário/administrador (operator.admin), mesmo quando incluídos em gateway.tools.allow. A autenticação bearer por segredo compartilhado continua seguindo a regra de operador totalmente confiável descrita acima. Para ajudar as políticas de grupo a resolver o contexto, você pode definir opcionalmente:
  • x-openclaw-message-channel: <channel> (exemplo: slack, telegram)
  • x-openclaw-account-id: <accountId> (quando existem várias contas)
  • x-openclaw-message-to: <target> (destino de entrega para a política da ferramenta de mensagens)
  • x-openclaw-thread-id: <threadId> (contexto da thread para a política da ferramenta de mensagens)

Respostas

Exemplo

Relacionados