Tools-Übersicht

OpenClaw bringt einen leistungsstarken Satz eingebauter Tools mit, die deinen Agenten echte Fähigkeiten geben – von der Browser-Steuerung über Shell-Befehle bis zu Web-Suche und Sitzungsverwaltung. Anders als die älteren openclaw-*-Skills, die Shell-Aufrufe brauchten, sind das erstklassige typisierte Tools, die direkt über die Agent-Runtime laufen.

Was verfügbar ist

Der Kern-Toolset umfasst:

Browser-Automatisierung: Chrome/Brave mit Snapshots, Klicks und Screenshots steuern
Shell-Ausführung: Befehle mit Hintergrund-Unterstützung und Freigabe-Gates ausführen
Web-Zugriff: Suche (Brave/Perplexity) und Abruf von Seiten mit Content-Extraktion
Sitzungsverwaltung: Agent-Sitzungen auflisten, inspizieren und Nachrichten senden
Node-Steuerung: Gepaarte macOS/iOS-Geräte für Benachrichtigungen, Kamera und Bildschirmaufnahme ansprechen
Zeitplanung: Cron-Jobs und Wakeup-Events verwalten
Gateway-Operationen: Gateway neu starten oder Config-Updates vor Ort anwenden
Canvas: Visuelles Canvas steuern (nur macOS-Node)
Bildanalyse: Bilder mit dem konfigurierten Vision-Modell analysieren

Plus optionale Plugin-Tools wie Lobster (Workflow-Engine) und LLM Task (strukturierte JSON-Ausgaben).

Zugriff steuern

Global allow/deny

Der einfachste Weg, Tools einzuschränken, sind tools.allow und tools.deny in der Config. Deny gewinnt immer.


{
  "tools": {
    "deny": ["browser", "exec"]
  }
}

Du kannst *-Wildcards nutzen – "*" bedeutet alle Tools. Die Zuordnung ist case-insensitiv.

Tool-Profile

Statt jedes Tool einzeln aufzulisten, ein Profil als Basis nutzen:

minimal: Nur session_status (nur-lesen Sitzungsinfo)
coding: Datei-Tools + Runtime + Sitzungen + Memory + Bildanalyse
messaging: Nachrichtenversand + grundlegende Sitzungs-Tools
full: Alles (wie kein Profil gesetzt)

Pro Agent überschreiben mit agents.list[].tools.profile.

Beispiel – standardmäßig Messaging, zusätzlich Slack- und Discord-Tools erlauben:


{
  "tools": {
    "profile": "messaging",
    "allow": ["slack", "discord"]
  }
}

Beispiel – Coding-Profil überall, aber Shell-Ausführung verweigern:


{
  "tools": {
    "profile": "coding",
    "deny": ["group:runtime"]
  }
}

Pro-Provider-Einschränkungen

Manchmal willst du strengere Kontrolle für bestimmte Modell-Provider. Mit tools.byProvider das Tool-Set nach Provider oder sogar konkretem Modell einschränken.

Das wird nach dem Basis-Profil, aber vor den globalen Allow-/Deny-Listen angewendet.


{
  "tools": {
    "profile": "coding",
    "byProvider": {
      "google-antigravity": { "profile": "minimal" }
    }
  }
}

Du kannst sogar ein einzelnes Modell ansprechen:


{
  "tools": {
    "byProvider": {
      "openai/gpt-5.2": { "allow": ["group:fs", "sessions_list"] }
    }
  }
}

Tool-Gruppen (Shortcuts)

Statt Tools einzeln aufzulisten, Gruppen nutzen:

group:runtime → exec, bash, process
group:fs → read, write, edit, apply_patch
group:sessions → sessions_list, sessions_history, sessions_send, sessions_spawn, session_status
group:memory → memory_search, memory_get
group:web → web_search, web_fetch
group:ui → browser, canvas
group:automation → cron, gateway
group:messaging → message
group:nodes → nodes
group:openclaw → alle eingebauten Tools (ohne Plugin-Tools)

Beispiel:


{
  "tools": {
    "allow": ["group:fs", "browser", "web_search"]
  }
}

Plugin-Tools

