User-Flow: wie GPT eine App vorschlägt und ihre Funktionen aufruft

1. Einleitung

Stellen Sie sich vor, Sie schreiben einen gewöhnlichen Web‑Service. Dort ist alles einfach: Sie haben die URL /search, der Nutzer klickt auf einen Button, Sie rufen den Controller searchController auf. In der Welt der ChatGPT-Apps sieht der Nutzer kein /search. Er schreibt einen ganz normalen Text:

„Finde ein Geschenk für meinen Gamer‑Bruder bis 50 $“

Und dann:

• entscheidet das Modell: „Oh, es geht um Geschenke, ich habe GiftGenius, der das kann“;
• GPT „drückt die Knöpfe“ selbst – es ruft die Tools Ihrer App auf;
• manchmal schlägt es dem Nutzer sogar vor: „Möchten Sie, dass ich GiftGenius öffne und Varianten zeige?“.

Der entscheidende Wandel: Der Nutzer äußert eine Absicht, und die Knöpfe drückt das Modell. Wenn man diesen Flow nicht versteht, ist es sehr leicht:

• Tools mit sinnlosen Namen zu schreiben (run_func, doStuff),
• eine App zu bekommen, die nie vom Modell vorgeschlagen wird oder unpassend aufgerufen wird,
• ein Widget zu bauen, das „aus dem Gebüsch springt“ und den Dialog zerstört.

Deshalb formen wir in dieser Vorlesung ein mentales Modell: wie GPT überhaupt von Ihrer App erfährt und an welchen Stellen des Dialogs es sie „einbettet“.

Insight: Die App ist ein Plugin für ChatGPT

Im Unterschied zu Apps auf dem Smartphone oder Mini-Apps in WeChat sind Apps in ChatGPT anders aufgebaut.

ChatGPT entscheidet selbst, wann es Ihre App startet und welche Funktion aufgerufen wird. Apps in ChatGPT können (wenn auch mit Einschränkungen) aktiv in die Chatlogik eingreifen. Ihr Hauptzweck und ihre Stärke sind – die Erweiterung der Fähigkeiten von ChatGPT selbst.

Wenn ChatGPT das Problem des Nutzers perfekt lösen kann – muss es Ihre App nicht aufrufen. Wenn ChatGPT das Problem des Nutzers überhaupt nicht lösen kann – wird der Nutzer auch nicht danach fragen. Ideal ist, wenn ChatGPT die Anfrage des Nutzers nur teilweise lösen kann. Das heißt: Es gibt entsprechende Anfragen, viele sogar, aber das Ergebnis reicht nicht aus.

Genau dann ruft ChatGPT Ihre App auf – und gemeinsam machen Sie den Nutzer glücklich. Der Nutzer wird glücklicher, und Sie – reicher.

2. Startarten der ChatGPT-App aus Nutzersicht

Der Nutzer hat keinen Button „starte den MCP‑Server und call_tool“, aber er hat ein Texteingabefeld und (manchmal) ein App-Menü. Aus seiner Sicht gibt es zwei grundlegende Startschemata: explizit und implizit.

Expliziter Start (explicit)

Das ist das Szenario, in dem der Nutzer Ihre App bewusst auswählt.

Typische Varianten:

• Er findet die App im ChatGPT-Store und klickt auf „Öffnen“;
• er wählt die App im Launcher (z. B. über den Button + im Composer – dem Texteingabefeld);
• er beginnt die Nachricht mit dem App-Namen: „GiftGenius, finde ein Geschenk …“ – das nennt man named mention. Steht der App-Name am Anfang des Prompts, mischt ChatGPT Ihre App automatisch in den Antwortkontext.

Im expliziten Modus weiß das Modell von Anfang an: Der Nutzer ist gekommen, um genau mit dieser App zu arbeiten. Daher:

• ruft GPT häufiger und aktiver Ihre Tools auf;
• das UI‑Widget Ihrer App kann bereits in der ersten Antwort erscheinen;
• GPT „ignoriert“ die App seltener und antwortet „aus eigener Kraft“.

