Wie GPT entscheidet, ein Tool aufzurufen: Tool‑Call‑Modell und die Rolle von Beschreibungen

1. Warum sich überhaupt mit tool-call befassen

Vereinfacht gesagt arbeitet eine normale Web‑App nach dem Schema „Benutzer klickt auf einen Knopf – wir rufen eine Funktion auf“. In der Welt der ChatGPT‑Apps ist das anders: Der Benutzer sagt etwas, das Modell denkt nach und erstellt – wenn es das für sinnvoll hält – einen strukturierten Toolaufruf (tool-call).

Das heißt, Sie schreiben nicht:

onClick={() => callSuggestGiftsApi(formData)}

sondern stattdessen:

1. Sie beschreiben das Tool suggest_gifts (Name, Beschreibung, Argument‑Schema).
2. Sie erklären dem Modell im system-prompt, warum dieses Tool nützlich ist.
3. Sie überlassen dem Modell die Entscheidung: Es entscheidet selbst, wann und wie es das Tool aufruft.

Daraus folgt, dass man sehr früh zwei Dinge verstehen sollte:

1. GPT sieht Ihren Backend‑Code nicht. Es sieht nur die „Kopfzeile“ des Tools: Name, Beschreibung und das Parametrierschema.
2. Wie „klug“ das Modell Ihre App nutzt, hängt fast direkt davon ab, wie Sie diese Beschreibungen formuliert haben. Gute Beschreibungen sind Ihr „Prompt für das Tool“.

Diese Vorlesung handelt genau von diesem „Gehirn“ zwischen Benutzer und Ihrem Server.

2. Mentales Modell des tool-call: Was passiert eigentlich

Beginnen wir mit dem Gesamtbild. Ein typisches Szenario für GiftGenius:

1. Benutzer: „Finde ein Geschenk für einen 30‑jährigen Freund, Budget 100 US‑Dollar, er liebt Videospiele“.
2. GPT liest diese Nachricht und schaut, welche Tools verfügbar sind. In unserer App gibt es zum Beispiel suggest_gifts.
3. GPT entscheidet: „Um gut zu antworten, muss ich dieses Tool aufrufen.“
4. Statt einer normalen Textantwort generiert es eine Struktur: Toolname + JSON‑Argumente.
5. Der ChatGPT‑Client sieht: „Aha, das ist ein tool-call“, und leitet ihn an Ihren MCP/Server weiter.
6. Ihr Server führt die Geschäftslogik aus und liefert eine strukturierte Ausgabe zurück.
7. GPT erhält das Ergebnis, liest es und formuliert dann auf Basis der Tool‑Antwort eine verständliche Antwort für den Benutzer und/oder aktualisiert ein Widget.

Aus Sicht des OpenAI‑API ist das derselbe Mechanismus wie LLM-function-calling: In der Modellantwort erscheint statt normalem Text ein Objekt mit dem name des Tools und den arguments, und die finish_reason wird als tool_calls markiert. Das Modell führt keinen Code selbst aus – es schlägt nur vor, welches Tool aufzurufen ist; den tatsächlichen Aufruf übernimmt der Client (ChatGPT/Apps SDK).

Das sieht ungefähr so aus (vereinfachte Abfolge):

sequenceDiagram
    participant U as Benutzer
    participant G as GPT (Modell)
    participant C as ChatGPT‑Client
    participant S as Ihr MCP/Backend

    U->>G: "Finde ein Geschenk für einen Freund..."
    G->>C: tool-call: { name: "suggest_gifts", args: {...} }
    C->>S: HTTP /mcp tools/call (suggest_gifts, args)
    S-->>C: Ergebnis (JSON mit einer Liste von Geschenken)
    C-->>G: tool result
    G-->>U: Antwort + aktualisiertes Widget

Die wichtigste Erkenntnis: Sie schreiben nicht if (userAskedAboutGifts) callSuggestGifts(). Sie definieren ein Tool und seine Beschreibung – die Entscheidung trifft das Modell.

3. Was das Modell sieht: System Prompt + Liste der Tools

