MCP JSON проверяют на двух уровнях: конверт JSON-RPC связывает запрос с ответом, а inputSchema задаёт допустимые аргументы инструмента. В актуальной ревизии 2026-07-28 запрос также несёт обязательную _meta с версией протокола и возможностями клиента. Такой разбор нужен, когда инструмент виден в каталоге, но вызов отвергается или ответ выглядит противоречиво.
Конверт сообщения
MCP использует конверт JSON-RPC 2.0: запрос содержит метод и идентификатор, ответ возвращает результат либо ошибку с тем же идентификатором. В ревизии MCP 2026-07-28 каждый запрос также передаёт обязательные поля протокола внутри params._meta.
Запрос «mcp json» обычно приводит к путанице между форматом сообщения и описанием инструмента. Конверт отвечает за передачу команды и сопоставление ответа. Схема инструмента описывает допустимые аргументы конкретного вызова. Для диагностики нужен контроль обоих уровней: корректный JSON подтверждает синтаксис, а допустимость вызова и права клиента проверяют отдельно.
Согласно базовой спецификации MCP, поле jsonrpc содержит строку 2.0. Это версия JSON-RPC, тогда как дата 2026-07-28 обозначает ревизию MCP. В запросе обязательны id и method; params несёт параметры метода. Значение id бывает строкой или целым числом, значение null для запроса MCP исключено. Пока отправитель ожидает ответ, тот же идентификатор для другого запроса использовать нельзя.
Особенность этой ревизии: в params._meta каждого запроса клиент указывает io.modelcontextprotocol/protocolVersion и io.modelcontextprotocol/clientCapabilities. Первый ключ сообщает ревизию протокола, второй описывает доступные возможности клиента. Отсутствие обязательного поля означает некорректные параметры запроса; сервер возвращает протокольную ошибку. Такая метаинформация относится к каждому запросу отдельно; каждый следующий запрос снова передаёт обязательные поля.
Ответ и ошибка
Успешный ответ содержит тот же id и объект result. Для результатов текущей ревизии спецификация задаёт resultType: значение complete означает завершение операции, значение input_required сообщает о потребности в дополнительном вводе. Клиент связывает ответ с ожидающим запросом по идентификатору и затем разбирает тип результата. Данные результата зависят от вызванного метода; поиск знакомого текста в любом поле создаёт ложное впечатление успешного вызова.
При протокольном отказе ответ содержит error с целочисленным code и строковым message. Поле data допускает дополнительные сведения. Идентификатор сохраняет связь с запросом, кроме случая, когда из повреждённого сообщения его невозможно извлечь. Отдельно стоит различать ошибку конверта и результат инструмента с признаком isError: последний означает, что вызов инструмента дошёл до серверной обработки, но сама операция завершилась ошибкой.
Уведомление выглядит похоже на запрос, однако поле id в нём отсутствует; получатель завершает обработку без ответа. Поэтому попытка ожидать result после уведомления приведёт к ложной диагностике зависания. При отладке отмечайте направление сообщения, метод, идентификатор и тип ответа. Связанные методы и роли клиента раскрывает обзор MCP-клиента; здесь важна именно форма записи на проводе.
В журнал диагностики переносите обезличенный идентификатор запроса, имя метода, тип результата и код ошибки. Аргументы, ключи доступа и содержимое рабочих документов остаются в защищённом контуре; для разбора достаточно синтетического примера.
Схема аргументов
Ответ на tools/list содержит описание доступных инструментов. У каждого инструмента есть имя и inputSchema, задающая форму аргументов по JSON Schema. Эта схема находится внутри описания инструмента. Верхний уровень JSON-RPC запроса содержит поля конверта. В tools/call клиент указывает имя инструмента и объект arguments. Валидатор сопоставляет аргументы со схемой выбранного имени до выполнения действия.
На странице инструментов MCP примеры запросов сокращены: обязательные поля _meta в них опущены ради чтения. Для рабочего теста такое сокращение копировать буквально нельзя. Клиенту требуется собрать полный запрос своей ревизии. При отсутствии явного диалекта в inputSchema базовая спецификация использует JSON Schema 2020-12; валидатор учитывает объявленный либо стандартный диалект.
| Уровень | Что проверить | Признак сбоя |
|---|---|---|
| JSON | Синтаксис объекта и типы полей | Парсер отвергает сообщение |
| JSON-RPC | jsonrpc, id, method, result либо error | Ответ расходится с запросом |
| MCP | Обязательная params._meta текущей ревизии | Сервер отвергает параметры |
| Инструмент | Имя и arguments по inputSchema | Аргумент лишний или отсутствует |
| Доступ | Право вызывающего субъекта на действие | Сервер отклоняет операцию |
Схема проверяет структуру входа, а разрешение на действие проверяет сервер. Поле description помогает языковой модели выбрать инструмент. Права и подтверждение действия проходят отдельную серверную проверку. Для опасного вызова приложение показывает предлагаемые аргументы человеку, а сервер повторно проверяет доступ и подтверждение. Подробнее о назначении каталога функций — в материале про инструменты MCP.
Хотите проверить конверт MCP и права своего инструмента?
Безопасный тест
Для будущего пилота подготовьте отдельный тестовый сервер и синтетический инструмент чтения. Его описание должно содержать простую схему аргументов с обязательным строковым полем. Запросы отправляйте из клиента с разрешённым тестовым доступом. Такая постановка позволяет увидеть путь от перечисления инструментов до ответа без записи в рабочие системы и без копирования секретов в трассу.
- Зафиксируйте ревизию MCP, список разрешённых методов и эталонную inputSchema инструмента. Сохраните обезличенные примеры допустимых и ошибочных аргументов.
- Соберите запрос tools/list с уникальным id и обязательными полями params._meta. Проверьте ответ парсером: совпадение id, наличие result и описания нужного инструмента.
- Создайте tools/call с допустимыми arguments. Затем отдельно отправьте объект с пропущенным обязательным полем и запрос без нужной метаинформации.
- Сопоставьте наблюдаемый ответ с ожидаемым уровнем ошибки. Для протокольной ошибки смотрите error; для ошибки исполнения инструмента смотрите результат вызова и его признак.
- Повторите вызов под субъектом без разрешения и проверьте отказ на сервере. Сохраните только очищенную трассу, решение владельца доступа и перечень исправлений.
Парсер или скрипт проверяет синтаксис, обязательные поля, совпадение идентификаторов и аргументы по схеме на полном наборе сообщений. Языковая модель может объяснить очищенный фрагмент трассы и предложить гипотезу причины отказа. Разработчик сверяет гипотезу со спецификацией и реальным ответом сервера. Такой порядок отделяет наблюдаемый факт от вероятного объяснения и сохраняет контроль над вызовом.
Если схема содержит внешние ссылки $ref, валидатор по умолчанию оставляет сетевое разрешение выключенным. Базовая спецификация требует явного разрешения для такого доступа; при недоступной ссылке безопаснее отклонить схему. Тест также ограничивает размер входа и глубину сложной схемы для защиты валидатора от избыточной нагрузки.
Приёмка пилота
Предложенный пилот принимает владелец внутреннего инструмента вместе с разработчиком клиента. До запуска они согласуют набор методов, роли, синтетические входы и журнал наблюдений. Проверка охватывает успешный запрос, ошибку формата, неверные аргументы, отсутствие обязательной метаинформации, отказ в доступе и повторное использование идентификатора среди ожидающих запросов. Для каждого сценария фиксируют ожидаемую форму ответа, фактический ответ и ответственного за исправление.
Критерий готовности связан с наблюдаемым поведением: допустимый вызов получает связанный ответ, ошибочный аргумент отклоняется по понятной причине, запрещённое действие остаётся закрытым на сервере. Отдельно проверьте: журнал содержит лишь разрешённые диагностические поля и сохраняет аргументы с секретами вне трассы. Полезно также различать ошибку клиента при разборе JSON и отказ сервера: у них разные владельцы исправления и разные доказательства в журнале.
Сравнение ревизий MCP и порядок перехода между ними вынесены в соседние материалы; здесь проверяется один конкретный конверт сообщения. Архитектуру собственного сервера разбирает статья о сервере MCP. Если нужен маршрут согласования, разработки и приёмки внутренних инструментов, его можно обсудить в рамках внедрения ИИ-агентов для компании.
Расходы на такой контур зависят от способа размещения сервера, требований к журналу, количества инструментов и процесса согласования. Тарифы сервисов сверяют перед выбором решения по действующим условиям поставщиков. Начинать удобнее с узкого инструмента чтения: его ответы дают проверяемую картину обмена, а команда получает основу для дальнейшего решения о расширении доступа. Перед расширением набора инструментов команда повторяет те же сценарии для каждого нового метода. Так владелец видит, какая схема изменилась, какой отказ ожидался и кто подтвердил переход к рабочему доступу.