Plugins können eigene Tools zusätzlich zum eingebauten Set hinzufügen. Siehe Plugins für die Installation und Skills dafür, wie Tool-Anweisungen in Prompts injiziert werden.

Bekannte Plugin-Tools:

Lobster: Workflow-Runtime mit typisierten Pipelines und Freigabe-Gates
LLM Task: Strukturierte Nur-JSON-LLM-Tasks ausführen (gut für Workflow-Schritte)

Wenn deine Allowlist nur Plugin-Tool-Namen referenziert, die nicht geladen sind, loggt OpenClaw eine Warnung und hält die Core-Tools verfügbar (damit du dich nicht versehentlich aussperrst).

Tool-Referenz

`exec`

Shell-Befehle im Workspace ausführen. Vorder- und Hintergrund-Ausführung.

Wichtige Parameter:

command (erforderlich)
yieldMs (Auto-Hintergrund nach dieser Verzögerung, Standard 10s)
background (sofort im Hintergrund starten)
timeout (beenden, wenn länger laufend, Standard 30 Minuten)
host (sandbox | gateway | node) – wo ausführen
security (deny | allowlist | full) – Durchsetzungsmodus
ask (off | on-miss | always) – Freigabe-Abfragen
elevated (auf Gateway-Host mit voller Sicherheit ausführen, wenn erlaubt)
pty (in Pseudoterminal für interaktive CLIs)

Mit dem process-Tool Hintergrund-Sitzungen abfragen, Eingabe senden oder beenden.

Bei Sandbox läuft exec standardmäßig in Docker. host=gateway oder elevated=true für Ausführung auf dem Host (erfordert Freigabe-Gates, außer du erlaubst es explizit).

Siehe Exec-Tool und Exec-Freigaben.

`browser`

Dediziertes Chrome/Brave-Profil steuern (getrennt von deinem persönlichen Browser).

Typische Aktionen:

status, start, stop – Browser-Prozess verwalten
tabs, open, focus, close – Tab-Steuerung
snapshot – Textdarstellung der Seite (AI- oder ARIA-Format)
screenshot – Pixel aufnehmen (ganze Seite oder bestimmte Elemente)
act – klicken, tippen, hovern, ziehen, auswählen, Formulare ausfüllen
navigate, console, pdf, upload, dialog – erweiterte Operationen

Multi-Profil: Mit profile benannte Browser-Configs ansprechen (z. B. clawd, work, chrome). Profile können auf lokale verwaltete Browser oder Remote-CDP-Endpunkte zeigen.

Ziel:

target=sandbox – Browser in Docker (Sandboxing muss aktiv sein)
target=host – Browser deiner Gateway-Maschine
target=node – Browser auf gepaartem macOS/Linux-Node

Snapshots liefern ref-IDs (numerisch wie 12 oder rollenbasiert wie e12), die du mit act für Klick/Tippen nutzt. Keine fragilen CSS-Selektoren.

Siehe Browser-Tool für Setup, Profile und Chrome-Extension-Relay.

`web_search`

Web mit Brave Search API (Standard) oder Perplexity Sonar durchsuchen.

Parameter:

query (erforderlich)
count (1–10 Ergebnisse)
country, search_lang, ui_lang, freshness (optionale Filter)

Setup: Brave-API-Key von brave.com/search/api , dann openclaw configure --section web oder BRAVE_API_KEY setzen.

Ergebnisse werden standardmäßig 15 Minuten gecacht.

Siehe Web-Tools für Perplexity-Setup und Konfiguration.

`web_fetch`

URL abrufen und lesbaren Inhalt extrahieren (HTML → Markdown oder Plain Text).

Parameter:

url (erforderlich)
extractMode (markdown | text)
maxChars (lange Seiten kürzen)

Standardmäßig Readability-Extraktion, optional Firecrawl-Fallback für JS-lastige oder Bot-geschützte Seiten.

Siehe Web-Tools und Firecrawl.

`process`

Hintergrund-exec-Sitzungen verwalten.

Aktionen:

list – aktive/kürzliche Sitzungen anzeigen
poll – auf neue Ausgabe prüfen (gibt Exit-Code bei Ende zurück)
log – Ausgabe mit Offset/Limit zeilenbasiert lesen
write, send-keys, submit, paste – Eingabe senden
kill, clear, remove – Sitzungen beenden oder aufräumen