Lieblingsbeispiel: Der Nutzer öffnet GiftGenius direkt, weil er „mit der Geschenksuche spielen“ will. Er klickt auf die App in der Liste, GPT zeigt eine Begrüßung im Stil:

„Hallo! Ich bin GiftGenius und helfe, ein Geschenk zu finden. Erzählen Sie mir, für wen wir suchen und welches Budget Sie haben.“

Und danach nutzt es aktiv Ihre Tools für die Suche.

Impliziter Start (implicit / suggested)

Ein völlig anderes Szenario: Der Nutzer denkt überhaupt nicht an eine App. Er schreibt einfach im normalen Chat:

„Finde ein Geschenk zum Geburtstag für meine Mutter, sie liebt Gartenarbeit, Budget bis 100 $“

GPT analysiert die Anfrage und sieht, dass:

• es in der Ökosphäre eine App GiftGenius gibt, deren Tools so beschrieben sind: „Use this when the user wants to get gift recommendations“;
• Aufgaben und Einschränkungen (Geschenk, Budget, Interessen) gut zu dieser App passen.

In so einem Fall kann das Modell „dezent dazwischengrätschen“ mit dem Vorschlag:

„Ich kann die App GiftGenius verwenden, um konkrete Geschenkoptionen auszuwählen und sie als Karten anzuzeigen. Soll ich sie öffnen?“

Wenn der Nutzer zustimmt – ruft GPT das passende App-Tool auf und rendert möglicherweise Ihr Widget.

Wichtig ist, dass Sie nirgends if (prompt.includes("Geschenk")) openApp() schreiben. Das Modell trifft die Entscheidung selbst und stützt sich auf:

• den Text der Anfrage und den Dialogverlauf;
• die Metadaten Ihrer Tools (Bezeichnungen, Beschreibungen, Parametrerschemata);
• den Verbindungsstatus des Nutzers zur App (ob er eingeloggt ist oder nicht), ob es ein Enterprise-Nutzer ist usw.

Sie beeinflussen nicht den Algorithmus, sondern wie Ihre App und Tools für das Modell „beschrieben“ sind.

Hybrid: wenn GPT erst nachfragt und dann die App vorschlägt

Manchmal schreibt der Nutzer etwas sehr Allgemeines:

„Ich muss mir etwas für einen Kollegen ausdenken, weiß aber überhaupt nicht was“

Das Modell versteht, dass GiftGenius helfen kann, aber die Informationen sind zu vage. Häufiges Muster:

1. GPT stellt 1–2 Rückfragen per Text.
2. Danach bietet es an, die App zu starten: „Ich habe ein Tool zur Geschenkauswahl. Soll ich es öffnen und Optionen zeigen?“.

Das ist gutes UX: Der Nutzer hat nicht das Gefühl, „zwangsweise in eine andere App versetzt“ worden zu sein.

3. Discovery: wie GPT Ihre App findet

Schauen wir uns nun an, wie das aus Sicht des Modells aussieht.

In der Apps-SDK-Dokumentation heißt das Discovery – alle Arten, wie Nutzer und Modell überhaupt von Ihrer App erfahren. Das sind natürliche Anfragen im Chat, der App-Katalog und spezielle „Entry Points“ wie der Launcher.

Woher weiß das Modell überhaupt, dass Ihre App existiert

Bei der Registrierung startet ChatGPT Ihre App, und diese beschreibt sich (über MCP) selbst: Sie listet verfügbare Tools mit ihren Schemata auf – Name, Beschreibung, JSON‑Schema der Eingabeparameter. Informationen über die App müssen bei der Registrierung angegeben werden, und Informationen über Tools holt sich ChatGPT selbst über die MCP‑Methode list_tools.

Das Modell sieht nicht Ihren Quellcode, ihm stehen nur zur Verfügung:

• der Tool-Name (name);
• die Beschreibung (description);
• die Signatur der Eingabe (inputSchema).

