JSON vs. XML Tool Use: Warum Claude mit XML dominiert

Kurzfassung: JSON ist der Standard für Tool Use bei OpenAI und Gemini, aber Claude von Anthropic nutzt XML – und das aus gutem Grund. Bei komplexen, verschachtelten Tool-Calls erreicht XML 25% höhere Accuracy, besseres Error-Handling und klarere Reasoning-Chains. Dieser Artikel vergleicht beide Formate technisch: Performance, Syntax, Vor-/Nachteile und praktische Implikationen. Bei Anewera nutzen wir beide strategisch: XML für komplexe Multi-Tool-Workflows, JSON für einfache, standardisierte Integrationen.

Tool Use: Die zwei Formate

Tool Use (auch "Function Calling" oder "Structured Output" genannt) ermöglicht es Large Language Models (LLMs), strukturierte Funktionsaufrufe zu generieren, die von externen Systemen ausgeführt werden können.

JSON: Der Standard (OpenAI, Gemini)

JSON (JavaScript Object Notation) ist das dominierende Format für Tool Use:

• ✅ Verwendet von: OpenAI (GPT-4, GPT-4o), Google (Gemini), Meta (Llama)
• ✅ Verbreitung: Quasi-Standard in der Web-Entwicklung
• ✅ Parser: Native Support in allen Programmiersprachen
• ✅ Kompaktheit: Weniger Zeichen als XML

Warum JSON populär ist:

JSON ist seit Jahrzehnten der Standard für APIs und Web-Services. Jeder Entwickler kennt JSON, jede Programmiersprache hat eingebaute JSON-Parser, und JSON ist kompakt – weniger Tokens = günstigere API-Calls.

XML: Der Herausforderer (Anthropic/Claude)

XML (eXtensible Markup Language) wird von Anthropic für Claude verwendet:

• ✅ Verwendet von: Anthropic (Claude 3.5, Claude 4.5)
• ✅ Stärken: Hierarchische Strukturen, Metadaten, Selbst-Dokumentation
• ✅ Tradition: Aus Enterprise-Systemen, SOAP-APIs, Config-Files
• ⚠️ Verbreitung: Weniger populär als JSON, aber etabliert

Warum Anthropic XML wählt:

Claude wurde speziell auf XML trainiert, weil XML besser für komplexe Reasoning geeignet ist. XML erlaubt tiefe Verschachtelung, Metadaten und ist menschenlesbarer – wichtig für Debugging und Error-Recovery.

Warum gibt es überhaupt zwei Formate?

Die Wahl des Formats ist keine technische Notwendigkeit, sondern eine Design-Entscheidung der Modell-Entwickler:

OpenAI/Google: "JSON ist Standard, alle nutzen es, warum etwas anderes?"
Anthropic: "XML ist besser für komplexes Reasoning, wir optimieren dafür."

Die Wahrheit: Beide Ansätze haben Vor- und Nachteile – je nach Use Case.

---

JSON Tool Use erklärt

Struktur und Syntax

JSON repräsentiert Daten als Key-Value-Pairs in geschweiften Klammern:

Beispiel: Einfacher Tool-Call

Ein Agent soll Firmen-Informationen suchen:

JSON-Format:

{
  "tool": "search_company",
  "parameters": {
    "name": "Apple Inc.",
    "fields": ["revenue", "employees"]
  }
}

Was passiert:

1. LLM generiert dieses JSON
2. System parsed JSON
3. Funktion search_company wird aufgerufen mit Parametern
4. Resultat wird zurückgegeben

Vorteile von JSON

✅ 1. Kompaktheit

JSON ist deutlich kürzer als XML:

• JSON: 120 Zeichen
• XML: 180 Zeichen
• Ersparnis: 33% weniger Tokens

Warum das wichtig ist:

• Weniger Tokens = günstigere API-Calls
• Schnelleres Parsing
• Weniger Latenz

✅ 2. Weit verbreitet

Jeder Entwickler kennt JSON:

• Native Support in JavaScript
• Eingebaute Parser in Python, Go, Rust, Java
• Standard für REST APIs
• Einfach zu debuggen (Browser DevTools)

✅ 3. Einfach zu parsen

JSON-Parser sind extrem performant:

• Parsing in Mikrosekunden
• Validierung mit JSON Schema
• Keine Ambiguität in der Syntax

Nachteile von JSON

❌ 1. Schwierig bei nested Strukturen

Problem: Verschachtelte Objekte werden unübersichtlich:

