Warum KI-Agenten JSON brauchen: Datenfluss von Tool Calling und Function Calling bis MCP

Unser früherer ArtikelWarum KI-Agenten JSON-Schema, Funktionsaufruf und MCP verwendenerklärtwarum diese drei Schichten existieren. Dieses Stück beobachtet dieBytes, die sich tatsächlich bewegenin einem echten Anruf – fast alle davon JSON.

Benutzer sehen natürliche Sprache. Agenten erledigen ihre Arbeit, indem sie Absichten als JSON-Parameter kodieren, Tool-Ergebnisse als JSON-Nachrichten kodieren und prozessübergreifende Protokolle als JSON-RPC kodieren. JSON ist keine Dekoration; Es ist die einzige gegenseitig validierbare Sprache zwischen dem Modell, dem Host und den MCP-Servern.

Drei Namen, eine JSON-Nutzlast

Dokumente vermischen drei Begriffe. Sie sitzen auf unterschiedlichen Schichten, aber die Form der Nutzlast ist nahezu gleich:

One sentence: the model side uses JSON to pick a tool and fill parameters; the MCP side uses JSON to discover and execute tools. The host is the translator: MCP tools/list becomes the model tools array; model tool_calls become tools/call.

Warum es JSON sein muss

Ein „Agent“ muss drei Parteien gleichzeitig zufriedenstellen:

• Das Modell: Trainingsdaten sind voll von JSON; Das Ausgeben eines gültigen Objekts ist weitaus einfacher als das Ausgeben von Protobuf-Bytes
• Das Programm: ausgereifte Analyse, Schemavalidierung, Diff und JSONPath-Tools
• Das Protokoll: OpenAPI, JSON-RPC und MCP inputSchema teilen bereits eine Typbeschreibung

Einfache Sprache kann nicht schnell versagen: Klammern, Anführungszeichen und gemischte Sprachen machen Regex-Parser kaputt. YAML ist einrückungsfragil. Binäre Protokolle sind sowohl für Menschen als auch für LLMs feindlich. JSON wird zum standardmäßigen Wire-Format, das überprüfbar, validierbar und versionierbar ist – weshalb sich alle Tools dieser Website um JSON drehen: Sie debuggen diesen Wire.

Hop 1: Schema in der Tooldefinition

The flow starts by telling the model which tools exist. Whether you use OpenAI-style tools or MCP tools/list, the core is a JSON Schema (or a subset):

{
  "name": "get_weather",
  "description": "Look up current weather for a city, read-only",
  "parameters": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "City name, e.g. Shanghai" },
      "unit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
    },
    "required": ["city"]
  }
}

In MCP the same constraint lives in inputSchema. Schema feeds two paths: the validator rejects illegal parameters; model context uses description to decide when to call. The more the field text reads like a product spec, the fewer mistaken calls.

Hop 2: Funktionsaufruf / Tool-Aufruf

Nachdem der Host die Werkzeugliste mit Nachrichten gesendet hat, wird das Modellführt keinen Code aus. Es wird ein strukturierter Aufruf zurückgegeben. Typische Form (Feldnamen variieren je nach Anbieter):

{
  "role": "assistant",
  "tool_calls": [
    {
      "id": "call_01",
      "type": "function",
      "function": {
        "name": "get_weather",
        "arguments": "{\"city\":\"Shanghai\",\"unit\":\"celsius\"}"
      }
    }
  ]
}

Note that arguments is often a stringified JSON object: JSON.parse first, validate against Schema, then execute. Results flow back as a tool-role message:

{
  "role": "tool",
  "tool_call_id": "call_01",
  "content": "{\"city\":\"Shanghai\",\"temp_c\":31,\"condition\":\"sunny\"}"
}

This hop is how the model reaches out. With parallel tools, the array holds multiple tool_calls; the host may run them concurrently and match results by id.

Hop 3: MCP JSON-RPC

Befindet sich das Tool nicht im Host-Prozess, sondern auf einem MCP-Server (Dateisystem, GitHub, interne Aufträge), sprechen Host und Server JSON-RPC 2.0. Eine schreibgeschützte Abfrage besteht ungefähr aus drei Schritten:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"host","version":"1.0"}}}
{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}
{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"get_weather","arguments":{"city":"Shanghai"}}}

A successful Server response is JSON too: content often has type: "text" whose text is another JSON string. That is JSON wrapping JSON — outer envelope vs inner business payload. When debugging MCP, split those layers, then Schema-validate the inner one.

Der Transport kann stdio oder Streamable HTTP sein;Die Nutzlast besteht immer noch aus JSON-Zeilen oder einem JSON-Körper. Informationen zum Transport im Jahr 2026 und dazu, ob sich der Servercode ändern muss, finden Sie imMCP 2026 Migrationsleitfaden.

End-to-End-Verfolgung eines Anrufs

Der Nutzer fragt: „Wie warm ist es heute in Shanghai?“ Ende bis Ende:

1. Host → MCP Server: tools/list returns tools with inputSchema (JSON)
2. Host → model API: mapped to tools[].parameters (still JSON Schema)
3. Model → Host: tool_calls with arguments {"city":"Shanghai"}
4. Host validiert:gegen Schema; Fehlende Felder oder falsche Typen verweigern die Ausführung und geben den Fehler JSON zurück an das Modell
5. Host → MCP: tools/call with params.arguments as an object (not a string)
6. MCP → Host:Wetterergebnis JSON
7. Host → model: role: tool content string
8. Modell → Benutzer:natürliche Sprache; Wenn ein Downstream-System nur Struktur benötigt, schränken Sie den endgültigen JSON mit einem Ausgabeschema ein

User natural language
    │
    ▼
Host orchestration ──JSON Schema──► LLM Tool Calling
    │                                  │
    │                                  ▼
    │                             arguments JSON
    │                                  │
    ▼                                  ▼
MCP JSON-RPC ◄──────────── validate, then execute
    │
    ▼
Result JSON ──► tool message ──► model final reply

Ein kleines Skript kann MCP überspringen und lokale Funktionen im Host aufrufen. Unternehmensagenten kombinieren fast immer Tool Calling + MCP. Informationen zu Ökosystem-Picks finden Sie unter2026 MCP Server-Rangliste.

Wie Validierungsfehler zurückfließen

JSON kann als Typsystem des Agent fungieren, da auch Fehler strukturiert werden können. Verwenden Sie mindestens zwei Tore:

Behalten Sie in der Entwicklung Schema plus zwei oder drei gültige/ungültige Nutzlasten in Git und validieren Sie sie lokal in der JSON Toolbox – die gleiche Idee wie REST-Vertragstests, außer dass der Verbraucher ein Modell ist.

FAQ

Zusammenfassung

KI-Agenten können nicht ohne JSON leben, weilJeder Hop muss maschinenlesbar sein: Schema beschreibt Tools, Tool Calling überträgt den Aufruf, MCP versendet ihn aus dem Prozess als JSON-RPC. Natürliche Sprache erscheint nur an den Enden, die dem Benutzer zugewandt sind; Die Mitte besteht aus validierbaren Objekten.

Start with one real tool: write the Schema → print and parse the model's arguments string → if the tool lives on an MCP Server, capture one tools/call. When those three JSON documents line up, the Agent is actually working. For the evolution story see der technische Zeitplan. Validate Schema samples locally in JSON Toolbox before you ship.