MCP-клиент принял форму, а tool упал на обязательном поле

Инструмент оформления демо-звонка запрашивает через MCP имя и рабочий email. Клиент показывает форму, пользователь нажимает «Отправить», а сервер получает пустую строку вместо email. Если обработчик сразу создаёт встречу, в CRM появляется запись без адреса. Наличие формы в протоколе не освобождает сервер от проверки данных на границе действия.

Где находится ответ в новой редакции

В опубликованной редакции MCP 2026-07-28 сервер не отправляет отдельный запрос клиенту посреди вызова tool. Он возвращает input_required с запросом elicitation/create внутри inputRequests. Клиент показывает форму и повторяет исходный вызов с inputResponses и сохранённым requestState. Ответ формы содержит action: accept, decline или cancel. Только при accept ожидается content с полями по requestedSchema.

Для email укажите в схеме строку с format: email и включите поле в required. Клиенту это помогает построить форму и обнаружить ошибку до отправки. На сервере после повторного вызова проверьте действие, тип объекта, наличие поля, формат адреса и собственные бизнес-правила. Не трактуйте decline как пустой email: пользователь явно отказался. cancel значит, что выбор не завершён. Оба исхода завершают или откладывают операцию без записи в CRM.

Полезно явно задать таблицу исходов для обработчика: accept с корректными полями ведёт к записи; accept с ошибкой возвращает новую форму или понятную ошибку ввода; decline завершает просьбу без действия; cancel оставляет пользовательский запрос незавершённым либо сообщает, что его можно повторить. Не превращайте любой неуспешный ответ в бесконечное повторение формы. Ограничьте число раундов и покажите пользователю, какое поле требует исправления.

Не повторяйте побочный эффект вместе с формой

Повторный вызов исходного tool — часть механизма получения ответа. Если до input_required вы уже создали черновик встречи, повтор может создать второй. Сохраните непрозрачное состояние запроса и перенесите запись в CRM на этап после успешной проверки принятого ответа; если ранняя запись неизбежна, используйте стабильный ключ операции и идемпотентный API. Тот же requestState должен связывать ответ с той формой и тем исходным вызовом, для которых он был выдан. Не доверяйте полям, которые клиент не обязан защищать от подмены.

requestState проходит через клиента и возвращается обратно, поэтому сервер не должен считать его подписанным сам по себе. Для состояния, которое влияет на запись, используйте проверяемую подпись либо храните состояние на сервере по случайному идентификатору. Свяжите его с пользователем, исходными параметрами и сроком действия. Иначе ответ на форму для одной встречи можно приложить к повторному вызову с другими аргументами.

В тесте отправьте четыре ответа: корректный accept, accept без email, decline и cancel. CRM должна получить запись только в первом случае. Отдельно проверьте повтор одного принятого ответа: второй записи быть не должно. Для API-ключа или платёжных данных не используйте обычную форму — спецификация предусматривает URL mode для чувствительных сведений вне MCP-клиента.

В платном курсе AI Agent Integrations PRO: MCP вы описываете контракт инструментов и ресурсов, подключаете клиент и проверяете сервер тестами. Elicitation добавляет к этому контракту ещё один исход вызова, который должен быть обработан до внешнего действия. Откройте программу курса, чтобы собрать такой поток на собственной MCP-интеграции.