Lokalisierung von Tools und description: Auswirkungen auf GPT und Verhaltensexperimente

1. Wie das Modell Ihre Tools „sieht“

Beginnen wir damit, dass ein Tool für das Modell keineswegs „Ihre hübsche TypeScript‑Funktion“ ist, sondern eine strukturierte Beschreibung im Stil von:

• name: technischer Name, zum Beispiel "search_gifts";
• description: Text in natürlicher Sprache, der erklärt, wann und wozu dieses Tool zu verwenden ist;
• inputSchema: JSON Schema mit Feldern, von denen jedes ebenfalls ein description, einen Typ und Einschränkungen haben kann.

Sehr vereinfacht macht das Modell ungefähr Folgendes (Pseudocode im Kopf von GPT):

1. Benutzeranfrage lesen (in beliebiger Sprache).
2. Liste der Tools lesen: name + description + Argumentbeschreibungen.
3. Für jedes Tool einschätzen, ob es zur Aufgabe passt.
4. Falls ein Tool nötig ist — JSON mit Argumenten gemäß Schema erzeugen.
5. Andernfalls — als Text antworten.

Hieraus ergeben sich zwei wichtige Schlussfolgerungen.

Erstens ist das Feld description eines Tools kein Kommentar für Entwickler, sondern die Schnittstelle zwischen dem Modell und Ihrem Backend. Wenn die Toolbeschreibung vage, unvollständig oder in einer Sprache ist, die nicht mit der des Nutzers übereinstimmt, verfehlt das Modell häufiger: falsches Tool, falsche Argumente, Textantwort statt Tool‑Aufruf, obwohl ein Tool nötig gewesen wäre.

Zweitens ist die description der Felder in JSON Schema genauso wichtig wie die Beschreibung des Instruments selbst. Das Modell liest die description jedes Properties wirklich und entscheidet danach, in welches Feld es „Alter“, in welches „Budget“ gehört und wo überhaupt eine id sein muss.

Mini‑Beispiel für GiftGenius

Nehmen wir unser Tool search_gifts. In der ursprünglichen, „nur EN“‑Version könnte es so aussehen:

// server/tools/searchGifts.ts
export const searchGiftsTool = {
  name: "search_gifts",
  description: "Search for gift ideas based on user preferences.",
  inputSchema: {
    type: "object",
    properties: {
      recipient_age: {
        type: "integer",
        description: "Age of the recipient in years.",
      },
      budget: {
        type: "number",
        description: "Maximum budget in user's currency.",
      },
    },
    required: ["budget"],
  },
};

Wenn der Nutzer schreibt: „Ich brauche ein Geschenk für meine Mutter, sie ist 60, Budget bis 3000 Rubel“, sollte das Modell:

1. verstehen, dass search_gifts das passende Tool ist,
2. verstehen, dass „60 Jahre“ in recipient_age gehört und „3000 Rubel“ in budget.

Solange die Beschreibungen nur auf Englisch sind, kommt GPT trotzdem zurecht, aber das erfordert bereits eine zusätzliche interne „Übersetzung“. Bei mehreren Sprachen und schwächeren Modellen leidet die Genauigkeit.

2. Das Problem „englischer Beschreibungen“ in einer mehrsprachigen App

In Modul 9 haben wir die allgemeine „Lokalisierungskarte“ kurz angerissen: UI‑Widget, Kataloge, Fehler, Commerce‑Texte. Jetzt fokussieren wir und schauen, was passiert, wenn Toolbeschreibungen nur auf Englisch verfasst sind, der Nutzer aber z. B. auf Russisch oder Spanisch kommuniziert — dann beginnt die leichte Unordnung.

Typisches Szenario:

1. Nutzer: „Finde ein Geschenk für einen IT‑Freund, Budget bis 50 Euro.“
2. Das Modell schaut auf die Liste der Tools und sieht Beschreibungen nur auf EN.
3. Wenn die Anfrage auch auf EN ist — alles gut.
4. Wenn die Anfrage in einer anderen Sprache ist, muss es:
   • die Anfrage zuerst verstehen,
   • sie gedanklich mit den englischen Beschreibungen abgleichen,
   • ein Tool auswählen,
   • und anschließend noch die Argumente in JSON extrahieren.

