Tool Calling: Das Modell kennt nur, was du beschreibst

Der Tool-Vertrag ist die gesamte Sicht des Modells

Ein Tool Calling LLM sieht nicht, wie ein Tool intern implementiert ist. Es kennt weder Datenbanktabellen noch API-Clients noch versteckte Geschäftslogik. Für die Auswahl stehen im Wesentlichen der Tool-Name, seine Beschreibung und das Parameterschema zur Verfügung.

Das gilt auch für Function Calling in LLM Agents: Ein Tool mit dem Namen search kann eine Dokumentensuche, eine Websuche oder eine Abfrage im Ticketsystem ausführen. Ohne präzise Beschreibung muss das Modell raten. Ein Name wie update_record sagt ebenfalls nicht, welchen Datensatz es verändert, welche Felder erlaubt sind oder ob der Vorgang rückgängig gemacht werden kann.

Die Tool-Definition ist damit kein nebensächliches Metadatum. Sie ist der Vertrag zwischen Agent und ausführendem System.

Namen und Beschreibungen für Entscheidungen schreiben

Ein guter Name benennt eine konkrete Aufgabe. Eine Beschreibung ergänzt den Kontext, den das Modell für die Auswahl benötigt:

• Wann soll dieses Tool verwendet werden?
• Welche Daten liefert oder verändert es?
• Welche Einschränkungen gelten?
• Wann ist ein anderes Tool die bessere Wahl?

Statt einer Beschreibung wie „Sucht Daten“ ist „Durchsucht die interne Wissensbasis nach freigegebenen Artikeln; nicht für Ticketdaten oder Benutzerkonten verwenden“ deutlich brauchbarer. Das grenzt den Zweck ab und reduziert Überschneidungen mit anderen Agent Tools.

Besonders wichtig ist die Abgrenzung bei ähnlich klingenden Tools. Gibt es etwa eine Suche für Dokumente und eine Suche für Supportfälle, sollten Name und Beschreibung den Unterschied ausdrücklich machen. Andernfalls kann ein Modell zwar syntaktisch korrekt aufrufen, aber die falsche Datenquelle wählen.

Parameter sind Teil der Bedienoberfläche

Parameter brauchen sprechende Namen, einen eindeutigen Typ und klare Regeln. Pflichtfelder, erlaubte Werte und Formate sollten im Schema stehen. Die Beschreibung kann zusätzlich Beispiele und fachliche Hinweise enthalten.

const createSupportTicket = {
  name: "create_support_ticket",
  description:
    "Erstellt ein Support-Ticket. Nur verwenden, wenn eine bestätigte Anfrage vorliegt. Kein Ersatz für eine Wissensbasis-Suche.",
  parameters: {
    type: "object",
    required: ["subject", "description", "priority"],
    properties: {
      subject: {
        type: "string",
        description: "Kurze Zusammenfassung des Problems."
      },
      description: {
        type: "string",
        description: "Fehlerbild, erwartetes Verhalten und bereits bekannte Details."
      },
      priority: {
        type: "string",
        enum: ["low", "normal", "high"],
        description: "high nur bei einem blockierenden Problem."
      }
    }
  }
};

Ein Parameter namens id ist oft zu ungenau. ticket_id, document_id oder user_id verhindern Verwechslungen. Freitextfelder brauchen Hinweise zum erwarteten Inhalt. Bei Datumswerten, Einheiten oder Statuswerten sollte das Tool erlaubte Formate und Werte explizit definieren.

Beispiele in Beschreibungen helfen vor allem dort, wo die Bedeutung nicht allein aus dem Typ folgt. Ein String kann eine Suche, eine Kennung, eine E-Mail-Adresse oder eine Anweisung sein. Das Schema sollte diese Mehrdeutigkeit nicht offenlassen.

Fehlermeldungen sind ein Rückkanal

Ein fehlgeschlagener Tool-Aufruf ist nicht nur ein technischer Fehler. Er ist eine Gelegenheit zur Korrektur im nächsten Schritt. Eine Meldung wie „Ungültige Anfrage“ lässt offen, was geändert werden muss.

Besser ist eine Fehlerantwort, die das betroffene Feld, die Regel und eine Korrekturmöglichkeit nennt. Beispielsweise: priority muss low, normal oder high sein; erhalten: urgent. Oder: document_id fehlt. Verwende die Kennung aus dem Ergebnis von search_documents.

Fehler sollten keine internen Details preisgeben, die für die Korrektur nicht nötig sind. Stacktraces, Zugangsdaten oder interne Infrastrukturinformationen gehören nicht in Tool-Antworten. Relevant sind nur Informationen, mit denen der Agent seinen nächsten Aufruf verbessern kann.

Rechte und Eingaben begrenzen

Nicht jedes Tool muss jedem Agent zur Verfügung stehen. Ein Agent für Recherche benötigt typischerweise Lesezugriffe, aber keine Löschfunktion. Schreibaktionen verdienen zusätzliche Grenzen: engere Parameter, erlaubte Zielbereiche, Validierung und gegebenenfalls eine explizite Bestätigung außerhalb des Modells.

Auch erfolgreiche Tool-Ergebnisse und Modellargumente sind unvertrauter Input. Sie sollten vor der Weiterverarbeitung geprüft werden: Stimmen Typ, Format, Berechtigung und fachliche Regeln? Darf die angeforderte Aktion in diesem Kontext ausgeführt werden? Eine Tool-Beschreibung ersetzt diese Prüfung nicht.

Zuverlässiges Function Calling entsteht daher aus zwei Ebenen: Das Modell erhält einen präzisen Vertrag für die Auswahl und Aufrufbildung. Die Ausführungsschicht validiert trotzdem jeden Aufruf und erzwingt Rechte unabhängig davon, was das Modell vorgeschlagen hat.

Lest eure Tool-Beschreibungen einmal so, als würdet ihr nur sie kennen. Reicht das?