Pourquoi les agents IA dépendent de JSON : flux de données du Tool Calling au MCP

Notre article précédentPourquoi les Agent d'IA utilisent JSON Schema, Function Calling et MCPexpliquépourquoi ces trois couches existent. Cette pièce regarde leoctets qui bougent réellementen un seul véritable appel – presque tous JSON.

Les utilisateurs voient le langage naturel. Les Agents effectuent leur travail en codant l'intention sous forme de paramètres JSON, en codant les résultats de l'outil sous forme de messages JSON et en codant le protocole inter-processus sous forme JSON-RPC. JSON n'est pas une décoration ; c'est le seul langage mutuellement validable entre le modèle, l'hôte et les serveurs MCP.

Trois noms, une charge utile JSON

Les documents mélangent trois termes. Ils reposent sur différentes couches, mais la forme de la charge utile est presque la même :

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.

Pourquoi ça doit être JSON

Un Agent doit satisfaire trois parties à la fois :

• Le modèle: les données d'entraînement sont pleines de JSON ; émettre un objet valide est beaucoup plus facile que les octets protobuf
• Le programme: analyse mature, validation de schéma, Diff et outils JSONPath
• Le protocole: OpenAPI, JSON-RPC et MCP inputSchema partagent déjà une description de type

Le langage simple ne peut pas échouer rapidement : les crochets, les guillemets et les langages mixtes brisent les analyseurs d'expressions régulières. YAML est fragile en retrait. Les protocoles binaires sont hostiles à la fois aux humains et aux LLM. JSON devient le format de fil par défaut qui est auditable, validable et versionnable — c'est pourquoi les outils de ce site tournent tous autour de JSON : vous déboguez ce fil.

Hop 1 : Schéma dans la définition de l'outil

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 : Appel de fonction / Appel d'outil

Une fois que l'hôte a envoyé la liste d'outils avec des messages, le modèlen'exécute pas de code. Il renvoie un appel structuré. Forme typique (les noms des champs varient selon le fournisseur) :

{
  "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.

Tronçon 3 : MCP JSON-RPC

Si l'outil n'est pas dans le processus hôte mais dans un serveur MCP (système de fichiers, GitHub, commandes internes), l'hôte et le serveur parlent JSON-RPC 2.0. Une requête en lecture seule comporte environ trois étapes :

{"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.

Le transport peut être stdio ou Streamable HTTP ;la charge utile est toujours constituée de lignes JSON ou d'un corps JSON. Pour le transport 2026 et si le code du serveur doit changer, consultez leGuide de migration MCP 2026.

Trace de bout en bout d'un appel

L’utilisateur demande : « Quelle chaleur fait-il à Shanghai aujourd’hui ? » De bout en bout :

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. Hôte valide :contre le schéma ; les champs manquants ou les types incorrects refusent l'exécution et renvoient l'erreur JSON au modèle
5. Host → MCP: tools/call with params.arguments as an object (not a string)
6. MCP → Hôte :résultat météo JSON
7. Host → model: role: tool content string
8. Modèle → utilisateur :langage naturel; si un système en aval souhaite uniquement une structure, contraignez le JSON final avec un schéma de sortie

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

Un petit script peut ignorer MCP et appeler des fonctions locales sur l'hôte. Les agents d'entreprise empilent presque toujours Tool Calling + MCP. Pour les choix d’écosystèmes, voirClassement des serveurs MCP 2026.

Comment les échecs de validation reviennent

JSON peut agir comme le système de types de Agent car les échecs peuvent également être structurés. Utilisez au moins deux portes :

En développement, conservez Schema plus deux ou trois charges utiles valides/invalides dans git et validez-les localement dans JSON Toolbox — la même idée que les tests de contrat REST, sauf que le consommateur est un modèle.

FAQ

Résumé

Les Agents d'IA ne peuvent pas vivre sans JSON carchaque saut doit être lisible par machine: Schema décrit les outils, Tool Calling transporte l'appel, MCP l'expédie hors processus sous le nom JSON-RPC. Le langage naturel n’apparaît qu’au niveau des utilisateurs ; le milieu est constitué d'objets validables.

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 le calendrier technique. Validate Schema samples locally in JSON Toolbox before you ship.