Tools und Function Calling: Ihrem Agenten Hände geben

# Tools und Function Calling: Ihrem Agenten Hände geben

Fragen Sie ein Sprachmodell „Wie ist gerade das Wetter in Tokio?“, dann passiert eines von zwei Dingen: Es rät, oder es gibt zu, dass es das nicht weiß. Es hat kein Fenster zur Außenwelt. Es kann schlussfolgern und schreiben, aber es kann nichts *nachschlagen* und nichts *tun*.

Tools ändern das. Ein Tool ist eine Funktion, die Ihr Agent aufrufen kann: eine Wetterabfrage, eine Datenbankabfrage, eine „E-Mail senden“-Aktion, ein Taschenrechner. Sie beschreiben das Tool, das Modell entscheidet, wann es genutzt wird, und plötzlich hat Ihr Agent Hände.

Was ein „Tool“ tatsächlich ist

Ein Tool (in diesem Kontext auch Function genannt) ist ein Stück Code, das Sie bereits haben, so verpackt, dass die KI es anfordern kann.

Sie geben dem Modell drei Dinge:

• Einen Namen, etwa get_weather.
• Eine Beschreibung in einfachem Deutsch: was es tut und wann man es nutzt.
• Die Parameter, die es annimmt, beschrieben in einem strukturierten Format namens JSON Schema (eine Standardart, um festzulegen: „dieses Feld ist Text, jenes eine Zahl, dieses ist Pflicht“).

Das Modell führt Ihren Code nie aus. Es liest nur diese Beschreibungen und sagt, wenn es sinnvoll erscheint: „Bitte rufe get_weather mit city = Tokyo auf.“ Ihr Programm führt die echte Funktion aus und liefert die Antwort zurück.

Hier eine konkrete Tool-Definition. Dieses Format ist bei OpenAI, Anthropic und Google nahezu identisch:

{
  "name": "get_weather",
  "description": "Get the current weather for a city. Use this whenever the user asks about weather, temperature, or conditions.",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "The city name, e.g. 'Tokyo' or 'Paris'"
      },
      "units": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"],
        "description": "Temperature units"
      }
    },
    "required": ["city"]
  }
}

Achten Sie darauf, wie viel die Beschreibung leistet. „Use this whenever the user asks about weather“ ist keine Dekoration. Es ist eine Anweisung. Das Modell liest sie, um zu entscheiden, *ob* es das Tool überhaupt aufruft.

Die Schleife aus Anfrage und Antwort

Hier der Kern der Sache, und ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → ist einfacher, als ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → klingt. Sie und das Modell wechseln sich ab.

1. Sie senden die Nachricht des Nutzers plus die Liste der verfügbaren Tools.

2. Das Modell antwortet auf eine von zwei Arten: mit einer normalen Textantwort oder mit der Anforderung eines Tool-Aufrufs (mit ausgefüllten Argumenten).

3. Fragt es nach einem Tool, führt Ihr Code die echte Funktion aus und sendet das Ergebnis zurück.

4. Das Modell liest das Ergebnis und antwortet entweder dem Nutzer oder fragt nach einem weiteren Tool.

Diese Schleife wiederholt sich, bis das Modell hat, was es braucht. Dieses Hin und Her ist gemeint, wenn von Function Calling oder Tool Calling die Rede ist.

Gehen wir einen echten Austausch durch:

• Nutzer: „Soll ich heute in Tokio einen Regenschirm mitnehmen?“
• Modell: (kein Smalltalk) „Rufe get_weather mit city='Tokyo' auf.“
• Ihr Code: ruft die Wetter-APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen → auf, bekommt {"condition": "rain", "temp_c": 14} zurück.
• Sie senden dieses Ergebnis zurück.
• Modell: „Ja, nehmen Sie einen Regenschirm mit. In Tokio regnet es und es sind etwa 14 °C.“

Das Modell hat eine Entscheidung getroffen (ich brauche Live-Daten), Sie haben die Arbeit erledigt (die APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen → aufgerufen), und das Modell hat aus dem rohen Ergebnis eine hilfreiche Antwort gemacht.