Bei starken Modellen geht das halbwegs, aber:

• häufig steigt der Anteil von Antworten ohne Tool‑Aufruf — das Modell „denkt“, es schafft es allein;
• die Fehlerquote in den Argumenten ist höher (insbesondere bei Währung, Maßeinheiten und regionalen Einschränkungen);
• die Routing‑Logik zwischen mehreren Tools wird unzuverlässiger (Tool „am Thema vorbei“).

Ein einfaches Fehlerbeispiel: Im Feld budget wird „in der Währung des Nutzers“ erwartet, die Beschreibung erwähnt das aber gar nicht. Das Modell entscheidet, dass USD der Default ist, und sendet an das Backend 50 Dollar, obwohl der Nutzer eindeutig 50 Euro meinte.

Hier kommt die Lokalisierung der Beschreibungen ins Spiel.

3. Ansätze zur Lokalisierung: separate Tools vs. mehrsprachige Beschreibungen

Es gibt zwei grundlegende Architekturansätze, und beide haben ihre Berechtigung.

Separate Tools für jede Sprache

In dieser Variante erstellen Sie mehrere Tools mit unterschiedlichen Namen, jedes mit „seiner“ Beschreibungssprache.

Für GiftGenius kann das so aussehen:

export const searchGiftsEn = {
  name: "search_gifts_en",
  description: "Search for gift ideas based on user preferences.",
  // ...
};

export const searchGiftsRu = {
  name: "search_gifts_ru",
  description: "Auswahl von Geschenken entsprechend den Vorlieben des Nutzers.",
  // ...
};

Für die ChatGPT App ist dabei wichtig, dass die Liste der verfügbaren Tools von der locale abhängt. Wenn locale = "ru-RU" ist, sollte Ihr MCP‑Server nur search_gifts_ru zurückgeben. Wenn locale = "en-US" ist — nur search_gifts_en.

Vorteile dieses Ansatzes: Beschreibungen sind maximal „sauber“ und einsprachig. Sie können die App sogar als mehrere einsprachige Versionen denken, jede mit eigenen Prompts und Beschreibungen. Das ist angenehm, wenn es wenige Sprachen gibt und sich die Märkte stark unterscheiden.

Nachteile — Logik‑Duplizierung und Analytics‑Komplexität. Im Backend‑Code gibt es wahrscheinlich ohnehin denselben Handler, aber auf MCP/Manifest‑Ebene sind es zwei verschiedene Tools. Man darf nicht vergessen, beide Beschreibungen bei jeder Änderung zu aktualisieren.

Insight (Datenstand: 2025-12-01)

Experimentell wurden keine signifikanten Vorteile für description in der Sprache des Nutzers/locale festgestellt. Die Tools wurden nahezu mit gleicher Frequenz ausgewählt, unabhängig von der Beschreibungssprache. Wenn es 2 Tools mit ähnlichen Beschreibungen (in unterschiedlichen Sprachen) gab, verwirrte das ChatGPT.

Außerdem muss Ihre App das Review bei der Registrierung im Store bestehen. Daher empfehle ich, einfach alle Tool‑Beschreibungen und Argumentbeschreibungen auf Englisch zu schreiben.

Sollten es in Zukunft Tausende Apps für ChatGPT geben und der Wettbewerb um die „Tool‑Auswahl“ zunehmen, könnte die Beschreibung in der Nutzer‑Locale einen Vorteil erhalten. Wir warten auf Tool Search Optimization.

Ein Tool mit mehrsprachigen Beschreibungen

Im zweiten Ansatz behalten Sie einen name (zum Beispiel search_gifts), machen aber dessen description und die Feldbeschreibungen der JSON Schema mehrsprachig.

Es gibt verschiedene Stile:

1. Kurze zweisprachige Form:

   description: "Search gifts for a recipient. / Geschenke anhand der Vorlieben des Empfängers finden.",

2. Markierte Blöcke pro Sprache:

   description: "[EN] Search for gifts based on user preferences. [DE] Auswahl von Geschenken nach den Vorlieben des Empfängers.",