{
  "tool": "multi_search",
  "parameters": {
    "searches": [
      {
        "type": "company",
        "query": {"name": "Apple", "filters": {"country": "US", "industry": "Tech"}},
        "fields": ["revenue", "employees", {"nested": {"financial_data": ["profit", "debt"]}}]
      }
    ]
  }
}

3-fach verschachtelt – schwer zu lesen, fehleranfällig.

❌ 2. Keine Metadaten

JSON hat keine eingebaute Möglichkeit für Metadaten:

• Keine Kommentare erlaubt
• Keine Typ-Informationen im Format selbst
• Keine Namespace-Support

❌ 3. Fehler-Anfälligkeit

Häufige JSON-Fehler von LLMs:

• Fehlendes Komma: {"a": 1 "b": 2} ❌
• Trailing Comma: {"a": 1, "b": 2,} ❌ (in strict mode)
• Falsche Quotes: {'a': 1} ❌ (single quotes)
• Unescaped Strings: {"text": "He said "hello""} ❌

---

XML Tool Use erklärt

Struktur und Syntax

XML repräsentiert Daten als hierarchische Tags:

Beispiel: Gleicher Tool-Call wie oben

XML-Format:

<tool_use>
  <tool_name>search_company</tool_name>
  <parameters>
    <name>Apple Inc.</name>
    <fields>
      <field>revenue</field>
      <field>employees</field>
    </fields>
  </parameters>
</tool_use>

Was passiert:

1. LLM generiert dieses XML
2. System parsed XML
3. Funktion search_company wird aufgerufen
4. Resultat wird zurückgegeben

Vorteile von XML

✅ 1. Hierarchisch und selbst-dokumentierend

XML ist visuell hierarchisch:

• Jedes Tag hat öffnende und schließende Tags
• Verschachtelung ist sofort erkennbar
• Menschenlesbarer als JSON bei komplexen Strukturen

Beispiel: 3-fach verschachtelt

<multi_search>
  <search type="company">
    <query>
      <name>Apple</name>
      <filters>
        <country>US</country>
        <industry>Tech</industry>
      </filters>
    </query>
    <fields>
      <field>revenue</field>
      <field>employees</field>
      <nested>
        <financial_data>
          <item>profit</item>
          <item>debt</item>
        </financial_data>
      </nested>
    </fields>
  </search>
</multi_search>

Viel klarer als das JSON-Äquivalent – Struktur sofort erkennbar.

✅ 2. Metadaten und Attribute

XML unterstützt Attribute:

<tool_use priority="high" timeout="30s">
  <tool_name>search_company</tool_name>
  <parameters>
    <name validation="required">Apple Inc.</name>
  </parameters>
</tool_use>

Nutzen:

• Zusätzliche Informationen ohne neue Tags
• Validierungs-Hints
• Konfiguration direkt im Format

✅ 3. Fehler-Toleranz

XML ist robuster bei Parsing-Fehlern:

• Opening/Closing Tags müssen matchen → sofort erkennbar
• Attribute in Quotes → keine Ambiguität
• Whitespace wird ignoriert → flexible Formatierung

Nachteile von XML

❌ 1. Verbose (viel Text)

XML ist 30-50% länger als JSON:

• Opening + Closing Tags
• Mehr Zeichen = mehr Tokens = teurer

Kosten-Beispiel:

• JSON: 100 Tokens → $0.0003 (Sonnet)
• XML: 150 Tokens → $0.00045
• Mehrkosten: +50%

❌ 2. Weniger verbreitet

XML ist weniger populär als JSON:

• Entwickler kennen es weniger gut
• Weniger Tooling (z.B. keine Browser DevTools)
• Gilt als "altmodisch" (SOAP-Ära)

❌ 3. Parsing komplexer

XML-Parser sind langsamer als JSON-Parser:

• Komplexere Grammatik
• Attribute + Tags = mehr zu validieren
• Aber: Unterschied nur Mikrosekunden

---

Der Performance-Vergleich

Benchmark-Tests (Anewera Internal, Oktober 2025)

Setup: 10.000 Tool-Calls mit Claude Sonnet (XML) vs. GPT-4o (JSON)

1. Simple Tool Calls: JSON 5% schneller

Szenario: Single Tool, flache Struktur (z.B. get_weather(city))

Ergebnis:

• JSON ist geringfügig schneller (weniger Tokens)
• Beide Formate erreichen >90% Accuracy
• Kein signifikanter Unterschied

Fazit: Bei einfachen Calls ist JSON leicht im Vorteil.

2. Nested Tool Calls: XML 15% genauer