Genau das wird zum „API für das Modell“. Wenn Sie ein Tool run_func mit der Beschreibung „Executes the function“ nennen, versteht das Modell nicht, wann es das aufrufen soll. Nennen Sie es suggest_gifts mit der Beschreibung „Use this when the user wants gift ideas based on recipient, occasion and budget“ – wird alles klar.

Named mention und in‑conversation discovery

Die offizielle Apps-SDK-Spezifikation hebt zwei Schlüsselmechanismen hervor:

• Named mention – wenn der Nutzer die Nachricht mit dem Namen Ihrer App beginnt. In diesem Fall wird die App fast garantiert eingebunden und in der Antwort verwendet.
• In‑conversation discovery – wenn der Nutzer einfach eine Anfrage schreibt und das Modell entscheidet, ob die App angebunden werden sollte. Dabei werden berücksichtigt:
  • Kontext des Gesprächs (Verlauf, Ergebnisse vorheriger Tools, Nutzerpräferenzen);
  • explizite Markennennungen im Text;
  • Metadaten Ihrer Tools – Bezeichnungen, Beschreibungen, Parameterdokumentation;
  • der Verknüpfungsstatus – ob der Nutzer mit der App verbunden ist (eingeloggt, ob die nötigen Berechtigungen erteilt sind).

Der Entwickler beeinflusst diesen Prozess indirekt: durch gute Metadaten und UX‑Muster, nicht durch if/else im Code.

Katalog und Launcher

Neben dem dialogbasierten Weg gibt es noch den Store innerhalb von ChatGPT und den Launcher, erreichbar aus dem Composer. Über diese Wege können Nutzer Apps explizit auswählen – wie in einem normalen App‑Store.

Für uns ist das konzeptionell wichtig: Wenn wir den Flow von GiftGenius durchdenken, müssen wir bedenken, dass:

• manche über den Katalog kommen und sofort „in der“ App landen;
• manche nie durch den Katalog stöbern und die App nur als Vorschlag im Dialog sehen.

All das betrifft die Discovery der App selbst: die Momente, in denen das Modell entscheidet, ob es Ihre App überhaupt „hochziehen“ und dem Nutzer im aktuellen Gespräch vorschlagen soll.

4. Anatomie des Interaktionszyklus: von der Eingabe bis zum Widget

Zeit, die Ebenen aus der vorherigen Vorlesung – vom ChatGPT‑UI und Widget bis zum Apps SDK und MCP‑Server – in einen verständlichen logischen Zyklus zu fassen.

High‑Level‑Ablauf

Aus Prozesssicht sieht der Zyklus so aus:

sequenceDiagram
    participant U as Benutzer
    participant G as ChatGPT (Modell)
    participant A as App / MCP-Server

    U->>G: Textanfrage
    G->>G: Analyse der Anfrage + Tool-Auswahl
    G->>A: Werkzeugaufruf (call_tool)
    A-->>G: Antwort (Daten / structuredContent)
    G->>U: Textantwort + (optional) App-Widget

In einfachen Worten:

1. Der Nutzer schreibt eine Nachricht in ChatGPT.
2. Das Modell analysiert die Anfrage und den aktuellen Kontext, entscheidet:
   • ob es selbst antwortet,
   • oder eines oder mehrere Tools aufruft.
3. Ist ein Tool Ihrer App ausgewählt, formt ChatGPT eine strukturierte Anfrage (call_tool) und sendet sie an den MCP‑Server.
4. Ihr Backend (oder MCP‑Server) führt die Aktion aus: greift auf die Datenbank zu, ruft externe APIs, ACP usw. auf und formt das Ergebnis.
5. Das Ergebnis kommt als strukturierte Daten zurück (und ggf. JSON für das Widget).
6. Das Modell nutzt diese Daten, um:
   • einen für den Nutzer verständlichen Text zu generieren,
   • und bei Bedarf das App‑Widget direkt in der Antwort zu rendern.

