MCP ответил, но задача не выполнена: где искать ошибку инструмента

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

Что известно

В спецификации Tools описаны два механизма. Ошибки протокола — например, неизвестный инструмент или некорректная структура запроса — возвращаются через JSON-RPC error. Ошибки выполнения инструмента, включая бизнес-ограничения, передаются внутри result с isError: true. Такой ответ может объяснять модели, что именно исправить.

Транспорт решает другую задачу. Streamable HTTP доставляет ответ как JSON-объект либо поток SSE. В потоке перед финальным ответом возможны уведомления о ходе работы. Полученный HTTP-ответ или сообщение о прогрессе сами по себе ещё не подтверждают выполнение пользовательской задачи.

Что это меняет

Представим учебный инструмент бронирования переговорной. Пользователь просит комнату на прошедшую дату, а сервер возвращает result с isError: true и объяснением ошибки даты. Клиент, проверяющий только наличие result, способен ошибочно сказать, что комната забронирована. Правильное продолжение — показать причину отказа и уточнить дату, если нужную дату нельзя вывести из запроса. Это иллюстративный сценарий, а не описание проверенного сервиса.

Для приёмки интеграции подготовьте три контролируемых ответа: успешный результат, ошибку выполнения с isError и отдельную ошибку JSON-RPC. Для каждого заранее запишите ожидаемое поведение агента. Успех должен давать подтверждённый результат; ошибка выполнения — понятное объяснение и допустимый способ исправления; ошибка протокола — диагностику вызова без притворного завершения задачи.

Добавьте четвёртый случай: соединение прервалось после отправки действия. Это не доказанный отказ. Для операции с побочным эффектом сначала выясните фактическое состояние средствами конкретного сервиса. Повтор без проверки может создать вторую бронь. Такой порядок — практическое правило проектирования, а не универсальная гарантия самого MCP.

Что ещё неясно

Значение isError не сообщает, какие побочные эффекты уже произошли и безопасен ли повтор. Это должен определять контракт конкретного инструмента. Также не следует автоматически считать любой result окончательным успехом: редакция протокола 2026-07-28 предусматривает запрос дополнительного ввода через InputRequiredResult.

Критерий готовности прост: агент различает доставку сообщения, завершение вызова и достижение пользовательской цели. Пока хотя бы один из этих уровней неизвестен, итог должен сохранять эту неопределённость. Тогда исправляемая ошибка останется ошибкой, а не превратится в ложное подтверждение.