Eine anbieterneutrale Code-Skizze

Die genauen Funktionsnamen unterscheiden sich je Anbieter, aber die Form ist immer dieselbe. Hier die Schleife in Pseudo-Python, die abbildet, wie jedes große SDK arbeitet:

tools = [get_weather_definition]   # das JSON Schema von oben
messages = [{"role": "user", "content": "Umbrella in Tokyo today?"}]

while True:
    response = model.generate(messages=messages, tools=tools)

    if response.wants_tool_call:
        call = response.tool_call          # z. B. get_weather(city="Tokyo")
        result = run_my_function(call.name, call.arguments)

        # das echte Ergebnis zurück in die Konversation geben
        messages.append(response.as_message())
        messages.append({
            "role": "tool",
            "name": call.name,
            "content": result
        })
        continue        # erneut durchlaufen, damit das Modell das Ergebnis nutzen kann

    # kein Tool nötig: wir haben eine finale Antwort
    print(response.text)
    break

Lesen Sie die Schleife noch einmal. Das while True ist der ganze Trick: weitermachen, solange das Modell nach Tools fragt, und stoppen, sobald es eine schlichte Antwort liefert. Ein Agent, der mehrere Tools hintereinander aufrufen kann (einen Kunden nachschlagen, dann seine Bestellungen prüfen, dann eine Antwort entwerfen), ist diese Schleife, die ein paar Mal mehr läuft.

Wenn Sie den zugrunde liegenden Standard hinter diesen JSON-Parameterdefinitionen wollen: Die JSON-Schema-Dokumentation ist die kostenlose, kanonische Referenz.

Gute Tools vs. frustrierende Tools

Das Modell kann nur nutzen, was Sie gut beschreiben. Die meisten Agenten-Fehler lassen sich auf schlampige Tool-Definitionen zurückführen, nicht auf ein „dummes“ Modell.

Schreiben Sie Beschreibungen wie ein Briefing für eine neue Mitarbeiterin

Vage:

> search: sucht Dinge

Klar:

> search_help_articles: Durchsucht die interne Support-Wissensdatenbank nach Artikeln zu Abrechnung, Rückerstattungen und Kontoeinstellungen. Gibt die drei besten Treffer zurück. Nutze dies, bevor du eine Frage zu Richtlinien beantwortest.

Die zweite Version sagt dem Modell, *was drin ist*, *was es zurückbekommt* und *wann es danach greifen soll*.

Halten Sie Parameter knapp

Jeder optionale Parameter ist eine Gelegenheit für das Modell, falsch zu raten. Nutzen Sie enum (eine feste Liste erlaubter Werte), wenn es nur wenige gültige Optionen gibt, etwa ["celsius", "fahrenheit"]. Markieren Sie Pflichtfelder als erforderlich. Weniger und klarere Eingaben bedeuten weniger Fehler.

Liefern Sie Ergebnisse zurück, die das Modell auch lesen kann

Senden Sie saubere, beschriftete Daten zurück:

{"condition": "rain", "temp_c": 14, "city": "Tokyo"}

keine Wand aus rohem HTML und kein 500-Zeilen-Log. Das Modell muss interpretieren, was auch immer Sie zurückgeben, machen Sie es ihm also leicht.

Gängige Tools, die Sie tatsächlich bauen werden

Sobald die Schleife sitzt, sehen Sie überall Tools. Ein paar Muster, die in fast jedem echten Agenten auftauchen:

