WebMCP, MCP на рівні сервісу чи звичайне використання браузера: де мають місце інструменти агента

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

Ці два запитання визначають основу для нижчого аналізу.

Що таке WebMCP

За допомогою WebMCP сайт реєструє структуровані інструменти, які сумісний агент може викликати через браузер. Кожен інструмент вказує, що він робить, які дані приймає та який код його виконує. Реєстрація відбувається за допомогою JavaScript або через форми HTML із примітками. Chrome описує цю ідею як пропонований стандарт, тестування починається з версії Chrome 149, і API може змінитися.

Уявіть сторінку пошуку рейсів. Без WebMCP агент читає сторінку, знаходить поле з пунктом призначення, встановлює дати та натискає «Пошук». За допомогою WebMCP сайт може опублікувати інструмент search_flights, який приймає пункт призначення та дати. Агент лише вводить аргументи, а програма виконує пошук.

Слід зберігати три окремі шляхи використання: MCP на рівні сервісу, WebMCP та загальне використання в браузері. Ніщо не змушує обирати один із них, і один агент може викликати інструмент сервісу для одного продукту, інструмент сторінки для іншого та безпосередньо керувати браузером для третього.

Архітектурні проблеми

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

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

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

Більш детальний аналіз послаблює деякі з цих початкових припущень.

• Браузер зберігає поточний стан. У редакторі може бути незбережений чернеток, активний вибір або локальні операції, які не мають відповідника на сервері, а називання клієнта порожньою оболонкою ігнорує все це.
• Логіку не обов’язково дублювати. Інструмент може викликати ту саму функцію клієнта, що й кнопка, і через неї — той самий кінцевий пункт сервера. Справжньою проблемою є додатковий контракт інструменту з власним життєвим циклом та те, як з часом навколо нього можуть накопичуватися бізнес-правила.

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

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

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

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

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

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

Коли агент натискає елемент керування на входженому у систему сайті, додаток надсилає свій запит у межах існуючої сесії, і інструмент WebMCP, який запускається безпосередньо, може використовувати ту саму сесію. Жодному з них не потрібен окремий дозвіл, наданий між хостом агента та сервісом.

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

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

Як CIMD зменшує розрив

Рівень доступу на рівні сервісу також покращується. Документи метаданих ідентифікатора клієнта (CIMD) вирішують одну з проблем OAuth: як абсолютно новий клієнт ідентифікує себе перед сервером авторизації, який ніколи раніше з ним не стикався. Клієнт використовує URL у форматі HTTPS як свій ідентифікатор, і цей URL передає документ метаданих, у якому перелічені такі елементи, як дозволені URI для перенаправлення. Сервер-підтримка завантажує та перевіряє цей документ, що усуває необхідність попередньої реєстрації кожної пари клієнт-сервер. Специфікація авторизації MCP від листопада 2025 року рекомендує підтримку CIMD та віддає їй пріоритет перед динамічною реєстрацією клієнтів у випадках, коли немає деталей про попередньо зареєстрованих клієнтів.

У випадку з п’ятьма сервісами підтримка CIMD на всіх п’яти серверах автентифікації усуває необхідність попередньої реєстрації. Вимоги до автентифікації та цикли життя токенів для кожного сервісу залишаються незмінними, хоча наявні дозволи чи сеанси можуть зменшити кількість запитів, тому не обов’язково буде потрібно п’ять нових входів. Самі рішення щодо автентифікації не змінюються під впливом CIMD.

Контекст, цикл життя та відкриття інформації

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

Проблема полягає у тому, що локальний стан прив’язує інструменти до сторінки. Після того, як користувач виходить чи закриває її, агенту може знадобитися спочатку знову відкрити додаток та відновити контекст. Сеанс входу може залишатися активним навіть після закриття сторінки, а зникає незбережений стан чи інструменти, які там знаходилися.

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

SEP-2127 під назвою MCP Server Cards пропонує стандартний спосіб публікації структурованих метаданих сервера через HTTP, щоб клієнти могли знайти інтерфейси послуг перед встановленням з’єднання MCP та без необхідності керування сторінкою для користувачів. Це перспективний напрямок. На момент написання цього тексту запит на внесення змін все ще є відкритим, тож це лише пропозиція щодо існуючої прогалини, а не прийняте рішення, яке можна було б застосовувати всюди.

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

Браузерні агенти вже працюють без цього

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

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

1 textbox “Destination”, value: “Tokyo”
2 button “Search flights”, enabled

З цього агент може визначити поле призначення, натиснути кнопку «Шукати рейси» та перевірити оновлений статус. Семантика HTML та етикетки доступності вже несуть значну частину значення інтерфейсу. Те, який вигляд сторінки отримує модель, залежить від інтеграції, а не від назви моделі, а документація OpenAI щодо використання комп’ютера демонструє приклади інтеграцій, де скріншоти надсилаються до моделі, а дії повертаються через інструменти, надані додатком.

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

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

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

Яке це дає результат

Вихідні положення, які випливають з усього цього, є наступними:

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

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

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

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