3. Separate Felder, zu einem String zusammengeführt (weniger bequem):

   description: `EN: ${enDescription} RU: ${ruDescription}`,

Vorteile — ein Tool, Single Source of Truth, einfacher, eine Architektur mit MCP Gateway auszurollen: Sie exponieren immer dieselbe Schnittstelle für ChatGPT, unabhängig davon, in welcher Sprache der Nutzer schreibt.

Nachteile: Beschreibungen werden länger. Wenn man Sprachen unachtsam „mischt“, kann das Modell etwas verwirrt sein — insbesondere wenn Englisch und lokale Texte ohne klare Kennzeichnungen [EN], [RU] durcheinanderstehen.

Für ein Lernprojekt wie GiftGenius empfehlen wir eine hybride Variante: Beschreibungen hauptsächlich auf Englisch, aber mit einer kurzen lokalen Erläuterung; und die eigentliche „Semantik“ (welche Sprache zu verwenden ist, wie der Nutzer anzusprechen ist) leiten Sie über Argumente (locale) und den System‑Prompt.

4. Lokalisierung von JSON Schema: Feldbeschreibungen

Jetzt gehen wir tiefer: zu den Argumenten des Tools selbst.

In JSON Schema kann (und sollte) jedes Feld eine description haben. Diese Zeichenkette liest das Modell, wenn es JSON für den Tool‑Aufruf generiert.

Für GiftGenius könnte es so aussehen:

export const searchGiftsTool = {
  name: "search_gifts",
  description:
    "Search gifts based on user preferences (DE: Auswahl von Geschenken nach den Vorlieben des Empfängers).",
  inputSchema: {
    type: "object",
    properties: {
      recipient_age: {
        type: "integer",
        description:
          "Recipient age in years. DE: Alter des Empfängers in Jahren (Ganzzahl).",
      },
      budget: {
        type: "number",
        description:
          "Maximum budget in user's currency. DE: Maximalbudget in der Währung des Nutzers.",
      },
      locale: {
        type: "string",
        description:
          "User locale (e.g. 'en-US', 'ru-RU'). DE: Sprache der Oberfläche und der Antworten.",
      },
    },
    required: ["budget", "locale"],
  },
};

Einige praktische Beobachtungen.

Erstens bleiben Feldnamen (recipient_age, budget, locale) in der Regel auf Englisch. Übersetzt wird die description. Das ist wichtig, damit sich das JSON‑Format nicht je nach Sprache ändert und Sie nicht zwei unterschiedliche Verträge pflegen müssen.

Zweitens ist es in der description hilfreich, Währung, Maßeinheiten und wichtige Einschränkungen explizit anzugeben. Das senkt die Zahl „schiefer“ Argumente deutlich.

Drittens: Wenn Sie bereits MCP Gateway verwenden, können Sie vereinbaren, dass es die locale automatisch in die Tool‑Argumente durchreicht, sodass das Modell sie nicht selbst setzen muss. Selbst dann ist die Beschreibung von locale nützlich: Das Modell versteht besser, was dieser Parameter ist und wozu er dient.

5. Welche Sprache für Beschreibungen wählen: Strategien für eine reale App

Die praktische Kernfrage: Welche Sprache soll für Beschreibungen die primäre sein, und wann lohnt sich eine vollständige Lokalisierung?

Empfehlungen und Erfahrung zeigen, dass GPT‑Modelle weiterhin am besten im englischen Kontext arbeiten, und viele Entwickler lassen Beschreibungen ausschließlich auf EN. Für eine mehrsprachige App kann das aber ein Kompromiss sein.

Betrachten wir einige Strategien.

Nur EN‑Beschreibungen

Die einfachste Variante — alles auf Englisch.

Vorteile: eine Codebasis, eine Sprache für die Pflege, einfacher präzise Formulierungen zu schreiben. Das Modell ist glücklich, wenn alles um es herum Englisch ist.

Nachteile: Für Nutzer, die in anderen Sprachen schreiben, kann die Qualität bei Tool‑Auswahl und Argumenten niedriger sein — besonders bei „bequemen“ Modellen oder komplexen Tools mit vielen Parametern.

EN + kurzer lokaler Anhang