Um zu verstehen, wie GPT entscheidet, muss klar sein, welche Informationen es im Moment der Auswahl hat.

Vereinfacht sieht das Modell:

• den System‑Prompt Ihrer App (dazu später ausführlich in Modul 5);
• den Dialogverlauf: Benutzernachrichten, eigene Antworten, Ergebnisse früherer Tool‑Calls;
• die Liste der verfügbaren Tools (tools) mit ihren Namen, Beschreibungen und Parametriermodellen;
• zusätzliche Annotationen der Tools (readOnly/destructive usw.).

Es sieht nicht:

• Funktionsimplementierungen;
• SQL‑Abfragen;
• die Struktur Ihrer Tabellen;
• den Inhalt eines privaten Repositorys mit dem Service.

Später sprechen wir ausführlich über MCP. Fürs Erste genügt: Auf MCP‑Ebene werden Tools als Deskriptoren deklariert – jedes hat einen name, eine description und ein inputSchema (JSON Schema). Beim Handshake fragt ChatGPT den MCP‑Server nach der Liste der Tools und betrachtet sie danach als verfügbare „Aktionen“.

Beispiel eines solchen Deskriptors für GiftGenius (vereinfachtes JSON):

{
  "name": "suggest_gifts",
  "description": "Findet Geschenkideen anhand von Alter, Interessen und Budget",
  "inputSchema": {
    "type": "object",
    "properties": {
      "age": { "type": "integer" },
      "budget": { "type": "number" }
    },
    "required": ["age", "budget"]
  }
}

Das Modell „liest“ hier nur Text und Struktur: was age ist, was budget ist, was das Tool insgesamt macht. Die nächste Vorlesung behandelt genau, wie man inputSchema gut beschreibt. Jetzt geht es darum, wie aus dieser Beschreibung die Entscheidung entsteht: „Ich rufe suggest_gifts auf.“

4. Wie ein tool-call aus API‑Sicht aussieht

ChatGPT ruft die tools Ihres MCP‑Servers grob so auf, wie ein OpenAI‑Agent Funktionen in Ihrem Backend aufruft. Im ChatGPT‑Apps SDK ist es etwas stärker gekapselt, aber die Mechanik ist die gleiche.

Stellen wir uns vor, unser Backend stellt eine normale Anfrage an das OpenAI‑API und übergibt dabei das Tool suggest_gifts, das das Modell in seiner Antwort aufrufen kann:

const response = await openai.responses.create({
  model: 'gpt-5-mini',
  messages: [
    {
      role: 'user',
      content: 'Ich brauche ein Geschenk für einen 30-jährigen Freund, Budget 100 US-Dollar'
    }
  ],
  tools: [ // hier übergeben wir die Liste von Funktionen, die das LLM „aufrufen“ kann
    {
      name: 'suggest_gifts',
      description: 'Wählt Geschenke nach Alter, Budget und Interessen aus',
      parameters: {
        type: 'object',
        properties: {
          age: { type: 'integer' },
          budget: { type: 'number' }
        },
        required: ['age', 'budget']
      }
    }
  ]
});

Wenn sich das Modell entscheidet, ein Tool aufzurufen, erhalten Sie als Antwort keinen Text, sondern eine Assistenten‑Nachricht etwa in dieser Form:

{
  "role": "assistant",
  "tool_calls": [
    {
      "id": "call_1",
      "name": "suggest_gifts",
      "arguments": "{\"age\":30,\"budget\":100}"
    }
  ],
  "content": []
}

So teilt das LLM Ihrem Backend mit, dass es die Funktion suggest_gifts(30,100) aufrufen lassen möchte.

Wichtig sind hier drei Dinge:

1. Der Toolname (name) – das Modell setzt hier exakt den String ein, den Sie in der Tools‑Beschreibung im ersten Request angegeben haben.
2. Die Argumente (arguments) – ein JSON‑String, konstruiert anhand von parameters/inputSchema.
3. Das Fehlen einer normalen Textantwort (zunächst) – stattdessen erhalten Sie die Struktur zum Toolaufruf.