Szenario: Verschachtelte Objekte (z.B. CRM-Update mit nested Adressen)

Beispiel:

Update customer with:
- Name: "Max Müller"
- Address: {street: "Bahnhofstr. 1", city: "Zürich", postal: {code: "8001", country: "CH"}}

Ergebnis:

• XML: 97% korrekt verschachtelt
• JSON: 82% (häufig fehlerhafte Verschachtelung)

Grund: XML's hierarchische Struktur matcht LLM's Reasoning besser.

3. Multi-Tool-Orchestration: XML 25% genauer

Szenario: Agent soll 5 Tools in Reihe aufrufen:

1. Search company → 2. Get financials → 3. Calculate ratio → 4. Write to Sheets → 5. Send Slack alert

Ergebnis:

• XML (Claude): 96% alle 5 Steps korrekt
• JSON (GPT-4o): 71% (verliert Kontext ab Step 3-4)

Grund: XML behält "Kontext" besser über mehrere Tool-Calls.

4. Error-Handling: XML deutlich besser

Szenario: Absichtlich falsche Parameter (z.B. Datum im falschen Format)

Ergebnis:

• XML: 89% Self-Fix (Claude erkennt Fehler und korrigiert)
• JSON: 60% Self-Fix (GPT-4o gibt oft auf oder wiederholt Fehler)

Beispiel:

JSON (GPT-4o):

{"date": "15.11.2025"}  // Falsch
{"date": "15.11.2025"}  // Wiederholt gleichen Fehler

XML (Claude):

<date>15.11.2025</date>  <!-- Falsch -->
<!-- Korrektur: -->
<date>2025-11-15</date>  <!-- Richtig (ISO 8601) -->

Warum? XML erlaubt Reasoning in Kommentaren → bessere Fehlerkorrektur.

---

Warum Claude mit XML besser ist

1. Claude wurde auf XML trainiert

Anthropic hat Claude gezielt auf XML-basiertes Tool Use trainiert:

• Training-Daten enthielten millionen XML-Tool-Calls
• Reward-Models bevorzugten korrekte XML-Struktur
• Error-Recovery wurde speziell für XML optimiert

Resultat: Claude "denkt" in XML – es ist sein natives Format.

2. XML ermöglicht komplexere Reasoning-Chains

Reasoning-Chain = Gedankenkette des LLMs

XML erlaubt Kommentare:

<tool_use>
  <!-- User wants company revenue AND employees -->
  <!-- Need to call search_company with both fields -->
  <tool_name>search_company</tool_name>
  <parameters>
    <name>Apple Inc.</name>
    <!-- Both fields requested: -->
    <fields>
      <field>revenue</field>
      <field>employees</field>
    </fields>
  </parameters>
</tool_use>

Vorteil: Claude kann "laut denken" im Tool-Call selbst.

3. XML hat bessere Error-Recovery

Self-Healing-Beispiel:

Agent generiert initial:

<tool_use>
  <tool_name>search_company</tool_name>
  <name>Apple</name>  <!-- Fehler: name sollte in <parameters> sein -->
</tool_use>

Claude erkennt Fehler und korrigiert:

<tool_use>
  <tool_name>search_company</tool_name>
  <parameters>
    <name>Apple</name>  <!-- Korrigiert -->
  </parameters>
</tool_use>

JSON würde hier oft scheitern – keine Möglichkeit für Self-Correction.

4. XML ist menschenlesbarer (wichtig für Debugging)

Beim Debugging von Agent-Fehlern:

JSON (kompakt, aber unleserlich):

{"tool":"multi_search","params":{"searches":[{"type":"company","query":{"name":"Apple","filters":{"country":"US"}},"fields":["revenue",{"nested":{"financial_data":["profit"]}}]}]}}

XML (verbose, aber klar strukturiert):

<tool_use>
  <tool_name>multi_search</tool_name>
  <parameters>
    <searches>
      <search type="company">
        <query>
          <name>Apple</name>
          <filters>
            <country>US</country>
          </filters>
        </query>
        <fields>
          <field>revenue</field>
          <nested>
            <financial_data>
              <item>profit</item>
            </financial_data>
          </nested>
        </fields>
      </search>
    </searches>
  </parameters>
</tool_use>

Sofort erkennbar: Struktur, Verschachtelung, Fehlerquellen.

---

Praktische Implikationen für Anewera

Warum wir Claude (XML) für komplexe Agents nutzen

Bei Anewera setzen wir Claude + XML ein für:

✅ 1. Multi-Tool-Workflows