Ein Kompromiss: Hauptbeschreibung auf EN, am Ende ein kurzer Block in der lokalen Sprache, der dem Modell hilft, Nutzerwörter den Argumenten zuzuordnen.

Beispiel:

description:
  "Search for gifts based on user preferences. DE: Das Tool wählt Geschenke anhand der Beschreibung des Empfängers, seines Alters und Budgets aus.",

Für JSON Schema:

description:
  "Age of the recipient in years. DE: Alter des Empfängers (in Jahren).",

Vorteile: Das Modell bleibt in der „englischen“ Welt, hat aber einen Hinweis in der Nutzersprache.

Nachteile: Die Beschreibungen werden länger, was in der Regel unkritisch ist.

Vollständige Lokalisierung der Beschreibungen nach Locale

Der anspruchsvollste Ansatz: Tool‑ und Feldbeschreibungen variieren je nach locale, die Sie von ChatGPT kennen. Für en-US liefern Sie rein englische Beschreibungen, für ru-RU — rein russische, und für de-DE — deutsche.

Das ist nicht mehr „eine JSON Schema für immer“, sondern ein Satz von Schemata, die MCP/Gateway zur Laufzeit auswählt.

Auf MCP‑Ebene sieht das so aus:

function getSearchGiftsToolDescription(locale: string) {
  if (locale.startsWith("ru")) {
    return {
      name: "search_gifts",
      description: "Auswahl von Geschenken nach den Vorlieben des Empfängers.",
      // ru‑schema...
    };
  }
  return {
    name: "search_gifts",
    description: "Search for gifts based on user preferences.",
    // en‑schema...
  };
}

Vorteile: Das Modell sieht die Schnittstelle in derselben Sprache, in der der Nutzer schreibt. Maximale Bequemlichkeit.

Nachteile: Pflege und Tests werden aufwendiger. Sie brauchen einen Prozess, der sicherstellt, dass alle lokalisierten Beschreibungen inhaltlich synchron bleiben und Sie z. B. das deutsche Schema beim Hinzufügen eines neuen Feldes im englischen Schema nicht vergessen zu aktualisieren.

6. Umsetzung in unserer GiftGenius‑App

Kommen wir zur konkreten Umsetzung. Wir machen für GiftGenius die Hybrid‑Variante: ein Tool search_gifts, Beschreibungen überwiegend auf EN, aber mit kurzen deutschen Erläuterungen sowie dem Argument locale.

Angenommen, Sie haben einen MCP‑Server in TypeScript, der Tools im Stil des MCP SDK beschreibt.

// mcp/tools/searchGifts.ts
import { z } from "zod";

export const searchGiftsInputSchema = z.object({
  recipient_age: z
    .number()
    .int()
    .describe(
      "Age of the recipient in years. DE: Alter des Empfängers (Ganzzahl)."
    ),
  budget: z
    .number()
    .describe(
      "Maximum budget in user's currency. DE: Maximalbudget in der Währung des Nutzers."
    ),
  locale: z
    .string()
    .describe(
      "User locale (e.g. 'en-US', 'ru-RU'). DE: Sprache der Oberfläche und Antworten."
    ),
});

export const searchGiftsTool = {
  name: "search_gifts",
  description:
    "Search for gifts based on user preferences (DE: Auswahl von Geschenken nach den Vorlieben des Empfängers).",
  inputSchema: searchGiftsInputSchema,
  // execute(...) ...
};

Wichtig:

• locale ist obligatorisch. Wenn das Widget sie kennt (was wir aus _meta["openai/locale"] wissen), setzt es sie entweder selbst im Aufruf von callTool oder der MCP Gateway macht das automatisch auf seiner Seite;
• die Beschreibungen enthalten bereits deutsche Schlüsselwörter „Alter“, „Budget“, „Sprache der Oberfläche“, wodurch das Modell leichter versteht, was aus der Nutzeranfrage wohin gehört.

Auf der Seite des Apps SDK können Sie zum Beispiel eine Funktion haben, die dieses Tool direkt aufruft (wenn widgetAccessible aktiviert ist) und die Locale aus dem Widget übergibt.