• Retrieval: eine Wissensdatenbank durchsuchen, ein Dokument nachschlagen, eine Datenbank abfragen. So verankern Sie einen Agenten in *Ihren* Daten.
• Aktionen: eine E-Mail senden, einen Kalendereintrag anlegen, ein Support-Ticket erstellen, eine Bestellung erstatten. Diese *verändern* etwas, behandeln Sie sie also mit Vorsicht (mehr dazu unten).
• Berechnung: ein Taschenrechner, ein Währungsumrechner, ein Helfer für Datumsrechnungen. Modelle sind bekanntermaßen wackelig bei exakter Arithmetik, Mathematik an eine echte Funktion abzugeben ist also ein schneller Gewinn an Zuverlässigkeit.
• Handoffs: einen anderen Agenten oder ein spezialisiertes Modell aufrufen. 2026 ist das üblich: Ein „Router“-Agent entscheidet, welches spezialisierte Tool oder welcher Sub-Agent eine Anfrage bearbeiten soll.

Read-only- vs. Aktions-Tools

Es gibt einen echten Unterschied zwischen einem Tool, das *liest* (Wetter abrufen, Artikel suchen), und einem, das *handelt* (E-Mail senden, Karte belasten).

Lese-Tools sind risikoarm: Im schlimmsten Fall schlägt der Agent etwas nach, das ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → nicht brauchte. Aktions-Tools kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen Schaden anrichten, wenn das Modell danebenliegt. Bauen Sie dafür ein Guardrail ein: menschliche Bestätigung vor dem Senden verlangen, begrenzen, worauf das Tool zugreifen darf, oder jeden Aufruf loggen. Ein „Rückerstattung senden“-Tool sollte den Betrag wohl deckeln und für alles Größere eine Person um Freigabe bitten.

Das ist eine Design-Entscheidung, kein Coding-Detail. Legen Sie vorab fest, welche Tools Ihr Agent eigenständig auslösen darf und welche einen Human in the Loop brauchen.

Wo die Anbieter ins Spiel kommen

Jeder große Anbieter unterstützt dasselbe Tool-Calling-Muster, und jeder liefert ein übergeordnetes Agent SDK (ein Software-Toolkit, das die Schleife für Sie ausführt, sodass Sie das while True nicht selbst schreiben müssen):

• OpenAI Agents SDK
• Claude Agent SDK (Anthropic)
• Google Agent Development Kit (ADK)

Sie übernehmen die Verkabelung: Tools übergeben, Tool-Aufrufe parsen, Ergebnisse zurückspeisen. Das Konzept, das Sie gerade gelernt haben, ist die Basis aller drei. Wenn Sie bereit für anbieterspezifische Syntax sind, sehen Sie sich die Deep-Dive-Blöcke zu jedem Anbieter an.

Noch eine Sache, die Sie kennen sollten: Es gibt einen wachsenden offenen Standard namens Model Context Protocol (MCP), mit dem Sie ein Tool *einmal* definieren und in Agenten verschiedener Anbieter einstecken kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen. Sehen Sie es als Universaladapter für Tools. Bis 2026 wird es zunehmend zur Standardmethode, wie Teams Tools über Systeme hinweg teilen.

Key Takeaways

• Ein Tool ist Ihr Code, für das Modell beschrieben. Geben Sie ihm einen klaren Namen, eine Beschreibung in einfacher Sprache und typisierte Parameter (JSON SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Vollständige Definition ansehen →). Das Modell fordert den Aufruf an; Ihr Code führt ihn tatsächlich aus.
• Der ganze Motor ist eine Schleife. Nachricht plus Tools senden, prüfen, ob das Modell ein Tool will, es ausführen, das Ergebnis zurückspeisen, wiederholen, bis eine schlichte Antwort kommt.
• Schreiben Sie Beschreibungen wie ein Briefing. Nennen Sie, was das Tool tut, was es zurückgibt und wann man es nutzt. Die meisten Agenten-Fehler kommen von vagen Tool-Definitionen, nicht vom Modell.
• Trennen Sie Lese-Tools von Aktions-Tools. Alles, was die Welt verändert (senden, belasten, löschen), braucht ein Guardrail: Bestätigung, Limits oder Logging.
• Starten Sie mit dem Konzept, dann wählen Sie ein SDK. Das OpenAI Agents SDK, das Claude Agent SDK und Google ADK führen alle dieselbe Schleife für Sie aus, und MCP lässt Sie ein Tool über alle hinweg wiederverwenden.