Warum AI Agents JSON brauchen: von Function Calling bis MCP

Symptom: Der Agent unterhält sich, aber Tool-Argumente scheitern an der Validierung, Retries verdoppeln eine Bestellung, oder ein MCP-Server läuft und es erscheinen keine Tools.
Schnellste Lösung: Behandeln Sie JSON als den einzigen Vertrag zwischen Modell und Tools: Eingaben per JSON Schema begrenzen, Ergebnisse in festen Feldern zurückgeben und MCP nur nutzen, um denselben Vertrag über Prozessgrenzen hinweg auffindbar zu machen.

Der Text richtet sich an Entwickler, Plattformteams und Architekten, die ein Sprachmodell an echte Systeme anbinden. Es geht nicht um ein weiteres Schlagwort, sondern darum, wie dasselbe JSON durch Function Calling, Tool Calling und MCP wandert und welcher Hop die Kette stoppt.

Wenn Sie noch ein Framework wählen, lesen Sie zuerst AI-Agent-Framework auswählen. Für Isolierung bei der Ausführung siehe AI Sandbox, Docker und virtuelle Dateisysteme.

Warum ein AI Agent JSON braucht

Modelle erzeugen Sprache. Produktionssysteme akzeptieren strukturierte Befehle. Sobald ein Agent Bestand prüft, Tickets ändert, Tests startet oder einen Browser steuert, muss Absicht zu Daten werden, die sich prüfen, ablehnen und auditieren lassen. JSON sitzt in dieser Fuge: lesbar für Menschen, parsebar für Maschinen, bereits in HTTP, Logs, Queues und Datenbanken zu Hause.

Der Vorteil ist Prüfbarkeit. Prosa sagt einem Gateway nicht, dass order_id ein String, amount positiv und currency ein Enum sein muss. JSON Schema tut das. Die OpenAI-Anleitung für Function Calling definiert Funktionsparameter als JSON Schema, damit das Modell schon beim Sampling in legale Strukturen läuft. OpenAI Function Calling Guide öffnen

Typen, Pflichtfelder, Enums und additionalProperties sind keine Theorie. Sie sind das erste Tor gegen erfundene Felder, Strings in Zahlen und fehlende Idempotenzschlüssel. JSON-Schema-Dokumentation öffnen

• Gespräch: „Mach die Bestellung aus dem Lager Shanghai Express.“
• Vertrag: {"name":"update_order","arguments":{"order_id":"A938","priority":"expedited"}}
• Ausführung: Schema, Rechte, Fach-API, JSON-Ergebnis zurück an das Modell.

Ohne Vertragsschicht bleibt der Agent ein Chatfenster. Mit ihr kann er ein gesteuerter Executor werden.

⚠️ Faustregel: Wenn Argumente noch „Freitext plus Regex“ sind, haben Sie kein Protokoll, nur Prompt-Glück. Schema zuerst, Orchestrierung danach.

Function Calling: das Modell füllt ein Formular

Function Calling heißt: Bevor das Modell dem Nutzer antwortet, darf es eine deklarierte Funktion wählen und schema-konforme Argumente liefern. Der Pfad hat fünf Schritte, in jedem kann ein Feld verloren gehen.

1. Registrieren: tools mit name, description, parameters als JSON Schema.
2. Entscheiden: Funktion oder direkte Antwort.
3. Ausfüllen: tool_calls, arguments als JSON-String oder Objekt.
4. Ausführen: parsen, validieren, autorisieren, echtes System aufrufen.
5. Zurückspielen: Tool-Nachricht, danach die Nutzantwort.

Descriptions sind Routing-Signale. „Wetter abfragen“ konkurriert mit „Sendung abfragen“. „Nur aufrufen, wenn ein Stadtname vorliegt; nicht für historische Klimafragen“ senkt Fehlauslösungen. Feldbeschreibungen im Schema sind ebenfalls Prompts. „order_id ist die Geschäftsnummer, keine Payment-ID“ gehört ins Schema.

Strict Mode und Structured Outputs heben „sieht nach JSON aus“ auf „entspricht dem Schema“. JSON mode garantiert nur parsebare Klammern. Schema-gültig ist nicht fachlich gültig. Negative Beträge, unbekannte Lager, fehlende Rechte müssen in Ihrem Code scheitern.