// widget/hooks/useSearchGifts.ts
export async function searchGiftsFromWidget(params: {
  recipientAge: number;
  budget: number;
  locale: string;
}) {
  const openai = (window as any).openai;
  const result = await openai.callTool("search_gifts", {
    recipient_age: params.recipientAge,
    budget: params.budget,
    locale: params.locale,
  });
  return result;
}

Diese Kette stützt die Architektur: Locale kommt aus ChatGPT → landet im Tool → dieses wählt den richtigen Katalog und die Preisformate, die Sie dann im Frontend schön rendern.

7. Verhaltensexperimente: den Einfluss der Lokalisierung messen

Nun zum Spannendsten: Wie erkennen Sie, dass die Lokalisierung von Tools und Beschreibungen das Modellverhalten tatsächlich verbessert und die Übersetzungsarbeit gerechtfertigt ist?

Man kann ein kleines „wissenschaftliches Experiment“ direkt im Dev Mode von GiftGenius durchführen.

Zwei App‑Varianten: base vs. localized

Bereiten Sie zwei Konfigurationen Ihrer App vor:

• base — Tool‑ und JSON‑Schema‑Beschreibungen nur auf EN;
• localized — Beschreibungen mit EN+DE (oder vollständige DE‑Versionen, falls möglich).

Den Rest (Kataloge, UI, Prompts) lassen Sie identisch, um Effekte nicht zu vermischen.

Zur Vereinfachung können Sie:

• im Dev Mode (und erst recht im Store) nur die localized‑Version halten;
• base lokal in einem separaten Branch starten und Ergebnisse an einem vordefinierten Satz von Anfragen vergleichen.

Was messen

Es gibt drei Schlüsselmetriken.

Erstens — Häufigkeit korrekter Tool‑Wahlen. Für einen Satz von Testanfragen auf Deutsch (und/oder einer anderen Sprache) prüfen Sie, wie oft das Modell:

• überhaupt ein Tool aufruft, wenn es nötig ist;
• genau search_gifts wählt und kein anderes Tool.

Zweitens — Korrektheit der Argumente. Prüfen Sie, wie oft das Aufruf‑JSON den Erwartungen entspricht: Felder nicht verwechselt, Budget in der richtigen Währung, Alter explizit Ganzzahl, Locale nicht verloren.

Drittens — Anzahl seltsamer oder sinnloser Aufrufe. Zum Beispiel ruft das Modell search_gifts für die Frage „Wie spät ist es gerade?“ oder setzt recipient_age auf 3000 statt beim Budget.

Testen lässt sich sowohl manuell als auch über MCP/Agents‑Logs — die Logs werden Ihnen ohnehin später nützlich sein, daher lohnt es sich, sich an solche Analysen bereits jetzt zu gewöhnen.

Wie man einen manuellen Testsatz organisiert

Sie können einen kleinen „goldenen Prompt‑Satz“ für die Lokalisierung anlegen:

1. "Ich brauche ein günstiges Geschenk bis 30 Euro für ein 10-jähriges Mädchen, sie malt gern."
2. "Finde ein Geschenk für einen Kollegen (Programmierer), 35 Jahre, Budget 100$."
3. "Ein Geschenk für Oma zum Jubiläum, 70 Jahre, Budget bis 5000 Rubel."

Und jagen Sie diese durch beide App‑Versionen (base und localized) und beobachten:

• welche Tools das Modell auswählt;
• welche Argumente es einsetzt;
• wie sich der Text der Antwort ändert, wenn kein Tool aufgerufen wurde.

Ein halbprofessioneller Lifehack: Sie können ein kleines Skript bauen, das diese Anfragen über die ChatGPT API laufen lässt; im Kurs reicht jedoch der manuelle Modus im Dev Mode. Eine besonders nützliche Kategorie für diesen Satz sind Nachrichten mit gemischten Sprachen und „schrägen“ locale‑Kombinationen. Dazu gleich mehr.

Wenn Sie eine ernsthafte kommerzielle Anwendung entwickeln und es um Millionen Dollar geht, testen Sie diese Punkte unbedingt genau für Ihre App. Modul 20 ist der professionellen Arbeit mit einem „goldenen Prompt‑Satz“ gewidmet — machen Sie sich damit unbedingt vertraut.