Die gesamte mehrschrittige Planung – „wann was rufen“, „ob nachfragen“, „ob noch ein Aufruf nötig ist“ – liegt auf der Seite des KI‑Modells. Apps SDK und MCP stellen lediglich einen einheitlichen Vertrag für Tools bereit.

Wo schreiben wir hier Code

In diesem Zyklus gibt es drei Stellen, an denen Sie wirklich TypeScript/Code schreiben:

1. Konfiguration der App und der Tools – Toolbeschreibungen (Name, Beschreibung, Schema) und App‑Metadaten (Name, Icon, Kategorien). In Ihrem Projekt ist das vermutlich eine Datei wie openai/app-config.ts.
2. MCP‑Server / Backend – Verarbeitung von call_tool: auf die DB zugreifen, Produkte filtern, weitere APIs aufrufen usw.
3. Widget (UI) – React‑Komponente in einer Next.js‑App, die im Chat gerendert wird und die Tool‑Ergebnisse über window.openai oder Hooks des Apps SDK liest.

Alles andere ist Sache des Modells und der Plattform.

5. GiftGenius in Aktion: zwei Szenarien des User‑Flows

Gehen wir zu konkreteren Szenarien über, damit Sie diesen Flow „sehen“ können.

Szenario 1: Nutzer öffnet GiftGenius explizit

Szenario:

1. Der Nutzer öffnet in ChatGPT den App‑Katalog und findet GiftGenius.
2. Er klickt auf „Öffnen“.
3. ChatGPT startet den Dialog bereits im Kontext von GiftGenius.

Der Dialog sieht ungefähr so aus:

Nutzer:

Öffnet GiftGenius aus dem Katalog.
Und schreibt: „Hallo! Ich möchte ein Geschenk für einen Freund auswählen“

GPT:

„Super, ich helfe Ihnen, ein Geschenk zu finden. Für wen, mit welchem Budget und zu welchem Anlass suchen Sie ein Geschenk?“

An diesem Schritt kann GPT sofort das erste Tool aufrufen, zum Beispiel start_gift_session, um eine Sitzung in Ihrem Backend zu initialisieren (einen temporären Warenkorb anlegen, eine sessionId generieren etc.).

Ihr Code auf der MCP‑Server‑Seite kann so aussehen (stark vereinfacht):

// Pseudo-Beispiel Future-TS: Beschreibung des Tools GiftGenius
const suggestGiftsTool = {
  name: "suggest_gifts",
  description: "Use this when the user wants gift ideas by recipient, occasion and budget",
  inputSchema: {
    type: "object",
    properties: {
      recipient: { type: "string" },
      occasion: { type: "string" },
      budgetUsd: { type: "number" },
    },
    required: ["recipient", "occasion", "budgetUsd"],
  },
};
    

Wie das in MCP/Apps SDK registriert wird, besprechen wir im Detail in einem separaten Modul; jetzt ist die Idee wichtig: Anhand dieser Beschreibung versteht das Modell, dass das Tool für „Geschenkauswahl“-Anfragen geeignet ist.

Nach der Antwort des Nutzers ruft GPT suggest_gifts auf, erhält von Ihnen ein Array mit Optionen und anschließend:

• fasst es die Ergebnisse in Textform zusammen;
• bettet das GiftGenius-Widget ein, in dem man Geschenk-Karten durchblättern und filtern kann.

Szenario 2: Nutzer bittet im normalen Chat „finde ein Geschenk“

Nun die andere Variante: Der Nutzer kennt GiftGenius gar nicht.

Er schreibt im normalen Chat:

„Brauche ein Geschenk für meinen Bruder, er liebt Brettspiele, maximal 50 $“

Innerhalb von ChatGPT passiert ungefähr Folgendes:

1. Das Modell analysiert die Anfrage und die Liste der verfügbaren Tools.
2. Es sieht das Tool suggest_gifts mit einer passenden Beschreibung.
3. Es versteht, dass die App GiftGenius speziell für solche Aufgaben gedacht ist.
4. Es prüft, ob der Nutzer diese App bereits installiert hat, ob er eingeloggt war und welche Berechtigungen erteilt wurden.