Im ChatGPT‑App‑Betrieb ist es dasselbe: Das Modell liefert „Ich möchte suggest_gifts mit diesen Parametern aufrufen“, und der Client (ChatGPT) stellt einen HTTP‑Request an Ihren MCP/Server: tools/call mit Toolname und Argumenten.

5. Wie das Modell entscheidet: Tool oder Text

Nun zum spannendsten Teil: Wann denkt GPT überhaupt an Ihre Tools?

Vereinfacht funktioniert der Mechanismus so:

1. Das Modell sieht die aktuelle Benutzernachricht und den Kontext.
2. Intern gibt es eine „Schicht“, die die nächste Assistenten‑Nachricht generiert. Statt immer nur normalen Text auszugeben, kann das Modell einen von mehreren Abschlusswegen wählen:
   • normale Textantwort (finish_reason: "stop");
   • einen oder mehrere tool-calls (finish_reason: "tool_calls");
   • manchmal andere Varianten (z. B. „es wird eine weitere Benutzernachricht benötigt“).
3. Diese Wahl wird beeinflusst von:
   • wieviel der Benutzerwunsch den in Ihren Tools beschriebenen Aufgaben ähnelt;
   • wieweit Ihre Toolbeschreibung explizit sagt „nutze mich genau in diesem Fall“;
   • Informationen aus dem App‑System‑Prompt, die im Apps SDK konfiguriert werden.

Anschaulich gesagt „hält“ das Modell Ihr Tool an die aktuelle Anfrage. Wenn die Beschreibung lautet: „Findet Geschenke nach Alter und Interessen“, der Benutzer aber „Analyse des Staatshaushalts“ verlangt, wird das Modell nicht einmal versuchen, das Tool aufzurufen. Ist die Beschreibung zu vage – „macht coole Sachen“ – versteht das Modell nicht, bei welchen Anfragen es das Tool überhaupt einsetzen soll.

Eine interessante Nuance: Das Modell muss das Tool nicht aufrufen, selbst wenn Sie es beschrieben haben. GPT kann entscheiden: „Hier ist alles klar, ich antworte selbst ohne Tool‑Call.“ Deshalb werden wir im weiteren Verlauf aktiv üben, Toolbeschreibungen so zu schreiben, dass die Nutzung für das Modell maximal offensichtlich und vorteilhaft ist.

6. Toolname: warum tool1 eine schlechte Idee ist

Der Name des Tools ist im Grunde der Bezeichner, den das Modell in seinen Aufrufen verwendet. Es wirkt wie ein rein technisches Feld, in der Praxis beeinflusst der Name jedoch das Modellverhalten stark.

Wenn Sie Ihr Tool tool1 nennen, kann das Modell damit nichts anfangen – es ist nur eine Zeichenfolge. Nennen Sie es hingegen suggest_gifts, search_products oder fetch_user_orders, liefert der Name selbst bereits ein starkes Signal, worum es bei dem Tool geht.

Denken Sie daran, wie Sie selbst fremden Code lesen. Bei einer Funktion calculateCartTotal wissen Sie ungefähr, was zu erwarten ist. Das Modell braucht denselben „semantischen Anker“.

Für GiftGenius sind sinnvolle Toolnamen etwa:

suggest_gifts
search_products
get_product_details
create_order

Gute Namen sind:

• kurz, aber aussagekräftig;
• im einheitlichen Stil (snake_case, lateinische Schrift, Verb_Substantiv);
• sie beschreiben eine konkrete Aktion.

Keine gute Idee ist es, verschiedene Aktionen in einem Tool zu mischen, etwa do_all_gift_stuff. Für das Modell wird es schwerer zu erkennen, wann genau es dieses Tool verwenden soll. In den nächsten Vorlesungen sehen wir, wie dadurch das Argumentschema zerfasert und das Debugging erschwert wird.

7. Toolbeschreibung: Ihr Prompt für das Modell

Wenn der Name die Überschrift ist, dann ist die description die Mini‑Dokumentation – aber nicht für einen menschlichen Entwickler, sondern für GPT. Der Entwickler liest den Code; das Modell nicht. Es stützt sich beim Entscheiden, wann es das Tool aufruft und welche Argumente einzusetzen sind, auf den Beschreibungstext.

