Пояснення WebMCP: можливість для веб-сайтів публікувати інструменти замість того, щоб агенти клікали по інтерфейсу.

Уявіть собі невеликий побічний проєкт, у якому штучний інтелект має самостійно керувати веб-додатком. Перша версія працює так, як більшість агентів браузера: агент отримує доступ до додатку та вирішує проблеми на основі того, що відображається на сторінці. Для простого додатку типу Todo запит може бути «Додати „Купити яйця“ до мого списку». Щоб це здійснити, агенту потрібно переглянути сторінку, знайти поле введення, визначити, яка кнопка надсилає форму, натиснути її, а потім перевірити результат.

Це працює, але це здається занадто складним. Додаток вже точно знає, що має відбутися. За цією кнопкою знаходиться функція, за цією функцією — API, а сама операція полягає у одному простому виклику:

add_todo(title)

То чому агент має дивитися на інтерфейс та здогадуватися, як щось зробити, коли додаток вже може це описати? Саме тут WebMCP починає мати сенс. Потік операцій виглядає приблизно так:

User request
     ↓
AI agent
     ↓
WebMCP tool
     ↓
Application logic
     ↓
UI updates

Інтерфейс все ще існує для людських відвідувачів. Агенту просто не потрібно його декодувати, щоб виконати дію. Це змінює підхід до всієї проблеми. Питання може полягати не в тому, як зробити ШІ кращим у використанні веб-сайтів, а в тому, як зробити веб-сайти кращими у поясненні ШІ того, що вони можуть робити.

Два способи, якими агенти сьогодні використовують Інтернет, та їхні обмеження

Агент, який потрібно діяти на сайті, наразі має два поширені шляхи.

Перший — це автоматизація браузера. Агент робить скріншоти, визначає, що можна натиснути, переміщує курсор, заповнює поля, натискає, перевіряє, що сталося, і повторює цей процес. Це схоже на спостереження за людиною, яка керує браузером, і має ті самі недоліки: це повільно, це споживає токени, і це легко ламається. Невелика зміна макету, прихований меню, взаємодія лише при наведенні курсору чи додатковий крок у процесі можуть збити агента з курсу.

Другий підхід — це спеціальний сервер MCP, створений під ваше додатку. Для інструментів це значно кращий варіант. Однак є інші витрати, адже агент повинен спочатку знати про існування сервера та під’єднатися до нього. Коли кожен веб-сайт постачає власну інтеграцію, це не дозволяє ефективно масштабуватися. Це практичний ліміт підходу з використанням спеціального сервера MCP.

Це створює прогалину: автоматизація браузера занадто опосередкована, а спеціальні інтеграції — занадто ручні. WebMCP покликаний заповнити цю прогалину.

Що таке WebMCP

Простіше кажучи, WebMCP дозволяє веб-сайту повідомити AI-агенту: «Ось те, що ви можете робити на цій сторінці». Замість того, щоб агент здогадувався, яку кнопку натиснути, сайт надає список дій.

Наприклад, інтернет-магазин може оприлюднити такі інструменти:

search_products()
get_product_details()
add_to_cart()

Агент, який переглядає сайт, сам знаходить інструменти та викликає їх за допомогою структурованих даних, які кожен з них вказує. Не потрібно нічого реєструвати у агенті заздалегідь. Інструменти виявляються динамічно з веб-сайту, і саме це варто зазначити. Сайт перестає бути просто набором сторінок та починає надавати певні функції.

Конкретний приклад: додаток Todo

Візьмемо простий додаток Todo. Без WebMCP агенту довелося б переглядати сторінку, знаходити поле введення, вводити текст, шукати кнопку «Додати», натиснути її та знову читати оновлений інтерфейс.

За допомогою WebMCP додаток може оприлюднити чотири інструменти:

add_todo(title)
list_todos()
toggle_todo(id)
delete_todo(id)

Агент більше не потребує жодних знань про візуальну структуру. Він знає, що може робити додаток. Демонстрація, побудована саме таким чином, показала додаток Todo, який надавав доступ до чотирьох інструментів; підключений агент читав їхні схеми та негайно викликав add_todo. Коли агенту було наказано додати до списку „Мені потрібно купити яйця“, це спричинило виклик відповідного інструменту, і новий елемент з’явився в додатку.

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

