Рекомендации по использованию WebMCP

Alexandra Klepper

Опубликовано: 18 мая 2026 г.

Описание инструмента WebMCP должно быть понятным, чтобы разработчикам или агентам не приходилось просматривать результаты и повторять попытку. Независимо от того, используете ли вы императивный или декларативный API, следуйте этим рекомендациям:

• Прежде чем приступать к разработке, создайте стратегию использования инструментария.
• Используйте понятный язык и семантический HTML.
• Разработайте свои схемы и обрабатывайте входные данные.
• Создавайте надежные инструменты.
• Тестирование и отладка.

Разработайте стратегию использования инструментов.

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

• Каждый инструмент должен выполнять одну единственную функцию . Например, один инструмент может направлять пользователя к определенному типу формы, а другой — сопоставлять поля ввода с информацией о пользователе. Следует избегать создания дублирующих инструментов, так как это может сбить с толку оператора, не понимая, какой из них использовать. Задайте себе вопрос: могу ли я выполнить несколько задач с помощью одной и той же функции?
• Управление регистрацией инструментов . Регистрируйте инструменты, когда они полезны на определенном этапе развития страницы, и отменяйте регистрацию, когда инструмент перестает быть полезным.
  • Императивный API : Вы можете динамически управлять регистрацией с помощью registerTool .
  • Декларативный API : Вы можете динамически управлять регистрацией, добавляя или удаляя атрибуты инструмента в форме, включая toolname и tooldescription .
• Уменьшите сложность: для большинства приложений статическая регистрация должна быть подходом по умолчанию.
• Доверьтесь агенту в выполнении задачи . Вместо того чтобы писать жесткие или негативные инструкции, исходите из того, что агент способен понять, что требуется для выполнения задачи, а не ожидайте от него точной последовательности действий.

Хотя максимальное количество инструментов не ограничено, каждый инструмент занимает часть контекстного окна и увеличивает время выполнения. Чем больше инструментов вы предоставляете и чем больше они перекрываются, тем сложнее агенту сделать правильный выбор. Экспериментируйте, чтобы определить, что подходит именно для вашего приложения.

Это помогает создавать отдельные инструменты, не дублирующие друг друга по назначению, и управлять доступностью этих инструментов.

Используйте понятный язык и семантический код.

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

При написании названий инструментов различайте выполнение и инициирование, используя глаголы, точно описывающие происходящее. Например, create-event — это инструмент для немедленного создания события, а start-event-creation-process — это инструмент, который перенаправляет пользователя на форму для создания события.

Четкое описание должно объяснять, что делает инструмент и когда его использовать. Следует использовать позитивные формулировки и формулировки предпочтений, а не негативные, например, ограничения.

Минимизация когнитивных вычислений

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

• Принимайте необработанный ввод пользователя . Избегайте запросов к агенту на выполнение математических операций или преобразование входных строк. Например, если пользователь говорит: «с 11:00 до 15:00», инструмент должен принять это как строку. Избегайте запросов к модели на вычисление минут между этими временными интервалами.
• Укажите конкретные типы для параметров , например, строка, число или перечисление.
• Объясните, почему вы сделали тот или иной выбор . Ваш выбор должен быть понятен сам собой. Объяснение «почему» помогает агентам принимать более взвешенные решения. Например, если у вас интернет-магазин, указывайте тип доставки на естественном языке, а не используйте неоднозначный идентификатор: shipping="Express" вместо shipping_id=1 .

Приоритет — надежность.

И агенты, и люди получают выгоду от инструментов, которые работают так, как ожидается:

• Установите корректный механизм обработки ошибок при превышении лимита запросов . Инструменты должны допускать разумное количество повторений, например, при сравнении цен. Если инструмент ограничен по количеству запросов, возвращайте информативное сообщение об ошибке или посоветуйте пользователю выполнить задачу вручную.
• Обновите состояние интерфейса после завершения функций . Агенты могут полагаться на интерфейс для планирования следующих шагов, в то время как выполнение функций может занять больше времени, чем загрузка интерфейса. Агент должен подтвердить завершение функции после обновления интерфейса или запросить повторное обновление.
• Строго проверяйте код, не слишком строго — схему . Ограничения и тестирование следует использовать для функций и кода с бинарной логикой. Хотя ограничения схемы могут быть полезны, они не гарантируют корректность. Добавьте в код функции описательные ошибки, чтобы модель могла самостоятельно исправить ошибки и повторить попытку с новыми, допустимыми параметрами.

Оценка, тестирование и отладка.

Создавайте оценочные тесты и предоставляйте свои инструменты для отладки. В отличие от детерминированных модульных тестов, оценочные тесты нельзя задавать жестко, поскольку выходные данные могут принимать непредвиденные формы.

• Определите проблему . Вы можете сформулировать свою проблему в виде контракта API, указав тип входных данных, формат выходных данных и любые дополнительные ограничения.
• Определите базовый и идеальный результат . Особенно при работе с текстовым вводом важно понимать, какие типы результатов могут дать вам ожидаемый результат.
• Определите, как будет оцениваться результат . Вероятно, вы определяете и измеряете субъективные, качественные результаты, основанные на качестве входных данных, их полезности и возможности выполнения следующей задачи. Существует ряд методов, которые можно использовать для оценки результата, включая проверку на основе кода для результатов, основанных на правилах (ограничения по количеству символов), и оценку LLM как судьи .

Избегайте добавления узконаправленных правил для исправления проблем с конкретной моделью. Например, если вы добавите поле выбора для обращений , модель может сделать неправильный выбор. Вместо добавления узконаправленных правил для исправления этой проблемы, абстрагируйте и адаптируйте свой инструмент. Лучше всего сделать это поле необязательным. Затем попросите агента спросить пользователя, какой вариант выбора имеет смысл, чтобы убедиться, что пользователь доволен результатом.

Принимайте участие и делитесь отзывами.

WebMCP находится в стадии активного обсуждения и может быть изменен в будущем. Если вы попробуете эти API и у вас появятся отзывы, мы будем рады их услышать.

• Ознакомьтесь с пояснениями к WebMCP , задавайте вопросы и участвуйте в обсуждении.
• Проверьте реализацию для Chrome в разделе «Статус Chrome» .
• Присоединяйтесь к программе раннего ознакомления , чтобы первыми увидеть новые API и получить доступ к нашей почтовой рассылке.
• Если у вас есть замечания по реализации в Chrome, создайте сообщение об ошибке в Chromium .