Ein minimal ausführbarer Vertrag

Das Schema friert Enums und einen Idempotenzschlüssel ein. Das Modell darf den Aufruf verweigern, aber keine Extra-Lagerfelder erfinden und idempotency_key nicht weglassen.

{
  "type": "function",
  "name": "update_shipment",
  "description": "Nur aufrufen, wenn der Nutzer die Lieferpriorität ausdrücklich ändern will.",
  "strict": true,
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {"type": "string", "description": "Geschäfts-Bestellnummer"},
      "priority": {"type": "string", "enum": ["standard", "expedited"]},
      "idempotency_key": {"type": "string"}
    },
    "required": ["order_id", "priority", "idempotency_key"],
    "additionalProperties": false
  }
}

Reihenfolge: JSON-Parse → Schema → Rechte → Idempotenz → Fach-API → {"ok":true,"shipment_id":"..."} oder {"ok":false,"error":"not_found"}. Keine Stacktraces oder Geheimnisse im Tool-Result.

Tool Calling: von der Funktion zur Tool-Fläche

Teams brauchten mehr als eigene Funktionen: Suche, Code-Interpreter, Browser, Computer Use, Dateisuche. APIs wechselten von function_call zu einem einheitlichen tools-/Tool-Calling-Oberfläche. Der Name änderte sich, der JSON-Vertrag nicht.

Anthropic nennt das Tool use und beschreibt input_schema als JSON Schema. Das Modell sendet einen tool_use-Block, die App antwortet mit tool_result. Anthropic Tool-use-Dokumentation öffnen

• Parallele Aufrufe: Reads parallel, Bestandssperre und Zahlung seriell.
• Freigabe: riskante Tools liefern pending-JSON statt Ausführung.
• Beobachtbarkeit: Traces mit Toolname, Argumentkurzform, Latenz, Fehlercode.

Das Modell kann das richtige Tool wählen und trotzdem eine gefährliche Nutzlast in einem String verstecken. Schema fängt Typen, nicht Semantik. Gefährliche Tools brauchen Allowlist, Timeout und Sandbox.

MCP: den JSON-Vertrag steckbar machen

Function- und Tool Calling beschreiben das Gespräch in einer API-Anfrage. MCP beschreibt Entdeckung, Wiederverwendung durch viele Hosts und Ausführung in einem eigenen Prozess. Die Spezifikation nutzt JSON-RPC 2.0. MCP-Spezifikation öffnen

1. Host startet als MCP-Client.
2. Verbindung über stdio, SSE oder Streamable HTTP.
3. initialize handelt Version und Fähigkeiten.
4. tools/list liefert inputSchema (weiterhin JSON Schema).
5. Das Modell bleibt bei Tool Calling; der Client sendet tools/call mit JSON.
6. Server-Content wird zum Tool-Result.

MCP ersetzt JSON nicht. Es macht aus einem hart kodierten tools-Array einen Laufzeitkatalog. Derselbe Git-Server, dieselbe Browser-Automation, dieselbe Ticket-API können Cursor, Claude Desktop und Ihr Agent teilen.

„MCP ist da, Tools fehlen“ ist fast immer ein Vertragsfehler: initialize, leere Liste, Schema vs. Strict Mode, fehlende required-Felder oder Prosa statt JSON-RPC-Error.

Ende-zu-Ende: ein Satz bis zur MCP-Ausführung

1. Nutzer schreibt natürliche Sprache.
2. Runtime baut messages, lokale Tools und MCP-tools/list.
3. Modell erzeugt JSON-Argumente.
4. Routing: lokale Funktion oder JSON-RPC tools/call.
5. Ergebnis-JSON kehrt in den Dialog.
6. Erneuter Aufruf, Rückfrage oder Antwort.

Eine Grenze wird übersehen: Das Modell hält keine Datenbankverbindung. Es erzeugt nur JSON. Wer parst, welche Maschine ausführt, ob SSH/VNC und ob Outbound-Netz erlaubt ist, ist Runtime-Politik. Ein Agent auf einem Cloud-Mac nutzt dasselbe Protokoll, eine andere Rechtebene.

Ignorieren Sie Produktnamen. Dienen Tools nur einer App, reicht Function/Tool Calling. Sollen mehrere Hosts sie teilen, lohnt ein MCP-Server. Ohne Schema verschiebt MCP nur das Chaos.

