Пояснення WebMCP: надання AI-агентам браузерів інструментів замість припущень

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

Саме так сьогодні працюють більшість агентів, що базуються на браузері. Вони аналізують DOM, визначають призначення кожного елемента за його підписом та розташуванням, а потім імітують кліки та натискання клавіш, які б зробив людина. Цю техніку називають актуацією; вона виглядає чудово на демонстраціях, але в реальних умовах припиняє працювати. Змініть один CSS-клас або перемістіть кнопку — і агент, який ще вчора працював коректно, почне давати проблеми.

WebMCP — це відповідь на цю проблему. Якщо ви знайомі з Model Context Protocol (MCP) на бекенді, ідея проста у формулюванні: взяти концепцію інструментів та перенести її у браузер, щоб вони існували на сторінках, які ви створюєте.

Чому недостатньо лише аналізу DOM

Агенти наразі отримують доступ до сервісу двома способами:

• Інтеграція з бекендом. Сервіс реєструє інструменти в платформі штучного інтелекту через сервер MCP, OpenAPI або якийсь пропрієтарний API, і штучний інтелект взаємодіє безпосередньо з сервером, не торкаючись браузера.
• Активація через браузер. Агент відкриває сторінку, як людина, та визначає, які елементи потрібно натиснути чи заповнити.

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

WebMCP додає третій шлях, який не є ні інтеграцією з бекендом, ні сліпим клацанням. Сам сайт визначає, що він може робити. Замість того, щоб агент здогадувався, що робить кнопка „Оплата“, розробник описує, що саме виконує процес оплати, які дані він потребує та що повертає.

Що таке WebMCP

WebMCP — це запропонований веб-стандарт від Групи спільноти веб-машинного навчання при W3C. Специфікація визначає JavaScript API разом із анотаціями для елементів HTML-форм, щоб агент міг знати, як використовувати функції сторінки, не здогадуючись.

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

Дизайн складається з трьох елементів:

• Відкриття: стандартний спосіб для сторінок реєструвати інструменти, такі як checkout або search_products, у агента.
• JSON Schema: чіткі визначення очікуваних вхідних та вихідних даних, що зменшує хибні уявлення та непорозуміння.
• Стан: спільний огляд поточного контексту сторінки, щоб агент знав, що він може робити прямо зараз.

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

Реєстрація WebMCP на сайті

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

1. Увімкніть середовище. Оскільки стандарт ще лише запропонований, увімкніть його вручну для експериментів. У Chrome відкрийте chrome://flags/#enable-webmcp-testing, встановіть значення на «Enabled» та перезавантажте браузер. Для ситуації, ближчої до продакшну, зареєструйтесь на пробну версію WebMCP origin, яка з’явиться у Chrome 149, щоб справжні відвідувачі могли використовувати цю функцію без змін параметрів браузера.

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

3. Виберіть імперативний або декларативний API. Імперативний API реєструє інструменти за допомогою звичайного JavaScript через функцію registerTool та підходить для складнішої логіки, такої як керування станом, навігація чи послідовне виконання дій. Декларативний API дозволяє розміщувати анотації безпосередньо у стандартному HTML-форматі <form>, і інструмент створюється автоматично, що підходить для простих сценаріїв, заснованих на формах. У проектах React та Angular є вбудовані опції цих фреймворків. React пропонує пакет usewebmcp, чий хук useWebMCP пов’язує життєвий цикл інструменту з моментом його підключення та від’єднання від компонента. Angular має експериментальну підтримку, яка дозволяє перетворювати Signal Forms на інструменти.

4. Зробіть inputSchema детальним. Це визначає, наскільки добре агент розуміє інструмент. Напишіть description простою природною мовою, а не внутрішнім скороченням, та визначте кожну властивість разом із її типом. Для замкнутого набору значень використовуйте enum, щоб агент з меншою ймовірністю надсилав щось недійсне.

5. Встановіть annotations відповідно до реального ризику. Кожен інструмент потребує чесної мітки:

• readOnlyHint: true для інструменту, який лише читає та залишає все незмінним.
• consequentialHint: true для дії з реальними наслідками, яка має спочатку запитати у користувача підтвердження.
• untrustedContentHint: true, коли результат включає контент від інших користувачів, такий як відгуки чи коментарі, які можуть приховувати інструкції.