Як виглядає визначення інструменту

Тут інженерам фронтенду буде цікаво. Реалізація в тій демонстрації реєструє інструменти через navigator.modelContext. Кожен інструмент складається з кількох елементів:

{
  name: "add_todo",
  description: "Add a todo item",
  inputSchema: {
    // structured inputs
  },
  execute: async (input) => {
    // application logic
  }
}

Структура залишається однаковою: ім’я, опис, схема введення даних та функція-виконавець, яка виконує роботу, зазвичай шляхом виклику API сервера, які вже є у додатку. Цей останній момент має велике значення. WebMCP не вимагає від вас переписувати бізнес-логіку для ШІ. Існуючий додаток залишається системою, яка виконує операцію, а агент лише отримує структурований спосіб її запуску.

Проблема автентифікації

Ситуація стає серйозною, коли додаток більше не є іграшкою. Уявіть собі такі інструменти:

get_profile()
update_profile()
create_order()
cancel_order()
transfer_money()

Невідомий агент не повинен мати можливості вільно викликати ці функції. Друга демонстрація у тому ж матеріалі саме це розглядає за допомогою OAuth. Інструменти WebMCP працюють у межах автентифікованого додатку, тож користувачі, які не увійшли, не можуть виконувати захищені дії.

Це має велике значення, оскільки агенти можуть надходити з різних клієнтів: браузера з підтримкою ШІ, десктопного агента чи іншого додатку-агента. Стандартний механізм на кшталт OAuth значно полегшує захист рівня функціональності у всіх цих випадках, порівняно з необхідністю створювати окремий процес входу для кожної інтеграції. Як тільки сайти розкривають свої можливості для агентів, автентифікація стає частиною їхнього досвіду з самого початку, а не доповненням, доданим пізніше.

Нове питання для дизайну фронтенду

Протягом багатьох років архітектура фронтенду оберталася навколо однієї ланцюгової структури: інтерфейс, стан, API, бекенд. WebMCP додає ще одне питання: які функції має надавати цей додаток агенту?

Це здається дрібницею, але це може змінити спосіб проектування функцій. Кнопка „Додати до кошика“ — це взаємодія з користувачем. Цей виклик є функцією додатку:

add_to_cart(productId, quantity)

Обидва рішення зрештою можуть бути розроблені разом. Користувачі отримують відполірований інтерфейс, а агенти — структурований інтерфейс функціоналу, причому обидва опиняються в межах однієї бізнес-логіки.

Це не лише про швидкість

Існує глибша причина, чому це важливо, ніж просто швидкіші агенти. Коли агент працює за допомогою скріншотів та кліків, сам інтерфейс є угодою, і будь-які зміни в інтерфейсі можуть пошкодити агента. За допомогою WebMCP визначення інструменту стає частиною цієї угоди.

Це вводить у сферу відповідальності розробника фронтенду новий набір аспектів: назви інструментів, описи, схеми вхідних даних, поведінка під час виконання та межі автентифікації. Робота більше не обмежується лише проектуванням екранів; вона починає включати проектування того, як програмне забезпечення представляє себе інтелектуальним системам.

Ще на початковій стадії

Є один момент, який варто підкреслити. WebMCP залишається пропозицією на ранній стадії тестування та не є остаточним веб-стандартом. Демонстрація працювала в Chrome Beta з увімкненим WebMCP через параметри браузера, і ведучий прямо зазначив, що API все ще може змінитися. Створення продакшн-архітектури на його основі зараз було б передчасним. Експериментування з ним — це інша справа, адже ідея, яка стоїть за ним, є ширшою за сучасний API.

Веб-сайти протягом десятиліть будувалися на одному припущенні: з іншого боку знаходиться людина. WebMCP є одним із перших експериментів, які кидають виклик цьому припущенню. Веб-додатки незабаром можуть змушені бути відповісти на два запитання: як людина повинна ним користуватися? І як його має використовувати штучний інтелект? Перше запитання призвело до розвитку сучасної фронтенд-інженерії. Друге, ймовірно, вплине на те, що буде далі.