Почему AI-агентам не обойтись без JSON: поток данных от Tool Calling до MCP

Каждый JSON-шаг вызова агента: Schema инструментов, Function Calling / Tool Calling, MCP JSON-RPC и возврат ошибок валидации.

Наша предыдущая статьяАгенты ИИ используют JSON Схема, Вызов функции и MCPобъяснилпочему существуют эти три слоя. Эта часть наблюдает забайты, которые на самом деле перемещаютсяза один реальный вызов — почти все JSON.

Пользователи видят естественный язык. Агенты выполняют работу, кодируя намерение как параметры JSON, кодируя результаты инструмента как сообщения JSON и кодируя межпроцессный протокол как JSON-RPC. JSON не является украшением; это единственный взаимно проверяемый язык среди модели, хоста и серверов MCP.

Три имени, одна полезная нагрузка JSON

Документы смешивают три термина. Они располагаются на разных слоях, но форма полезной нагрузки практически одинакова:

ИмяМеждуJSON работа
Вызов функцииМодель API ↔ хостопределение инструментов + tool_calls.arguments
Вызов инструментаТо же (общее имя)Те же сообщения/инструменты JSON
MCPХост ↔ процесс инструментаJSON-RPC методы + inputSchema

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.

Почему это должен быть JSON

Агент должен удовлетворить интересы трёх сторон одновременно:

  • Модель: данные обучения полны JSON; создать действительный объект намного проще, чем байты protobuf
  • Программа: зрелый синтаксический анализ, проверка схемы, различия и инструменты JSONPath.
  • Протокол: OpenAPI, JSON-RPC и MCP inputSchema уже имеют одно описание типа.

Простой язык не может работать быстро: скобки, кавычки и смешанные языки нарушают работу анализаторов регулярных выражений. YAML неустойчив к отступам. Бинарные протоколы враждебны как людям, так и LLM. JSON становится форматом передачи по умолчанию, который доступен для аудита, проверки и создания версий — именно поэтому все инструменты этого сайта вращаются вокруг JSON: вы отлаживаете эту связь.

Шаг 1: Схема в определении инструмента

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.

Шаг 2: Вызов функции / Вызов инструмента

После того как хост отправит список инструментов с сообщениями, модельне запускает код. Он возвращает структурированный вызов. Типичная форма (названия полей зависят от поставщика):

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

Переход 3: MCP JSON-RPC

Если инструмент находится не в хост-процессе, а на сервере MCP (файловая система, GitHub, внутренние заказы), хост и сервер говорят JSON-RPC 2.0. Запрос только для чтения состоит примерно из трех шагов:

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

Транспорт может быть stdio или Streamable HTTP;полезная нагрузка по-прежнему представляет собой строки JSON или тело JSON. Информацию о транспорте 2026 и необходимости изменения кода сервера см.MCP Руководство по странам на 2026 год.

Сквозная трассировка одного звонка

Пользователь спрашивает: «Насколько тепло сегодня в Шанхае?» От конца до конца:

  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. Хост проверяет:против схемы; отсутствующие поля или неправильные типы отказываются выполняться и возвращают ошибку JSON обратно в модель.
  5. Host → MCP: tools/call with params.arguments as an object (not a string)
  6. MCP → Хост:результат погоды JSON
  7. Host → model: role: tool content string
  8. Модель → пользователь:естественный язык; если нижестоящей системе нужна только структура, ограничьте окончательный JSON выходной схемой
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

Небольшой скрипт может пропустить MCP и вызвать локальные функции на хосте. Корпоративные агенты почти всегда объединяют Tool Calling + MCP. Выбор экосистемы см.2026 MCP Рейтинги серверов.

Как возвращаются ошибки проверки

JSON может действовать как система типов Agent, поскольку сбои также можно структурировать. Используйте как минимум двое ворот:

ВоротаЧто вы подтверждаетеКак неудача возвращается обратно
Перед выполнениемМодель аргументыНе вызывайте настоящий инструмент; записывать ошибки схемы в виде результата инструмента или системной подсказки, чтобы модель заполнялась заново.
Перед обратной записьюMCP / возврат функцииУсекать, редактировать или отмечать ошибки; не сбрасывайте необработанные стопки на следующий ход

При разработке сохраните схему плюс две или три действительных/недействительных полезных данных в git и проверяйте их локально в JSON Toolbox — та же идея, что и в тестах контракта REST, за исключением того, что потребитель является моделью.

Часто задаваемые вопросы

Являются ли «Вызов инструмента» и «Вызов функции» одним и тем же?

Для разработчиков это почти один и тот же поток данных: хост отправляет инструментальную схему модели, модель возвращает вызов с JSON аргументами, хост выполняет и записывает обратно результаты JSON. Function Calling было ранним названием OpenAI; Tool Calling/Инструменты API — более позднее общее имя.

Почему сообщения MCP тоже являются JSON?

MCP — это JSON-RPC 2.0: запросы и ответы initialize, tools/list и tools/call являются объектами JSON. inputSchema каждого инструмента представляет собой JSON Schema, поэтому Host может сопоставлять инструменты MCP один к одному с массивом инструментов API модели.

Являются ли аргументы строкой или объектом?

Большинство API в стиле Chat Completions помещают arguments в строку JSON; хост должен JSON.parse, а затем проверить его на соответствие схеме. Некоторые новые API возвращают объект. В любом случае перед выполнением проверьте ту же схему.

Почему бы не YAML или protobuf вместо JSON?

Реализации инструментов могут использовать любой внутренний формат, но контекст модели и протоколы разных поставщиков рассматривают JSON как фактический стандарт. YAML неустойчив к отступам; protobuf недружелюбен к моделям. Типичный шаблон: JSON на границе, конвертировать внутри.

Какой уровень должен проверять схему?

Как минимум два шлюза: после tool_calls и перед выполнением реального инструмента; и после возвращения сервера MCP перед обратной записью в модель. Первый блокирует галлюцинаторные параметры; второй блокирует грязные данные на следующем ходу.

Как мне проверить этот JSON локально?

Сохраните inputSchema, образцы arguments и примеры результатов инструмента в виде файлов JSON. Используйте JSON Toolbox в браузере, чтобы сверить схему с данными. Ничего не загружается.

Краткое содержание

АгентыИИ не могут жить без JSON, потому чтокаждый переход должен быть машиночитаемым: Схема описывает инструменты, Tool Calling переносит вызов, MCP отправляет его из процесса как JSON-RPC. Естественный язык появляется только на концах, обращенных к пользователю; середина — проверяемые объекты.

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 технический график. Validate Schema samples locally in JSON Toolbox before you ship.