Hintergrund-Sitzungen sind pro Agent. Ein Agent sieht die Sitzungen eines anderen nicht.

`apply_patch`

Strukturierte Mehrdatei-Änderungen in einem Aufruf anwenden. Nützlich, wenn ein normales edit-Tool zu fragil wäre.

Format:


*** Begin Patch
*** Add File: path/to/new.txt
+line content
*** Update File: src/app.ts
@@
-old line
+new line
*** Delete File: obsolete.txt
*** End Patch

Experimentell. Aktivieren mit tools.exec.applyPatch.enabled (nur OpenAI-Modelle).

Siehe Apply Patch.

`sessions_list` / `sessions_history` / `sessions_send` / `sessions_spawn`

Mit Agent-Sitzungen über Konversationen hinweg arbeiten.

sessions_list: Aktive Sitzungen mit optionalen Nachrichtenvorschau auflisten
sessions_history: Transkript einer Sitzung lesen (per Key oder ID)
sessions_send: Nachricht an eine andere Sitzung senden und optional auf Antwort warten
sessions_spawn: Sub-Agent-Lauf im Hintergrund starten (meldet sich bei Fertigstellung)
session_status: Aktuelle Sitzungsinfo anzeigen oder Modell überschreiben

Nützlich für Multi-Agent-Setups, Delegation oder Prüfung, was in einer anderen Konversation passiert ist.

Siehe Session-Tool und Subagenten.

`agents_list`

Auflisten, welche Agent-IDs die aktuelle Sitzung mit sessions_spawn ansprechen kann. Respektiert pro-Agent-Allowlists (agents.list[].subagents.allowAgents).

`message`

Nachrichten senden und kanalspezifische Aktionen (Reaktionen, Bearbeiten, Umfragen, Threads usw.) in Discord, Telegram, Slack, WhatsApp, Google Chat, Signal, iMessage und MS Teams ausführen.

Typische Aktionen:

send – Text + optionale Medien (Bilder, Dateien, Standorte)
react, edit, delete, pin
poll – Umfragen erstellen (WhatsApp, Discord, MS Teams)
thread-create, thread-reply – Thread-Verwaltung
search, permissions, member-info, role-info
Moderation: timeout, kick, ban

Kanalspezifische Features wie Adaptive Cards (Teams), Sticker (Telegram) und Emoji-Uploads laufen über dasselbe Tool.

`cron`

Geplante Jobs auf dem Gateway verwalten.

Aktionen:

list, status – Jobs und kürzliche Läufe anzeigen
add, update, remove – CRUD-Operationen
run – Job sofort auslösen
wake – System-Event in die Warteschlange (optional mit sofortigem Heartbeat)

Jobs nutzen Standard-Cron-Syntax und können Shell-Befehle ausführen oder Agent-Nachrichten auslösen.

Siehe Cron CLI.

`gateway`

Gateway neu starten oder Konfigurations-Updates ohne Stopp anwenden.

Aktionen:

restart – SIGUSR1 für In-Process-Neustart senden
config.get, config.schema – aktuelle Config inspizieren
config.apply, config.patch – Config validieren und schreiben, dann neu starten
update.run – Updates anwenden und neu starten

Nützlich für Agenten, die ihre eigene Infrastruktur verwalten.

Neustart erfordert commands.restart: true in der Config.

`nodes`

Gepaarte macOS/iOS-Geräte entdecken und steuern.

Aktionen:

status, describe – was verbunden ist und welche Fähigkeiten verfügbar sind
pending, approve, reject – Pairing-Anfragen verwalten
notify – macOS-Benachrichtigungen senden
run – Befehle auf dem Node ausführen (erfordert Freigabe-Gates)
camera_snap, camera_clip, screen_record – Medien aufnehmen
location_get – GPS-Koordinaten (iOS/macOS mit Standortberechtigung)

Bilder kommen als Media-Blöcke zurück. Videos liefern Dateipfade. Die Node-App muss im Vordergrund sein für Kamera/Bildschirmaufnahme.

Siehe Nodes CLI.

`canvas`

Visuelles Canvas auf macOS-Nodes steuern.

Aktionen:

present, hide, navigate – Canvas-Fenster anzeigen/verstecken/steuern
eval – JavaScript im Canvas-Kontext ausführen
snapshot – Screenshot aufnehmen
a2ui_push, a2ui_reset – A2UI-Rendering (v0.8-Format)

Nutzt intern node.invoke. Wählt automatisch einen Node, wenn nur einer verbunden ist.

`image`

Bild mit dem konfigurierten Vision-Modell analysieren.

Parameter:

image (Pfad oder URL)
prompt (optional, Standard: „Describe the image.“)
model (optionale Überschreibung)
maxBytesMb (Größenobergrenze)

Nur verfügbar, wenn agents.defaults.imageModel konfiguriert ist oder OpenClaw ein Bildmodell aus deinem Hauptmodell + Auth-Profilen ableiten kann.

Typische Muster

Browser-Automatisierung:

browser status / browser start
browser snapshot für die Seitenstruktur
browser act mit ref aus dem Snapshot zum Klicken/Tippen
browser screenshot zur visuellen Bestätigung

Shell-Aufgaben:

exec mit Befehl
Bei Hintergrund: mit process pollen bis fertig
Ausgabe mit process log lesen

Multi-Agent-Delegation:

sessions_spawn für Sub-Agent-Aufgabe
Läuft im Hintergrund und meldet sich bei Fertigstellung
sessions_history zum Inspizieren, was passiert ist

Node-Aufnahme:

nodes status für verbundene Geräte
nodes camera_snap oder nodes screen_record
Ergebnisse als Media-Blöcke oder Dateipfade

Sicherheitshinweise

exec und nodes run sind mächtig. Freigabe-Gates (ask: "on-miss" oder "always") und Allowlists nutzen bei Ausführung auf echten Hosts.
Kamera/Bildschirmaufnahme erfordert Einwilligung. Immer zuerst mit nodes describe Berechtigungen prüfen.
Elevated-Modus (elevated: true oder host: "gateway" mit security: "full") umgeht einige Sicherheitsprüfungen – nur für vertrauenswürdige Agenten.
Browser-Isolation: Das clawd-Browser-Profil ist getrennt von deinem persönlichen Browser, kann aber trotzdem eingeloggte Sitzungen nutzen. Vorsichtig behandeln.

Siehe Sicherheit und Sandboxing für das Gesamtbild.

Wie Tools unter der Haube funktionieren

Wenn ein Agent läuft, stellt OpenClaw Tools auf zwei Wegen bereit:

System-Prompt: Menschenlesbare Beschreibungen, damit das Modell weiß, was verfügbar ist
Tool-Schemas: Typisierte Funktionsdefinitionen, die an die Modell-API gesendet werden (OpenAI Function Calling, Anthropic Tools usw.)

Ist ein Tool an keiner der beiden Stellen, sieht das Modell es nicht. Darum werden Allow-/Deny-Listen vor dem Aufbau des Prompts durchgesetzt – nicht erlaubte Tools kommen nie beim Modell an.

Empfohlene Lektüre

Browser – vollständiger Browser-Automatisierungs-Leitfaden
Exec + Exec-Freigaben – Shell-Ausführung mit Sicherheits-Gates
Web-Tools – Such- und Fetch-Setup
Skills – eigene Tools mit SKILL.md-Dateien
Subagenten – an Hintergrund-Agenten delegieren
Slash-Befehle – Chat-Befehle und Direktiven

Tools-Übersicht

Was verfügbar ist

Zugriff steuern

Global allow/deny

Tool-Profile

Pro-Provider-Einschränkungen

Tool-Gruppen (Shortcuts)

Plugin-Tools

Tool-Referenz

exec

browser

web_search

web_fetch

process

apply_patch

sessions_list / sessions_history / sessions_send / sessions_spawn

agents_list

message

cron

gateway

nodes

canvas

image

Typische Muster

Sicherheitshinweise

Wie Tools unter der Haube funktionieren

Empfohlene Lektüre

`exec`

`browser`

`web_search`

`web_fetch`

`process`

`apply_patch`

`sessions_list` / `sessions_history` / `sessions_send` / `sessions_spawn`

`agents_list`

`message`

`cron`

`gateway`

`nodes`

`canvas`

`image`