Das weitere Verhalten kann unterschiedlich sein:

• ist die Anfrage ausreichend konkret, kann GPT stillschweigend suggest_gifts aufrufen und eine Antwort mit Widget zurückgeben;
• fehlt etwas (z. B. der Anlass oder das Alter), fragt GPT zuerst per Text nach und schlägt dann die App vor.

Diese Flexibilität unterscheidet Apps von „starren“ UIs mit Formularen: Das Modell entscheidet selbst, wann es Tools nutzt und wann es spricht.

6. Semantisches Routing: „LLM als Dispatcher“

Auf der Discovery-Ebene entscheidet das Modell, ob Ihre App überhaupt an die aktuelle Anfrage angeschlossen wird. Aber danach, wenn die App bereits „hochgezogen“ ist und ihre Tools dem Modell in der laufenden Sitzung bekannt sind, greift die zweite Ebene – das semantische Routing innerhalb dieser Tools: Mit welchem konkreten Tool die aktuelle Äußerung verarbeitet wird.

Im klassischen Web‑Backend wird per URL geroutet: /checkout – bedeutet, wir rufen den Checkout‑Controller. In ChatGPT‑Apps gibt es kein Routing per URL, dafür aber semantisches Routing: Das Modell vergleicht die Bedeutung der Anfrage mit den Beschreibungen Ihrer Tools.

Vereinfacht läuft es so:

1. Beim Start der Sitzung erhält ChatGPT die Liste der Tools: deren Namen, Beschreibungen, Schemata.
2. Diese Daten werden in die Systeminstruktionen des Modells eingebettet.
3. Wenn der Nutzer eine Anfrage schreibt, vergleicht das Modell die Bedeutung mit den Tool-Beschreibungen: wo „Geschenkauswahl“, wo „Hotelsuche“, wo „Diagramm erstellen“.
4. Findet es eine gute Übereinstimmung – formt es einen strukturierten Aufruf des passenden Tools.

Daraus folgt die wichtigste praktische Erkenntnis:

• Die Toolbeschreibung ist Ihr API für das Modell; lesen Sie diesen Satz noch einmal. Und dann noch einmal.
• Wenn Sie „does stuff“ schreiben, versteht das Modell tatsächlich nicht, wann es das Tool aufrufen soll.

Dokumentation und Best Practices zur Discovery betonen: Metadaten sind eine Aufgabe des Produkt‑Copywritings. Sie bestimmen, in welchen Gesprächen das Modell sich an Ihre App erinnert.

7. Dialogmuster rund um die App

Schauen wir uns typische UX‑Muster an, die entstehen, wenn GPT innerhalb eines Gesprächs mit der App interagiert. Das ist wichtig, damit Sie die App nicht „im Vakuum“ bauen – ohne die Rolle des GPT‑Teils zu verstehen.

Alle praktischen Guides zum Apps SDK heben einige charakteristische Muster hervor:

„Assistent“ (The Wizard)

GPT führt den Nutzer Schritt für Schritt – oft gestützt auf die App.

Am Beispiel GiftGenius:

1. GPT: „Erzählen Sie, für wen das Geschenk ist?“
2. Nutzer: „Bruder, 25 Jahre, liebt Brettspiele.“
3. GPT: „Welches Budget?“
4. Nutzer: „Bis 50 $.“
5. GPT ruft suggest_gifts auf, zeigt die Ergebnisse im Widget und schreibt: „Ich habe einige Optionen ausgewählt, schauen Sie sich die Liste unten an.“

In diesem Muster sind die App und ihr Widget wie eine visuelle Ebene über dem mehrstufigen Dialog. Der Nutzer schreibt die meiste Zeit Text, und das Widget hilft, die Auswahl zu visualisieren.

„Adaptives Widget“ (The Adaptive Widget)

Text bleibt der Hauptkanal, und die App wird gezielt für Spezialaufgaben zugeschaltet: ein Diagramm zeichnen, eine Tabelle zeigen, Produktkarten rendern.