8. Gemischte Sprachen und ungewöhnliche Locale‑Kombinationen

Nichts amüsiert LLM‑Entwickler so sehr wie ein Nutzer, der in zwei Sprachen gleichzeitig schreibt. Zum Beispiel:

"Brauche ein Geschenk for my friend, er mag Star Wars, budget 100€"

Wir wissen bereits, dass das Modell multilingual ist und meist zurechtkommt. Aber bei gemischten Sprachen und „englischen“ Beschreibungen steigt die Fehlerwahrscheinlichkeit.

Es gibt einige typische Situationen.

Erstens — der Nutzer schreibt auf DE, die Toolbeschreibungen sind auf EN. Das Modell kann das verstehen, kommt aber manchmal durcheinander, besonders bei spezifischer Terminologie (Kategorienamen, seltene Feldlabels).

Zweitens — locale = "ru-RU", aber der Nutzer schreibt aus irgendeinem Grund auf Englisch. ChatGPT hat Ihnen Signale gesendet, dass die Oberfläche besser auf Russisch sein sollte, die tatsächliche Textsprache ist aber EN. Man kann:

• trotzdem russische Beschreibungen liefern und locale als primäre Wahrheit werten;
• oder eine Spracherkennung der Nachricht als zusätzliches Signal implementieren und Beschreibungen an die tatsächliche Sprache anpassen.

Drittens — locale = "en", und der Nutzer mischt gelegentlich deutsche Wörter hinein. In diesem Fall fühlen sich englische Beschreibungen in der Regel bestens.

In der Praxis reicht es, eine klare Policy zu wählen. Zum Beispiel:

• wenn locale mit "ru" beginnt — fügen Sie russische Teile in die Beschreibungen ein;
• wenn nicht — bleiben die Beschreibungen rein englisch.

Eine klare Regel hilft vor allem, jede Verzweigung gezielt zu testen, statt zu rätseln, warum heute Beschreibungen in dieser oder jener Sprache erschienen sind.

9. Dokumentation, Prozess und „kanonische“ Sprache

Lokalisierung von Beschreibungen ist kein einmaliger Akt, sondern ein Prozess. Nutzer mögen neue Features, und Sie mögen, wenn nichts Altes kaputtgeht. Legen Sie daher im Voraus fest:

• w welche Sprache als „kanonisch“ gilt und als Referenz für alle Übersetzungen dient;
• wo die lokalisierten Beschreibungen gespeichert werden;
• wie Konsistenz geprüft wird.

Meist ist Englisch die kanonische Sprache. Alle neuen Tools und Felder werden zuerst auf EN beschrieben, durchlaufen ein Review und werden erst dann in andere Sprachen lokalisiert. In der Codebasis kann man das so ausdrücken:

• Datei tools.en.json mit vollständiger Beschreibung von name/description/Feldern;
• Dateien tools.ru.json, tools.de.json als „Derivate“ für konkrete Sprachen;
• ein kleiner Generator, der die finalen JSON Schemas für MCP aus diesen Wörterbüchern zusammenstellt.

In einer einfachen Variante können Sie vorerst bei Strings im Code bleiben, diese aber so strukturieren, dass sie später leicht in separate Wörterbücher ausgelagert werden können.

Wichtig: Beschreibungen sind ebenfalls Produkttexte. Sie sollten genauso streng reviewed werden wie UI‑Texte: auf Verständlichkeit, Eindeutigkeit und ohne „Füllwörter“. Besonders in der mehrsprachigen Variante wollen wir nicht, dass der deutsche Anhang der englischen Hauptbeschreibung widerspricht.

10. Visualisierung: wie Sprache den Stack durchläuft

Um alles zusammenzuführen, betrachten wir ein vereinfachtes Ablaufdiagramm einer Anfrage unter Berücksichtigung der Tool‑Lokalisierung.