6. Під’єднайте execute до існуючого кінцевого пункту. Функція execute може просто викликати вже наявний API-шлях за допомогою fetch(). Шлях у Laravel також підходить. Окремого бекенду WebMCP немає. Ви створюєте фронтенд-міст до бізнес-логіки, яка вже перевірена у продакшені.

7. Протестуйте це. Додайте розширення Chrome під назвою Model Context Tool Inspector (Chrome Web Store), завантажте вашу сторінку та подивіться, які інструменти реєструються. Ви також можете зв’язатися з агентом звідти, щоб підтвердити, що ваш інструмент викликається та що його схема читається коректно.

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

Приклад: інструмент для перегляду статусу замовлення

Уявіть інтернет-магазин, створений на Laravel, із сторінкою статусу замовлень. Звичайний процес виглядає так: користувач уходить у систему, відкриває розділ «Мої замовлення», обирає діапазон дат та переглядає список замовлень із інформацією про статус доставки. Агент, який використовує актуацію, мусить знайти відповідний выпадаючий список та кнопку надсилання, а потім обробити таблицю результатів з необробленого HTML, яка руйнується як тільки змінюється формат маркування.

За допомогою WebMCP один інструмент обгортає вже існуючий кінцевий пункт:

await document.modelContext.registerTool({
  name: 'get_order_status',
  description: 'Look up orders within a given timeframe. Returns order number, shipping status, and current location.',
  inputSchema: {
    type: 'object',
    properties: {
      timeframe: {
        type: 'string',
        enum: ['today', 'yesterday', 'last_7_days', 'last_30_days', 'last_6_months'],
        description: 'Timeframe for the order lookup.'
      }
    },
    required: ['timeframe']
  },
  annotations: {
    readOnlyHint: true,
    consequentialHint: false,
    untrustedContentHint: false
  },
  execute: async ({ timeframe }) => {
    const response = await fetch(`/api/orders/status?range=${timeframe}`, {
      headers: { 'Accept': 'application/json' }
    });
    const data = await response.json();
    return JSON.stringify(data);
  }
});

Три аспекти є особливо важливими. inputSchema допомагає агенту уникнути необхідності здогадуватися щодо формату, оскільки він знає, які значення приймає timeframe. Анотація readOnlyHint: true позначає інструмент як такий, що не має побічних ефектів, тому підтвердження не потрібне. А execute просто викликає наявний маршрут Laravel, тож нічого не потрібно перебудовувати.

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

await document.modelContext.registerTool({
  name: 'checkout_cart',
  description: 'Completes checkout for the currently logged-in user\'s cart.',
  inputSchema: {
    type: 'object',
    properties: {
      paymentMethod: { type: 'string', description: 'Payment method selected by the user' }
    },
    required: ['paymentMethod']
  },
  annotations: {
    readOnlyHint: false,
    consequentialHint: true,
    untrustedContentHint: false
  },
  execute: async ({ paymentMethod }) => {
    const response = await fetch('/api/checkout', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ payment_method: paymentMethod })
    });
    return await response.text();
  }
});

З параметром consequentialHint: true браузер або агент знає, що потрібно показати діалогове вікно підтвердження перед виконанням. Навіть якщо агент натисне кнопку, остаточне рішення залишається за користувачем.

Щоб перелічити інструменти, зареєстровані на сторінці:

const tools = await document.modelContext.getTools();
console.log(tools);

Щоб вручну активувати його для тестування:

const [tool] = await document.modelContext.getTools();
const result = await document.modelContext.executeTool(tool, '{"timeframe": "last_7_days"}');

Повний цикл обробки

Ось послідовність дій під час спілкування з агентом, який використовує інструмент get_order_status.

1. Ви пишете агенту, у якого відкрита сторінка магазину, щось на кшталт «знайдіть мої замовлення з минулого тижня» простою мовою.
2. Агент запускає процедуру пошуку, викликаючи функцію getTools() на цій сторінці.
3. Сторінка повертає список своїх інструментів із описами, серед яких є get_order_status з його описом та форматом введення даних.
4. Агент порівнює ваш запит із цими описами. Чіткий опис допомагає йому одразу вибрати правильний інструмент.
5. Агент викликає функцію executeTool() із аргументами, сформованими на основі розмови, наприклад {timeframe: 'last_7_days'}.
6. Функція execute сторінки викликає той самий ендпоїнт Laravel через fetch(), так само, якби ви натиснули кнопку.
7. Бекенд відповідає у форматі JSON, а інструмент передає його назад агенту.
8. Агент сформулює результат мовою природи та відобразить його, при цьому все залишається видимим у інтерфейсі сторінки.