Beispiel:

• Nutzer: „Vergleiche drei Geschenkoptionen: Brettspiel, Buch, Erlebnisgeschenk.“
• GPT erklärt zunächst in Textform Vor- und Nachteile.
• Dann ruft es ein Tool auf, das eine strukturierte Produktliste zurückgibt, und rendert eine kleine Tabelle oder Karten.

Hier ist die App eine visuelle Ergänzung – nicht der „Standardmodus“.

„Unsichtbarer Agent“ (Invisible Agent)

Die App muss überhaupt kein UI zeigen. Sie arbeitet „unter der Haube“ als Datenquelle:

• Sie implementieren ein MCP‑Tool, das Geschenke in Ihrer DB sucht;
• GPT ruft es auf, erhält die Liste und erzählt die Ergebnisse dann selbst in Textform nach – ohne ein Widget.

Das ähnelt einem klassischen „Plugin ohne UI“: Der Nutzer sieht nur, dass GPT aktuelle Preise und Sortiment kennt.

Ein solches Muster ist nützlich für Tool‑first‑Apps, bei denen UI nicht kritisch ist.

8. Wie der Flow das App‑Design beeinflusst

Das Flow‑Verständnis ist nicht nur Philosophie, sondern führt zu sehr praktischen Entscheidungen: welche Tools man anlegt, wie man sie beschreibt, wann man ein Widget zeigt und wann man besser in Text antwortet.

Prinzip „Chat‑first“

Die Schlüsselidee des Ökosystems: Der Chat ist der Hauptinteraktionskanal, UI‑Komponenten sind unterstützend.

Das bedeutet:

• man muss nicht versuchen, „die ganze Website“ in ein Widget zu quetschen;
• Widgets sollten dort helfen, wo Chat unpraktisch ist: Auswahl aus Listen, Filterung, Vergleich, komplexe Formulare.

Für GiftGenius heißt das:

• eine Geschenkliste zusammenstellen und dem Nutzer erlauben, durch Karten zu klicken;
• Filter visualisieren (Preis, Kategorie, Verfügbarkeit);
• beim Bestellvorgang (Checkout) in einigen klaren Schritten helfen.

Lange Erklärungen wie „wie man ein Geschenk für eine introvertierte Freundin auswählt“ ins Widget zu schreiben, ist keine gute Idee – das ist Aufgabe des Chats.

Wann die App starten – und wann nicht

Eine weitere Konsequenz: Machen Sie Ihre App nicht zum „Dialog‑Eroberer“.

Schlechtes Muster:

• der Nutzer führt eine ernsthafte Diskussion;
• die App startet und öffnet ohne Vorwarnung ein riesiges Fullscreen‑Widget;
• der Nutzer ist verwirrt: „Wo ist mein Chat geblieben?“.

Besser:

• zuerst alles im Text besprechen, ein paar Rückfragen stellen;
• dann behutsam vorschlagen, die App zu öffnen, wenn das UX wirklich verbessert (Vergleich, Konfiguration, Checkout).

Auswirkung auf den Werkzeugsatz

Da das Modell das Tool über die Beschreibung auswählt, sollte jedes Tool:

• eine klar erkennbare Aufgabe lösen;
• gut im Stil „Use this when …“ beschrieben sein;
• Parameter haben, die sich natürlich aus den Fragen ergeben, die GPT dem Nutzer stellen wird.

Für GiftGenius ist es sinnvoller, statt eines riesigen do_everything zu haben:

• suggest_gifts – die Liste von Optionen zusammenstellen;
• get_gift_details – Details zu einer konkreten ID;
• create_order – die Bestellung anlegen.

Wir beschäftigen uns ausführlicher mit dem Tool‑Design in Modul 4, aber die Grundidee ist schon jetzt wichtig: Der Dialog‑Flow bestimmt, welche Tools überhaupt nötig sind.

9. Mini‑Beispiel: wie Tool‑Beschreibungen den Flow beeinflussen (TypeScript‑Skizze)

