Подключайте ИИ-агента к сайту через MCP поэтапно: сначала дайте ему доступ только для чтения, затем проверьте работу на тестовых сценариях и лишь после этого открывайте отдельные действия с подтверждением человека. MCP связывает модель с инструментами сайта, например поиском по каталогу или созданием черновика заявки. В статье разберём, как выбрать доступы, проверить границы и не дать агенту выполнить действие, которого вы от него не ожидали.
Что MCP даёт ИИ-агенту на сайте?
MCP — способ подключить модель к внешним инструментам по понятному интерфейсу. Агент может запросить у сервера данные или вызвать доступную функцию. Например, посетитель спрашивает о статусе заказа: агент ищет запись в системе и формулирует ответ на её основе.
Само подключение не определяет, какие действия безопасны. Это задают инструменты, доступы и правила работы агента. Если инструмент умеет только искать заказ, агент не сможет отменить его через этот инструмент. Если же ему доступна функция отмены, понадобятся отдельные ограничения и проверка.
Для работы с Claude Code полезно сначала разобраться, как подключить MCP-серверы к GitHub и базе данных. Принцип тот же: отдельно настройте сервер, инструменты и права доступа, а потом проверьте, что агент видит только нужные функции.
Как ограничить действия агента?
Начните с перечня задач, которые посетитель сможет решать через сайт. Для каждой задачи определите, какие данные нужны и что агенту разрешено сделать. Не добавляйте инструмент «на всякий случай»: каждая доступная функция расширяет круг действий агента.
- Поиск информации. Разрешите читать опубликованные страницы, каталог или справочные данные.
- Просмотр статуса. Ограничьте поиск конкретным идентификатором заказа или заявки, который предоставил пользователь.
- Подготовка ответа. Пусть агент составит текст или черновик, который сотрудник проверит перед отправкой.
- Изменение данных. Выдавайте доступ к конкретной операции только тогда, когда без неё не обойтись.
- Подтверждение. Перед отменой заказа, изменением записи или другим значимым действием запрашивайте согласие человека.
Разделите инструменты по назначению. Например, функцию просмотра заказа назовите так, чтобы её назначение было очевидно, а функцию отмены отделите от чтения. В описании инструмента укажите обязательные параметры и случаи, когда агент должен отказаться от вызова. Не объединяйте чтение и изменение данных в одну универсальную функцию.
Если разработчик подключает агента к сайту, начните с тестовой среды и ограниченных учётных данных. Для каждого инструмента проверьте, что происходит при пустом параметре, неверном номере заказа и запросе к чужой записи. Отдельно проверьте ситуацию, когда сервер недоступен: агент должен сообщить, что проверить действие не удалось, а не придумывать результат.
Как проверить связку до запуска?
Составьте сценарии из обычных запросов посетителей и пограничных случаев. Для небольшого первого прогона используйте реальные по форме, но тестовые данные. Сверяйте не только текст ответа: проверяйте, какой инструмент вызвал агент, какие параметры передал и изменились ли данные.
- Проверьте запрос, на который агент может ответить по открытой информации сайта.
- Попросите найти статус по корректному тестовому номеру.
- Передайте отсутствующий или неверный номер и проверьте, что агент запросит уточнение.
- Попросите выполнить действие, для которого нет доступного инструмента.
- Проверьте, что изменение не происходит без требуемого подтверждения.
Для каждого сценария запишите ожидаемый результат: ответ, допустимый вызов инструмента и состояние данных после проверки. Такой набор можно повторить после изменения системной инструкции, модели или MCP-сервера. Подход к проверке похож на тестирование обычного сайта: проверьте API и сохранение данных в сайте, написанном ИИ-агентом.
Для первой версии достаточно ручной проверки сценариев и журнала вызовов. В журнале полезно видеть название инструмента, параметры, результат и причину отказа. Не записывайте туда больше данных, чем нужно для диагностики. Если агент действует через несколько сервисов, проверяйте всю цепочку: ошибка может возникнуть не в модели, а при передаче параметра или ответе API.
Какие ошибки чаще всего пропускают?
- Сразу открывают запись и удаление. Сначала запустите чтение и подготовку черновиков; изменения подключайте отдельно.
- Считают описание инструмента защитой. Правила в инструкции помогают агенту, но ограничения доступа должны действовать и на стороне самого инструмента.
- Проверяют только удачный запрос. Добавьте неверные данные, неполный запрос и недоступность сервера.
- Не проверяют, что именно изменилось. Сверяйте состояние тестовой записи до и после вызова.
- Разрешают агенту додумывать результат. Если инструмент не вернул подтверждение, агент должен сказать, что действие не удалось проверить.
Публикуйте агент с минимальными правами и постепенно расширяйте их по результатам тестов. Для первого запуска выберите одну задачу, например поиск ответа или просмотр статуса, отключите изменение данных и проверьте сценарии на тестовом сайте. Это даст конкретную отправную точку: будет видно, какие инструменты действительно нужны и где требуется подтверждение сотрудника.