Schreiben Sie die Beschreibung im Stil einer „Gebrauchsanweisung“:

• wann das Tool zu verwenden ist;
• welche Einschränkungen es hat;
• was es nicht tun soll.

Nehmen wir unser suggest_gifts. Hier drei Varianten von Beschreibungen.

Zu breit:

"Wählt Geschenke aus."

Das Modell versteht nicht, aus welchem Anlass, für wen, mit welchen Parametern. Dieses Tool „konkurriert“ im Kopf des Modells mit seinem Allgemeinwissen über Geschenke – oft entscheidet es sich dann, einfach selbst zu antworten.

Zu eng:

"Wählt Geschenke nur für jüngere Brüder zum Geburtstag aus."

Damit verbieten wir die Nutzung fast immer. Jeder andere Kontext – Mutter, Kollege, Jubiläum – „passt nicht“, und das Modell wird den Aufruf vermeiden.

Optimal:

"Verwende dieses Tool, wenn Geschenke für eine Person anhand von Alter, Art der Beziehung (Freund, Partner, Kollege usw.), Budget und Interessen auszuwählen sind.
Rufe es nicht für Fragen auf, die nichts mit Geschenken zu tun haben (z. B. Politik oder Wetter)."

Hier ist klar beschrieben, was das Tool macht, welche Parameter es dafür gibt und wann es aufzurufen ist – plus eine Negativbedingung: für welche Anfragen es besser nicht genutzt wird.

Das Modell „mag“ solche klaren Rahmen. Je präziser Sie benennen, bei welchen Benutzerformulierungen (Intents) das Tool passt, desto vorhersehbarer verhält sich Ihre App.

Mini‑Übung

Nehmen Sie jetzt gleich Ihre zukünftige App (muss nicht um Geschenke gehen) und formulieren Sie für eines Ihrer Tools drei Beschreibungen: sehr breit, sehr eng und ausgewogen. Testen Sie anschließend, wie sich GPT mit den verschiedenen Versionen verhält.

8. Parameterschema: wie es der Entscheidung hilft

Über JSON Schema sprechen wir ausführlich in der nächsten Vorlesung; für das Verständnis von tool-calls reicht ein Gefühl für die Ebene darüber.

Wenn das Modell ein Tool aufrufen will, muss es:

1. verstehen, welche Argumente das Tool überhaupt erwartet.
2. diese Werte aus dem Benutzertext (oder dem Kontext) extrahieren.
3. ein JSON mit diesen Argumenten konstruieren.

Dafür hat die Toolbeschreibung ein Parametriermodell (inputSchema), das dem Modell sagt:

• welche Felder es gibt (age, budget, relationship_type, interests usw.);
• welche Felder verpflichtend sind (required);
• welche Typen vorkommen (integer, number, string, Arrays usw.);
• mitunter – welche Werte zulässig sind (enum) und Feldhinweise (description).

Ein einfaches TypeScript‑Interface für die Parameter von suggest_gifts kann so aussehen:

interface SuggestGiftsParams {
  age: number;
  relationship_type: 'friend' | 'partner' | 'colleague';
  budget: number;
  interests?: string[];
}

Auf Modellebene wird das in ein JSON Schema überführt, und das Modell erkennt an Namen und Beschreibung der Felder unter anderem, dass:

• age aus Formulierungen wie „30 Jahre“, „für einen Teenager“ zu entnehmen ist;
• budget aus „Budget 100 US‑Dollar“, „bis 50 Euro“;
• relationship_type aus „Freund“, „Kollege“;
• interests aus „er liebt Videospiele“.

Geben Sie ein Schema ohne Beschreibungen und mit abstrakten Feldnamen (a, b, c), wird das Modell wesentlich häufiger Fehler beim Befüllen der Argumente machen. Darauf kommen wir im Modul zur Lokalisierung und zu UX‑Hinweisen zurück. Die Kernidee ist einfach: Das Schema ist nicht nur Backend‑Validierung, sondern vor allem eine Anleitung für das Modell, was wohin gehört.