flowchart TD
    U[Benutzer schreibt auf DE] --> C[ChatGPT UI]
    C -->|"_meta.openai/locale = 'ru-RU'"| W[GiftGenius-Widget]
    W -->|"locale = 'ru-RU'"| T["Tool descriptions (EN+DE)"]
    T --> M[GPT-Modell]
    M -->|callTool search_gifts| MCP[MCP / Gateway]
    MCP -->|"locale = 'ru-RU'"| B[Backend / Kataloge DE]
    B --> MCP --> M2["GPT-Modell (Antwort)"]
    M2 --> C2[ChatGPT UI + Widget DE]

Hier bestimmen die Nutzersprache und die locale:

• in welcher Sprache das Widget das UI anzeigt;
• welche Tool‑ und Feldbeschreibungen das Modell sieht;
• welche Kataloge und Währungen das Backend wählt;
• wie Antworten formatiert werden (vom Modell und vom Widget).

11. Typische Fehler bei der Lokalisierung von Tools und Beschreibungen

Fehler Nr. 1: Das Feld description als „technisch“ ansehen und gar nicht lokalisieren.
Das funktioniert, solange Sie nur englischsprachige Nutzer haben. Sobald andere Sprachen auftauchen, antwortet das Modell häufiger ohne Tools oder übergibt krumme Argumente gemäß Schemata. Sie haben das UI zwar übersetzt, aber die App verhält sich „englisch“.

Fehler Nr. 2: Feldnamen im JSON je nach Sprache ändern.
Manchmal lockt die Idee, age → vozrast, budjet usw. zu machen. Das führt zum Backend‑Albtraum: verschiedene Schemata, verschiedene Formate, komplizierte Log‑Analyse. Lassen Sie die Feld‑names stabil und lokalisieren Sie nur die Beschreibungen.

Fehler Nr. 3: Sprachen chaotisch in Beschreibungen mischen.
Sätze wie „Suche gifts nach den Vorlieben des user“ helfen weder dem Modell noch Menschen. Wenn Sie mehrsprachige Beschreibungen machen, trennen Sie die Blöcke deutlich: [EN] ... [RU] .... Dann sieht das Modell Struktur statt Brei.

Fehler Nr. 4: locale nicht an Tools übergeben.
Selbst wenn Sie Beschreibungen lokalisiert haben, aber locale nicht an das Tool übergeben (oder der MCP Gateway sie nicht durchreicht), weiß das Backend nicht, welche Kataloge und Formate zu verwenden sind. Am Ende versucht das Modell „mehrsprachig“ zu sein, während der Server nur Daten für einen Markt liefert.

Fehler Nr. 5: Autotranslation der Beschreibungen ohne Review.
Es scheint, man könne Beschreibungen einfach durch einen maschinellen Übersetzer jagen und glücklich sein. In der Praxis sind solche Übersetzungen oft ungenau, besonders bei Begriffen und Argumenten. In der Folge kann das Modell die Bedeutung eines Tools oder Feldes falsch interpretieren. Besser ein gut durchdachter EN‑Stand und sorgfältig lokalisierte Varianten als zwanzig „automatische“ Sprachen.

Fehler Nr. 6: Keine Tests/Experimente für verschiedene Locales.
Wenn Sie das App‑Verhalten nicht wenigstens mit einem Basissatz an Anfragen pro Locale prüfen, kann vieles monatelang „still“ kaputt sein, bis der erste echte Nutzer mit dieser Sprache kommt. Ein kleiner goldener Testsatz und manuelle Dev‑Mode‑Tests senken dieses Risiko deutlich.

Fehler Nr. 7: Drift zwischen kanonischen und lokalisierten Beschreibungen.
Sie haben ein neues Feld occasion („Anlass“ des Geschenks) im englischen Schema hinzugefügt, aber das deutsche vergessen zu aktualisieren. In der Folge kennt das Modell dieses Feld unter DE‑Locale gar nicht und füllt es nicht, obwohl das Backend es bereits erwartet. Beispielsweise versucht der Server, Geschenke nach Anlass zu filtern, erhält null und zeigt eine zu allgemeine Liste — auf EN funktioniert alles, auf DE bricht das Verhalten unbemerkt. Daher sollten Änderungen an Tool‑Beschreibungen einem einfachen, aber regelmäßigen Prozess folgen: EN aktualisieren → Locales aktualisieren → kurz testen.