Tool Use erklärt — Wie LLMs externe Funktionen aufrufen

Direkte Antwort: Tool Use (auch Function Calling) ist der Mechanismus, mit dem ein LLM strukturiert externe Funktionen aufruft. Das Modell antwortet statt mit Text mit einem JSON-Tool-Call, der dann von OpenClaw ausgeführt wird. So funktionieren alle Skills und MCP-Integrationen.

Was ist Tool Use?

Tool Use (oder synonym Function Calling) bezeichnet die Fähigkeit moderner LLMs, eigenständig externe Funktionen aufzurufen. Statt nur Text zu generieren, kann das Modell entscheiden: "Für diese Anfrage brauche ich aktuelle Daten — ich rufe das Tool get_weather auf."

Das LLM gibt dann keine normale Text-Antwort, sondern strukturiertes JSON mit dem gewünschten Tool und den Parametern. Die ausführende Schicht (in OpenClaw das Gateway) führt den Call durch und gibt dem Modell das Ergebnis zurück, damit es die finale User-Antwort formulieren kann.

Kontext

Tool Use ist eines der wichtigsten Konzepte hinter modernen Agentic-AI-Systemen. Ohne Tool Use ist ein LLM ein reines Text-Modell ohne Zugriff auf die echte Welt. Mit Tool Use wird es zu einem Agenten, der Software und APIs orchestrieren kann.

OpenAI hat das Konzept 2023 als "Function Calling" populär gemacht; Anthropic zog mit "Tool Use" in der Claude API nach. Heute ist es Standard bei allen großen Modellanbietern und die Grundlage der meisten Agent-Frameworks — auch bei OpenClaw.

Funktionsweise

Der typische Tool-Use-Flow in OpenClaw:

1. Tool-Definition: OpenClaw schickt dem LLM eine Liste verfügbarer Tools im JSON-Schema-Format.
2. User-Anfrage: Du sendest "Wie ist das Wetter in Berlin?"
3. Modell entscheidet: Claude erkennt, dass es kein aktuelles Wetter weiß, und gibt einen Tool-Call zurück: {"tool": "get_weather", "input": {"city": "Berlin"}}.
4. OpenClaw führt aus: Das Gateway ruft die Wetter-API auf und bekommt z.B. "12°C, bewölkt".
5. Modell antwortet: Mit dem Tool-Result formuliert das Modell jetzt die finale Antwort: "In Berlin sind aktuell 12 Grad und es ist bewölkt."

Praxis-Beispiel

Ein Tool wird dem LLM als JSON-Schema deklariert. So sieht z.B. ein simples Wetter-Tool aus:

{
  "name": "get_weather",
  "description": "Holt das aktuelle Wetter fuer eine Stadt.",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "Name der Stadt, z.B. Berlin"
      },
      "unit": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"],
        "default": "celsius"
      }
    },
    "required": ["city"]
  }
}

Wenn das Modell entscheidet, das Tool zu nutzen, antwortet die Anthropic API mit:

{
  "stop_reason": "tool_use",
  "content": [{
    "type": "tool_use",
    "id": "toolu_01ABCD",
    "name": "get_weather",
    "input": {"city": "Berlin", "unit": "celsius"}
  }]
}

OpenClaw führt das Tool aus und sendet das Ergebnis zurück:

{
  "role": "user",
  "content": [{
    "type": "tool_result",
    "tool_use_id": "toolu_01ABCD",
    "content": "12 Grad Celsius, bewoelkt"
  }]
}

Das Modell formuliert dann die finale Antwort an den Nutzer.

Tool Use vs. RAG

RAG (Retrieval-Augmented Generation) und Tool Use werden oft verwechselt. Beide reichern das Modell mit externen Daten an, aber:

| Aspekt | Tool Use | RAG | | --- | --- | --- | | Initiator | Modell entscheidet, wann | Suche läuft immer vor dem Call | | Datenformat | Strukturiert (JSON-Schema) | Frei (Text-Chunks) | | Flexibilität | Mehrere Tools, eines wird gewählt | Embedding-Suche in Vector-DB | | Beispiel | "Sende E-Mail" | "Was steht in unseren Handbüchern?" |

In OpenClaw werden beide oft kombiniert: Der Agent nutzt Tool Use, um eine RAG-Suche zu starten.

Multi-Tool und Tool-Chaining

Ein Modell kann in einer einzelnen Antwort mehrere Tools parallel aufrufen oder sequenziell verkettete Tools nutzen. Beispiel: "Schau in den Kalender, dann buche ein Meeting passend dazu."

OpenClaw kümmert sich um die Orchestrierung. Wichtig ist nur, dass jedes Tool ein klares Schema und eine klare Beschreibung hat, damit das Modell weiß, wann es welches nutzt.

Häufige Fehler / Stolperfallen

1. Vage Tool-Beschreibungen: "Macht etwas mit Daten" hilft dem Modell nicht. Schreibe präzise, was das Tool tut, was es zurückgibt und wann es einzusetzen ist.
2. Zu viele Tools gleichzeitig: Wenn 50 Tools aktiv sind, wird das System-Prompt riesig und das Modell wählt schlechter. Halte aktive Tools schlank.
3. Tool-Schema-Fehler: Required-Felder, Typen und Enums müssen korrekt sein. Ein falsches Schema führt zu Tool-Calls, die nicht ausgeführt werden können.
4. Keine Fehlerbehandlung: Was passiert, wenn der Tool-Call fehlschlägt? OpenClaw gibt das zurück ans Modell — aber dein Tool sollte sinnvolle Error-Messages liefern.
5. Sicherheits-Lücken: Wenn ein Tool sensitive Aktionen erlaubt (E-Mail senden, Dateien löschen), muss eine Bestätigung-Schleife eingebaut sein. Sonst kann Prompt Injection gefährlich werden.

Tool Use und MCP

Wer mit OpenClaw arbeitet, begegnet Tool Use selten direkt — die meisten Tools sind hinter Skills und MCP-Servern versteckt. MCP ist im Grunde ein standardisiertes Wrapper-Protokoll um Tool Use, das die Tool-Definitionen automatisch synchronisiert.

Verwandte Begriffe

• Model Context Protocol (MCP)
• Skills
• Anthropic API
• RAG (Retrieval-Augmented Generation)
• Prompt Injection
• Gateway

Tool Use in der Praxis: Modul 4 der Masterclass.