Чому це краще, ніж актуація?

• Це менш залежить від контексту. Агент читає компактну схему, а не тисячі рядків маркування, тому відповіді є швидшими та дешевшими.
• Результати залишаються послідовними. Інструмент викликає вашу справжню функцію, тож зміна кольору кнопки чи переміщення елемента не порушують її роботи.
• Люди залишаються під контролем. Дії з високим ризиком, позначені як consequentialHint: true, все одно потребують підтвердження, тож агент не може їх виконати без запиту.

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

Безпека

Оскільки інструменти знаходяться на ваших сторінках, безпека знаходиться ближче до поверхні, ніж у випадку з backend MCP, який зазвичай працює ізольовано на власному сервері. Специфікація передбачає кілька захисних механізмів:

• Ізоляція походження. WebMCP працює лише в документах з ізольованим походженням. Якщо сторінка увімкнула document.domain, наприклад через заголовок Origin-Agent-Cluster: ?0, WebMCP вимикається.
• Політика дозволів. Реєстрація інструментів контролюється політикою tools, яка за замовчуванням дорівнює self, тож інфрафрейми з іншого походження не можуть реєструвати інструменти, якщо ви не дозволите це за допомогою allow="tools".
• Відкритість для певних джерел. Щоб зробити інструмент доступним з іншого джерела, вкажіть це джерело у параметрі exposedTo. Ніщо не є автоматично відкритим.
• Три підказки щодо анотацій. readOnlyHint, consequentialHint та untrustedContentHint — це не просто мітки. Вони вказують, чи може агент виконувати інструмент без підтвердження, чи слід уважно ставитися до його результатів, оскільки вони містять ненадійний контент, наприклад відгуки користувачів, які можуть містити загрози у вигляді вставки коду.

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

Стан підтримки браузерами

Станом на середину 2026 року все ще на ранній стадії:

• Група спільноти з машинного навчання в мережі W3C офіційно схвалила специфікацію у вересні 2025 року.
• У Chrome з версії 149 є пробний режим для тестування, а повна підтримка у Chrome та Edge планується до другої половини 2026 року.
• Для локальних експериментів прапорець chrome://flags/#enable-webmcp-testing працює без необхідності участі у пробному режимі.
• Розширення Model Context Tool Inspector відображає, які інструменти реєструє сторінка, та дозволяє імітувати розмову з агентом.

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

Текущі обмеження

• Без безголового браузингу. API призначений для локальних робочих процесів браузера з участю людини, а не для автоматизації без нагляду.
• Додаткові витрати на складні інтерфейси. Додаток із складним керуванням станом, ймовірно, потребуватиме рефакторингу, щоб інструменти відображали справжній стан додатку.
• Для пошуку потрібен візит. Клієнти дізнаються про наявність інструментів на сайті лише після відвідування сторінки. Поки що немає глобального індексу, подібного до сіт-мапи, для інструментів.
• Ще немає ресурсів чи підказок. Два інші примітиви з повного MCP ще не потрапили до WebMCP. Якщо агенту потрібно читати документи чи отримувати структуровані дані з інших джерел, все одно потрібен окремий сервер MCP.

З чого почати

WebMCP доповнює backend MCP, але не замінює його. Backend MCP залишається ідеальним для даних та логіки, які мають знаходитися на сервері, тоді як WebMCP підходить для робочого шару фронтенду: складних форм, багатоетапної навігації та дій, пов’язаних із поточним станом інтерфейсу.

Безпечний спосіб початку роботи:

• Увімкніть локальний флаг та зареєструйте один простий інструмент, бажано лише для читання, наприклад для пошуку продуктів.
• Від самого початку правильно використовуйте annotations. Не відкладайте використання readOnlyHint та consequentialHint, адже саме вони є основою безпеки, яка визначає, наскільки можна довіряти агенту у роботі з вашим інструментом.
• Слідкуйте за репозиторієм групи Web Machine Learning Community Group у GitHub, адже обговорення в спільноті постійно впливають на формування специфікації.

WebMCP ще далекий від досконалості, але напрямок зрозумілий. У вебі з’являється чітка мова для взаємодії з агентами, чіткий контракт між розробником та агентом замість припущень щодо DOM. Для тих, хто звик до інструментів та схем з backend MCP, цей перехід здасться знайомим. Тепер контракт знаходиться безпосередньо в браузері.