Wir haben gesehen, wie das Schema dem Modell hilft, Argumente richtig zusammenzustellen. Neben „was und wie aufrufen“ ist jedoch auch wichtig „darf das jetzt überhaupt aufgerufen werden und wie sicher ist das“. Hier kommen Berechtigungen und Metainformationen über Tools ins Spiel.

9. Berechtigungen und Kontext: Nicht jedes Tool ist immer verfügbar

Neben Name, Beschreibung und Parameterschema gibt es noch eine wichtige Dimension – Sicherheit und Zugriff. Tools in einer realen App unterscheiden sich stark im „Gefährdungsgrad“. Etwas anderes ist die Suche nach Geschenken in einem öffentlichen Katalog, etwas anderes das Abbuchen von Geld von der Karte eines Nutzers.

Apps SDK und MCP ermöglichen, das in Toolbeschreibungen und Annotationen abzubilden – zum Beispiel als read-only oder destructive.

Die Idee:

• Tools, die nur öffentliche Daten lesen (search_products, get_weather), können ohne zusätzliche Bestätigungen aufgerufen werden.
• Tools, die etwas verändern (create_order, cancel_order, charge_user), werden als „destruktiv“ markiert. Die ChatGPT‑UI kann beim Nutzer eine zusätzliche Bestätigung einholen („Sind Sie sicher, dass Sie die Bestellung aufgeben möchten?“), und das Modell wird sie ohne explizite Nachfrage seltener vorschlagen.

In späteren Modulen – wenn wir MCP konfigurieren – sehen Sie, wie diese Annotationen (_meta, destructiveHint, readOnlyHint) in echten JSON‑Deskriptoren aussehen, wie sie den UX beeinflussen und wie ChatGPT „Are you sure?“-Dialoge vor dem Aufruf bildet. Wichtig ist jetzt:

• GPT berücksichtigt nicht nur den Beschreibungstext, sondern auch Metainformationen zur Sicherheit.
• Ein Tool, das Authentifizierung benötigt, wird erst genutzt, wenn der Benutzer angemeldet ist (oder die App das nötige Token erhalten hat).

Das ist ein weiterer Faktor für die Entscheidung „Tool starten oder nicht“: Selbst wenn das Tool inhaltlich passt, kann es an Berechtigungen scheitern – dann wählt das Modell einen anderen Weg.

10. Woher Tools in ChatGPT überhaupt kommen

Architektonisch gelangen Tools auf zwei Hauptwegen zum Modell.

Erstens aus der Konfiguration Ihrer ChatGPT‑App. Wenn Sie die App registrieren, geben Sie an, welche MCP‑Server (und deren Tools) angebunden sind oder welche eingebauten Tools die App selbst hat. Beim Start einer Sitzung erhält ChatGPT diese Konfiguration und weiß damit, welche Tools verfügbar sind.

Zweitens direkt aus MCP. MCP (Model Context Protocol) definiert einen Standardweg, wie der Client (hier ChatGPT/Apps SDK) erfährt, was Ihr Server kann: Er stellt tools/list, erhält JSON mit Toolbeschreibungen und speichert sie als Capabilities. Die Details behandeln wir im separaten MCP‑Modul – hier genügt das Grundprinzip.

Schematisch:

flowchart LR
  A[ChatGPT Client] -->|handshake| B[MCP Server]
  B -->|tools/list| A
  A -->|übermittelt die Liste| G[GPT Model]

Danach wird die Toolliste Teil des Modellkontexts. Wenn Sie Schema oder Beschreibung eines Tools auf dem Server ändern und die App neu starten, erhält ChatGPT den neuen Deskriptor beim nächsten Handshake und das Modell trifft seine Aufrufentscheidungen entsprechend neu.

Und ein wichtiger Praxispunkt: Wenn Sie nur das Backend (die Toolimplementierung) ändern, weiß das Modell nichts davon. Wenn Sie hingegen name/description/schema verändern, ändern Sie tatsächlich das „Gehirn“ der App. Manchmal ist es hilfreicher, eine Zeile in der description zu justieren, als 200 Zeilen Heuristik‑Code zu schreiben.