Ein kleiner Ausschnitt einer hypothetischen openai/app-config.ts, um Theorie mit Code zu verbinden. Verstehen Sie das nicht als exakte SDK‑Syntax (die klären wir im nächsten Modul) – jetzt zählen Namen und Beschreibungen.

// Bedingter Konfigurationsausschnitt von GiftGenius (zukünftiger Code)
const tools = [
  {
    name: "suggest_gifts",
    description: "Use this when the user wants gift ideas based on recipient, occasion, and budget.",
    inputSchema: {/* ... */},
  },
  {
    name: "get_gift_details",
    description: "Use this when the user asks for more information about a specific gift from a previous list.",
    inputSchema: {/* ... */},
  },
];

Wenn Sie suggest_gifts durch run_func ersetzen und die Beschreibung durch „Main function“, dann:

• versteht GPT schlechter, für welche Anfragen dieses Tool gedacht ist;
• wird Ihre App im In‑Conversation‑Discovery seltener vorgeschlagen;
• wird es schwieriger, Follow‑ups des Nutzers mit der bereits gezeigten Geschenkliste zu verknüpfen.

Umgekehrt erhöhen gute Namen und Beschreibungen die Chance, dass genau Ihre App im richtigen Moment auftaucht.

10. Typische Fehler beim Design des User‑Flows

Fehler Nr. 1: Erwartung vollständiger Kontrolle – „ich entscheide selbst, wann ich die App starte“.
Manche Entwickler denken in der Paradigma „ich fange alle Anfragen zu Geschenken ab und binde meine App an“. In der Welt der ChatGPT‑Apps ist das nicht so: Entscheidungen trifft das Modell. Es berücksichtigt Tool‑Beschreibungen, Dialogkontext, Berechtigungsstatus und wie zufrieden der Nutzer mit dem Aufruf genau Ihrer App ist.

Fehler Nr. 2: Sinnlose Tool‑Namen und ‑Beschreibungen.
Tools mit Namen wie run, main, tool1 und Beschreibungen wie „Calls the main function“ erzeugen den perfekten Sturm: Das Modell versteht nicht, wann es sie aufrufen soll, In‑Conversation‑Discovery funktioniert praktisch nicht, und Ihre App wird „unsichtbar“. Eine gute Beschreibung im Stil „Use this when the user wants …“ und ein verständlicher Name sind viel wichtiger, als es zunächst scheint.

Fehler Nr. 3: Der Versuch, in eine App „alles auf der Welt“ zu stopfen.
Wenn Ihre App gleichzeitig „Geschenke auswählt, Hotels bucht, Steuern berechnet und Katzen zeigt“, kann das Modell Anfragen nicht zuverlässig routen. Offizielle Empfehlungen und Praxisguides betonen das Prinzip „one clear job per tool/app“: besser mehrere spezialisierte Apps als ein Mega‑Monolith.

Fehler Nr. 4: Aggressiver Autostart eines schweren UIs.
Der Entwickler ist stolz auf sein schönes Fullscreen‑Widget und möchte es „bei jeder Gelegenheit“ zeigen. Das Ergebnis: Der Nutzer hat das Gefühl, dass der Chat „kaputtgeht“ und sich in eine seltsame Web‑App verwandelt. Viel besser ist es, wenn GPT zuerst im Text kommuniziert, Rückfragen stellt und erst danach anbietet, die App zu öffnen – mit Erklärung, warum das sinnvoll ist.

Fehler Nr. 5: Die Rolle von GPT als UX‑Schicht ignorieren.
Man kann eine App wie ein gewöhnliches SPA entwerfen: alles ins Widget packen, und ChatGPT soll „schweigen und nicht stören“. Das wird aber nicht funktionieren. ChatGPT könnte Ihr Widget nicht anzeigen – oder bei jedem Tool‑Aufruf ein neues Widget rendern. Wollen Sie ein erfolgreiches Produkt, passen Sie sich der Plattform an – erwarten Sie nicht, dass sie sich Ihnen anpasst.