MCP: от задачи агенту к подключённой форме

Начните с задачи для агента

Выберите готовый промпт для своего инструмента: он описывает поля, общий адрес отправки, access_key и проверку результата. Агент адаптирует разметку к вашему проекту, сохраняя дизайн сайта. Примеры для ручного подключения собраны в инструкциях по стеку.

Что даёт MCP

Model Context Protocol связывает ИИ приложение с инструментами внешнего сервиса. Клиент получает описание доступных операций и вызывает их с заданными параметрами. В отличие от текста задания, такой вызов возвращает структурированный результат действия.

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

Промпт, код и MCP: какая разница

• Промпт объясняет агенту, что изменить в проекте и как проверить результат.
• Код формы отправляет поля на общий POST /v1/submit с access_key в теле запроса.
• MCP даёт агенту способ вызывать разрешённые операции сервиса. Он не заменяет HTML форму и не меняет её внешний вид.

Для обычной отправки посетителю не нужен MCP клиент. Достаточно формы с нужными полями и публичным ключом. Подробнее — в основах подключения.

Разделите отправку и управление

Публичный access_key можно разместить в hidden поле формы. Он разрешает приём заявок в эту форму и не предоставляет права управления.

Управляющий доступ выдаётся отдельно и ограничивается рабочим пространством и разрешёнными действиями. Не вставляйте управляющий токен в HTML, клиентский JavaScript, публичный репозиторий или текст промпта. Для проверки используйте синтетические данные; реальные заявки и контакты посетителей не передавайте coding агенту.

Перед действием агента проверьте, к какому рабочему пространству относится форма и какие операции разрешены. Для отладки подключения доступ ко всей истории заявок не требуется.

Проверьте результат по этапам

1. Интерфейс. Обязательные поля проверяются, ошибка понятна, ввод сохраняется при неудаче.
2. Отправка. Уходит один корректный запрос с access_key. Ответ с ошибкой не превращается в сообщение об успехе.
3. Сохранение. Подтверждение приёма относится к сохранённой заявке. Используйте синтетическую тестовую отправку.
4. Доставка. Уведомление по email или webhook проверяется отдельно. Сохранение заявки само по себе не подтверждает доставку.

Полный порядок — в руководстве по проверке формы после ИИ.

MCP и тарифы

MCP включён в каждый тариф, включая бесплатный. Выбирайте объём по количеству заявок и активных форм, а не по способу подключения. Сравните тарифы или перейдите к промптам.

Проверьте подключение по сохранённому тесту

После подключения попросите агента отправить синтетический тест через submit_test и прочитать get_test_status по полученному ID. Для этого выдайте право submissions:test. Диагностика показывает сохранение и состояние обработки, не раскрывая содержимое реальных заявок. Повтор неизменного теста использует тот же ключ идемпотентности.

Письмо владельцу проверяйте отдельным явным действием test_owner_notification с правом delivery:test. Это право не выбрано по умолчанию. Ответ queued подтверждает постановку в очередь, а delivered появляется после записанного результата провайдера. Статус failed не удаляет сохранённый тест. Для исправления ошибки используйте безопасный код запроса; не передавайте агенту настоящие заявки или секреты сайта.

Обновлено 27 октября 2026 г.