Wenn JSON bricht, bricht die Agent-Kette

• Kein gültiges JSON: Strict aus, „erst erklären“, Markdown-Zaun. Nur den strukturierten Tool-Kanal nutzen.
• Parse ok, Schema fehl: required, Enum, additionalProperties. Validierungsfehler als Tool-Result, Retries begrenzen.
• Schema ok, Fachfehler: unbekannte Bestellung, Bestand, Rechte. Stabiler error code, keine 500-HTML.
• Retry schreibt doppelt: Timeout plus zweiter Aufruf. idempotency_key und Deduplizierung.
• list und call driften: Namens- oder Schemawechsel nach Reload. Hash versionieren, neu initialize.
• Geheimnisse in JSON-Logs: volle Argumente im Shared Trace. Nur Feldnamen und Hashes, Tokens und PII schwärzen.

Machen Sie Timeout, Schemafehler und Rechteverweigerung zu einem Abnahmeszenario. Loopt der Agent oder ändert Argumente wild, gehört er nicht an Zahlung, Versand oder Produktionsdatenbanken.

JSON-Vertrags-Checkliste vor dem Go-live

• [ ] Jedes Tool hat name, description, JSON Schema, additionalProperties: false.
• [ ] Risiko-Felder mit Enum, Format, Maximallänge.
• [ ] Writes mit Idempotenzschlüssel; Timeout/Retry in der Runtime.
• [ ] Tool-Results mit ok / error / data, keine Stacktraces.
• [ ] Parallele Calls nach Seiteneffekt; Zahlung, Mail, Delete serial.
• [ ] MCP initialize / list / call mit Timeout, Auth, Fehlercodes.
• [ ] Hosts laden Schemas nach Katalogwechsel neu.
• [ ] Traces rekonstruieren die Kette, nicht die Secrets.
• [ ] Ein eingefrorener Prompt trifft denselben Toolnamen und dieselbe Pflichtfeldmenge.

Erst danach Multi-Agent oder schwere Workflows. Ein instabiles Protokoll kopiert kaputtes JSON nur schneller.

FAQ

Warum nicht natürliche Sprache vom Programm parsen lassen?

Es gibt keine Pflichtfelder und Typen. „Mach es eilig“ lässt sich nicht stabil auf ein Enum mappen. JSON Schema macht aus Parsen Validierung.

Unterscheiden sich Tool Calling und Function Calling praktisch?

Für Anwendungsentwickler bleibt der Kern: JSON-Formular, Ihr Code führt aus. Tool Calling ist die breitere Fläche mit Host-Tools, parallelen Aufrufen und einheitlichem Result-Kanal. Beim Umzug zuerst Schema und Rollen angleichen.

Wann MCP statt fest kodiertem tools-Array?

Wenn dieselben Tools mehrere Hosts, Isolation in einem eigenen Prozess oder Veröffentlichung durch ein anderes Team brauchen. Lebt ein Tool mit einem internen Dienst, ist Function/Tool Calling einfacher.

Manchmal kaputtes JSON: retry oder Protokollwechsel?

Strict Structured Output einschalten und keine Argumente aus Prosa ziehen. Bleibt die Quote hoch, Schema-Tiefe, widersprüchliche Descriptions und Toolanzahl prüfen. MCP ändert nichts daran, dass Argumente JSON bleiben.

Auf einem geteilten Laptop zerfallen Schema-Regressionen, sobald die Umgebung driftet, und MCP-Prozesse kämpfen um Entwicklerports. Ein Kvmjet-Bare-Metal-Mac in der Cloud hält ein festes macOS-Image, damit Sie denselben Tool-Calling- oder MCP-Fehler per SSH oder VNC reproduzieren. Öffentlich sind Tages- bis Quartalstarife beschrieben — genug, um den JSON-Vertrag zu stabilisieren, bevor Sie langfristig mieten.

Nehmen Sie die Checkliste mit ins Kvmjet-Hilfezentrum, prüfen Sie Dauerbetrieb, Rechteisolation und Fernzugriff und entscheiden Sie dann, ob der MCP-Server auf dem Laptop, im Rack oder auf einem Cloud-Mac liegt.