11. Anwendung auf GiftGenius: Ein Tool, das das Modell aufrufen will

Verknüpfen wir das alles mit unserer Übungsapp GiftGenius. Nehmen wir an, wir haben bereits einen MCP‑Server oder eine Backend‑Schicht, in der wir Tools registrieren. Registrieren wir das Tool suggest_gifts mit server.registerTool(...).

Ein einfacher TypeScript‑Entwurf (noch ohne echte Logik):

// pseudo-mcp-server/tools/suggestGifts.ts
server.registerTool(
  'suggest_gifts', // Toolname
  {
    title: 'Geschenkauswahl',
    description:
      'Verwende dieses Tool, um Geschenkideen anhand von Alter, ' +
      'Art der Beziehung und Budget auszuwählen. Nicht für Fragen verwenden, die nichts mit Geschenken zu tun haben.',
    inputSchema: { // Beschreibung der Tool-Parameter
      type: 'object',
      properties: {
        age: { type: 'integer', description: 'Alter der zu beschenkenden Person in Jahren' },
        relationship_type: {
          type: 'string',
          description: 'Beziehungsart: friend, partner, colleague'
        },
        budget: {
          type: 'number',
          description: 'Maximales Geschenkbudget in der Währung des Benutzers'
        }
      },
      required: ['age', 'budget']
    }
  },
  async ({ age, relationship_type, budget }) => { // Funktions-/Toolcode
    // Die echte Logik folgt später
    return { suggestions: [] };
  }
);

Achten Sie auf die Details, die wir schon hier durchdacht haben, obwohl die Logik noch ein „Stub“ ist:

• Name: suggest_gifts statt tool1.
• Beschreibung: erklärt ausdrücklich, wann das Tool aufzurufen ist – und wann nicht.
• Feldbeschreibungen: helfen dem Modell, Benutzersprache korrekt auf Argumente zu mappen.

Wenn ein Benutzer schreibt: „Finde ein Geschenk für einen Kollegen für 50 US‑Dollar“, sieht das Modell:

• Es gibt ein Tool namens suggest_gifts mit einer Beschreibung zur Geschenkauswahl;
• es hat die Felder age, relationship_type, budget;
• budget ist „maximales Geschenkbudget“, relationship_type ist „Beziehungsart: friend, partner, colleague“.

Selbst wenn Nutzer ungenau formulieren („bis Fünfzig“, „für den Projektpartner“), hat das Modell genug Kontext, um den JSON der Argumente sinnvoll zusammenzustellen.

Sobald unser Tool tatsächlich arbeitet (im Modul zu Backend und MCP), sind Sie in der Thematik bereits fit: GPT wird es vorhersehbar aufrufen – weil wir Schnittstelle und Beschreibung gut entworfen haben.

12. Kleine Übung für Sie

Damit das Thema nicht rein theoretisch bleibt, empfehle ich ein kleines Experiment direkt nach der Vorlesung.

Nehmen Sie zunächst ein Szenario aus GiftGenius oder denken Sie sich eine neue App aus. Notieren Sie sich eine Funktion, die Sie dem Modell explizit geben wollen – etwas wie search_products, find_hotels, calculate_shipping.

Überlegen Sie dann dafür drei Paare „Name + Beschreibung“:

1. Sehr abstrakter Name und Beschreibung.
2. Zu konkrete (fast Special‑Case).
3. Gut ausbalancierter Name + Beschreibung, die klar sagt, wann das Tool aufzurufen ist und was es nicht tun soll.

Optional können Sie anschließend mit einem normalen OpenAI‑SDK eine einfache Anfrage mit diesen Varianten bauen und beobachten, wie sich das Modellverhalten ändert: Wird das Tool aufgerufen, wie füllt es die Argumente? In Research zu diesem Thema gibt es genau eine Übung dieser Art für suggest_gifts.

13. Typische Fehler beim Entwurf von tool-call und Beschreibungen