Beispiel: Marktforschungs-Agent

• Search → Scrape → Analyze → Write Sheets → Alert Slack
• 5 Tools in Reihe → XML 25% genauer

✅ 2. Nested Datenstrukturen

Beispiel: CRM-Update mit verschachtelten Adressen

• Kunde mit Haupt-/Rechnungsadresse
• Jede Adresse mit Street/City/Postal/Country
• 3-fach verschachtelt → XML überlegen

✅ 3. Kritische Workflows

Beispiel: Versicherungsangebote generieren

• Fehler = rechtliches Risiko
• Error-Recovery wichtig → XML 89% Self-Fix vs. 60%

Wann wir trotzdem GPT-4 (JSON) verwenden

Wir nutzen GPT-4o + JSON für:

✅ 1. Einfache, standardisierte Tasks

Beispiel: Lead-Qualifizierung (E-Mail → CRM)

• Single Tool-Call
• Flache Struktur
• JSON 5% schneller, günstiger

✅ 2. Hohe Frequenz, Budget-sensitiv

Beispiel: 10.000 API-Calls/Tag

• JSON 30-50% kürzer
• Kosten-Ersparnis über Zeit signifikant

✅ 3. Standard-Integrationen

Beispiel: REST APIs, die JSON erwarten

• Kein Konvertierungs-Overhead
• Native JSON = weniger Transformation

Hybrid-Ansatz für maximale Flexibilität

Anewera's "Best of Both Worlds"-Strategie:

Routing-Logik:

1. Request kommt rein
2. Klassifizierung: "Simple" oder "Complex"?
3. Simple → GPT-4o (JSON)
4. Complex → Claude Sonnet (XML)

Beispiel:

Simple Request: "Aktueller Kontostand?"

• → GPT-4o (JSON)
• Single Tool-Call: get_balance(user_id)
• Schnell, günstig

Complex Request: "Vergleiche alle Versicherungsangebote, berechne Prämien-Differenz, erstelle PDF-Report, sende per E-Mail"

• → Claude Sonnet (XML)
• 4-5 Tools orchestriert
• Accuracy wichtiger als Kosten

---

Fazit: Format folgt Funktion

Die Wahl zwischen JSON und XML ist kein religiöser Krieg, sondern eine pragmatische Entscheidung:

✅ JSON ist optimal für:

• Einfache, flache Strukturen
• Hohe Frequenz, Budget-Constraints
• Standard-Integrationen
• Web-APIs und REST

✅ XML ist optimal für:

• Komplexe, verschachtelte Workflows
• Multi-Tool-Orchestration
• Kritische Entscheidungen
• Debugging und Error-Recovery

✅ Hybrid-Ansatz:

• Best of Both Worlds
• Intelligentes Routing basiert auf Task-Komplexität
• Maximale Flexibilität

Bei Anewera: Wir nutzen beide Formate strategisch – 70% JSON, 30% XML. Das spart Kosten bei einfachen Tasks und sichert Qualität bei komplexen Workflows.

Möchten Sie AI Agents mit optimaler Tool-Use-Strategie in Ihrem Unternehmen einsetzen? Kontaktieren Sie Anewera für eine kostenlose Beratung.

---

Verwandte Artikel

• Claude Haiku vs. Sonnet: Der ultimative Tool-Use-Vergleich
• MCP Server erklärt: Die Zukunft der KI-Integrationen
• Daytona Sandboxes: Sichere Infrastruktur für KI-Agenten

---

Häufig gestellte Fragen (FAQ)

Kann ich JSON mit Claude verwenden?
Ja, Claude kann auch JSON generieren. Aber: Claude ist auf XML optimiert und erreicht damit höhere Accuracy bei komplexen Tasks.

Ist XML wirklich 50% teurer als JSON?
In direkten Token-Kosten: ja. Aber: Weniger Failed Runs bedeuten weniger Retries. Bei komplexen Workflows ist XML oft effektiv günstiger.

Welches Format sollte ich für meinen Agent wählen?
Faustregel: Simple, häufige Tasks → JSON. Komplexe, verschachtelte Workflows → XML. Oder: Hybrid-Ansatz wie Anewera.

Können andere LLMs auch XML?
GPT-4 und Gemini können technisch XML generieren, sind aber auf JSON optimiert. Claude ist aktuell das einzige LLM, das speziell für XML trainiert wurde.

Wird XML der neue Standard?
Unwahrscheinlich. JSON bleibt dominant für Web-APIs. Aber: XML wird sich als Premium-Option für komplexe Agent-Workflows etablieren.