Fehler Nr. 1: Tools nennen tool1, handler, doStuff.
Solches Naming ist für das Modell völlig nutzlos. GPT errät keine „Entwicklerintentionen“ aus dem Dateinamen; es braucht einen semantisch verständlichen Namen. Geben Sie eine Sammlung aus tool1, tool2, tool3 ohne Beschreibungen, wird das Tool praktisch nicht aufgerufen: Das Modell versteht schlicht nicht, was jedes einzelne macht, und ignoriert sie entweder oder wählt zufällig.

Fehler Nr. 2: Die description wie Kommentare für Menschen behandeln.
Viele schreiben in die Beschreibung etwas Formalistisches wie „Funktion zur Geschenkauswahl“ und meinen, die Details stünden ja im Code. Aber den Code sieht das Modell nicht – nur den Beschreibungstext und das Parameterschema. Eine unklare Beschreibung wird zur Quelle von Halluzinationen: GPT versucht entweder selbst zu antworten, wenn das Tool nötig gewesen wäre, oder ruft das Tool in seltsamen Situationen auf.

Fehler Nr. 3: Die Beschreibung zu breit oder zu eng machen.
Schreiben Sie „macht coole Sachen“, versteht das Modell die Einsatzgrenzen nicht. Schreiben Sie „wählt ein Geschenk nur für den jüngeren Bruder zum 18. Geburtstag“, verbieten Sie die Nutzung praktisch immer. Die optimale Beschreibung steckt einen klaren Aufgabenbereich (Geschenkauswahl anhand mehrerer Parameter) ab, listet die Schlüsselparameter (Alter, Beziehung, Budget, Interessen) und sagt, für welche Fragen das Tool nicht verwendet werden soll.

Fehler Nr. 4: Das Parameterschema nicht als Teil des „Prompts“ betrachten.
Manche Entwickler sehen JSON Schema nur als Server‑Validierung. Tatsächlich analysiert das Modell aktiv Feldnamen, Typen und Beschreibungen, um zu verstehen, welche Daten aus dem Benutzertext zu extrahieren sind. Benennen Sie ein Feld x ohne Beschreibung und machen es optional, füllt GPT es chaotisch oder gar nicht. Ein korrektes Schema mit klaren Namen und kurzen Beschreibungen reduziert ungültige tool-calls deutlich.

Fehler Nr. 5: Erwarten, dass das Modell „verpflichtet“ ist, ein Tool aufzurufen.
Entwickler wundern sich manchmal: „Warum hat GPT mein Tool nicht aufgerufen, obwohl es existiert?“ Die Antwort ist fast immer: Aus der Beschreibung oder dem System‑Prompt folgt nicht, dass das Tool genau für diese Frage gebraucht wird, oder die Anfrage lag in einer Zone, in der das Modell meint, selbst besser antworten zu können.

Fehler Nr. 6: Mehrere unterschiedliche Aktionen in einem Tool mischen.
Mitunter möchte man ein universelles manage_orders, das Bestellungen sucht, neue erstellt und alte storniert. Für Menschen noch erklärbar – für das Modell ein nebulöses Tool ohne klare Grenzen. GPT versteht schlechter, wann es zu verwenden ist, und füllt Argumente schwieriger – intern entsteht eine Menge optionaler Felder. Besser, solche Aktionen in mehrere fokussierte Tools (get_order, create_order, cancel_order) mit klaren Beschreibungen und Schemata zu trennen.

Fehler Nr. 7: Berechtigungen und Sicherheit im Tool‑Design nicht berücksichtigen.
Wenn Sie ein Tool beschreiben, das destruktive Aktionen ausführen kann (Geld abbuchen, Daten löschen), es aber nicht als „destructive“ markieren und den Einsatzbereich in der Beschreibung nicht begrenzen, erzeugen Sie Risiko. Die ChatGPT‑UI wird keine zusätzliche Bestätigung erfragen, und das Modell könnte das Tool auch in „Grenzfällen“ vorschlagen. Korrekte Annotationen und eine sorgfältige Beschreibung („nur nach ausdrücklicher Zustimmung des Benutzers verwenden“) reduzieren solche Risiken bereits auf der Ebene des Tool‑Calls.