WebMCP, MCP на ўзроўні сэрвісу ці звычайны браўзер: дзе месца інструментам агентаў
Крытычны погляд на WebMCP: інструменты старонкі супраць MCP на ўзроўні сэрвісу і звычайных браўзерных агентаў — сесіі, OAuth CIMD, выяўленне, лакальны стан і ўласнасць.
Крыніцы: WebMCP: My Architectural Uneasiness and Where I Think It May Fit
На першы погляд WebMCP здаецца разумным рашэннем. Пользоватальнік ужо заўважаны, агент працуе ўнутрь браузера, а сайт можа паказаць, якія дзеянні існуюць, таму агенту не трэба здогадвацца, якія ўпрацоўваць полья і кнопкі. Неудобства выступаюць у тым, дзе розташоўваецца гэты інтэрфейс. Калі вітрачаюцца зусілля на тое, каб прыстройства моглі выкарыстоўваць дапытку, чы не трэба, каб можлівасці былі адкрываны праз саму сторунку чы праз службы, якія знаходзяцца пад яю? І што дадае інтэрфейс інструмента на рэвэлі сторункі да загальных інструментаў браузера?
Гэтыя два пытанні станавяць аднойчыну для ніжэйшага аналізу.
Што такое WebMCP
За дапамою WebMCP сайт рэгіструе структураваныя інструменты, якія сумесны агент можа вызваць праз прыгледач. Кожны інструмент паказвае, што ён робіць, якія даныя прыймае і які код яго запускае. Рэгістрацыя выконвалася ў JavaScript або праз анкатаваныя формы HTML. Chrome задокументаваў гэю ідэю як прапанованы стандарт, пробны перыяд якога пачынаецца з Chrome 149, і API можа змяніцца.
Уявіце сторанку для пошуку рэйсаў. Без WebMCP агент чытае сторанку, знаходзіць поле з пунктом прызначэння, задае даты і нажымае «Пашук». За дапамою WebMCP сайт можа опублікаваць інструмент search_flights, які прыймае пункт прызначэння і даты. Агент толькі запоўнюе параметры, а прыгледач выкананае пошук.
Тры разлічныя сцэны выкарыстоўвання трэба заліць аддзельнымі: MCP на рэжыме абслугоў, WebMCP і звычны выкарыстоўкі браузера. Нічога не прымусвае выбіраць адну з іх, і адны агент можа вызваць інструмент абслугоў для аднаго продукту, інструмент стораніцы для іншага, а таксама безпасэродзейна кераваць браузерам для трэцьяго.
Архітэктурныя проблемы
Першая рэакція — што WebMCP пераносіць пытанні абслугоў у шар прэзэнтавання. Пошук запасоў, зміна бронівкі чы адправка замовленняў у тыповай бізнес-зялёзе завершваецца на бэкенд-абслузе, а браузер ужо вызывае канец-пункт, які выканае цю задачу. Тады чаму не візначыць кантракт, прызначаны для агента, ў самай стораніцы, а не побач з тай абслугою?
Натуральная альтэратыва выклікаецца з існуючага кантракту на абслугіванне, такога як спецыфікацыя OpenAPI або вялічынка gRPC, і на яе аднойчы будуецца інтэрфейс MCP. Адзін з прыемнаў — гэта правае власніцтва. Команда, якая адпавядае за аператыўную частку, можа ствараць версіі, тэставаць і кантролаваць кантракт, назначаны для агентаў, а інтэрактывныя агенты, пакетныя заданні і запланаваныя рабочыя праграмы могу ўсе яны выкарыстоўваць.
Закаменаванне внутранняга канцэнтрау у інструменце для стварэння стораніц таксама не робіць кантракт менш абавязковым. Агенты отрымаюць операцыю з прынятнымі вхіднымі дадзеннямі і спосабамі дзеяння, а рабочыя праграмы перастаюць працаваць, калі гэты спосаб дзеяння змініцца. Як толькі інструмент стане доступным, команда павінна вырашыць, якую сумяжнасць і падтрымку ён обяцвае, і размешчэнне інтэрфейсу на веб-рэверсе сама па сабе не зменшае гэтыя абавязкі.
Болей дакладны анаіз слабяе дзеякія з гэтых пачатковых прыпускаў.
- Браузер зберагае стан працы. У рэдагары можа быць незявічаны праект, актуальны выбір або локальныя операцыі, якія не мают адпаведнага адпаведніка на серверы, і калі вважаць кліента простаю шчылкой, то гэта ігнаруе все гэта.
- Логіку не трэба дублюваць. Інструмент можа вызваць тую ж самую функцыю кліента, як і кнопка, і праз яе — той жа самы серверны канцэнтры. Асалівая проблема — гэта додатковы контракт інструмента з сваім сопным цыклам жыцця, а таксама тое, як з часам навакола яго можа накаплівацца велікія колькасць бізнес-правіл.
Зрэласць таксама мае значэнне. Адзінакова эксперыментацыя ўскладнюе справу, але інтэрфейс, створаны на аднойчына змінюючымся API прыгледача, дадае ўтроху ўскладненняў у тым, каб яго падтрымваць.
Тады болей правільны падход — гэта, што стойкую бізнес-операцыю лепш кераваць безпосерэдна ў месцы, дзе яе рэалізуеяць сервіс, і для таго, каб размістыць яе кантракт на сторанцы, патрэбны конкрэтныя прычыны.
Павторны выкарыстоўванне сесій проты дэлегавання доступу
Прыямыя перавагі аўтэнтыфікацыі выклікаюцца работай у прыгледачы, у яком ўжо ёсць адпаведныы прынт, і WebMCP, як і звычны прыгледач, апытваецца ўжыць гэтыя перавагі. Порэванне тут паказвае гэю зручнасць проты доступу да сервіса па дэлегаванні. Якія конкрэтныя інструменты WebMCP дадаюць дадатковых перавагаў пры взаімадзеі з прыгледачам, — гэта аднае пытанне, якое будзе розглянуцца далей.
Калі агент нажымае на элемент керування на сайце, дзе ёсць адмаўкаванне, прыкладненне адправляе свой запіт праз існуючую сесію, і інструмент WebMCP, які запускаецца безпосерэдня, можа выкарыстоўваць тую ж сесію. Ні аднаму з іх не трэба аддзельнага разрэшэння між хостам агента і сервісам.
Цяжар працы зменшаецца за рахунак разных прыкладненняў. Рабочы працэс, які выкарыстоўвае пяць сервісаў, можа запатрабаваць пяць разрэшэнняў, пяць цыклів жыцця токенаў і пяць набораў трэбаванняў да інтэграцыі, плюс працэс рэгістраціі кліента, які залежыць ад кожнага сервіса. Калі корыстнік вялікі час адмаўкаваны на ўсіх пяці сайтах, паўтарна выкарыстоўка тых сесій дапамагае ухіліцца ад вялікай часткі гэтай наладкі.
Называць гэта безкоштовным аўтэнтыфікацыям — значыць перацініць яго. Жывая сесія мае свой саём цыкл безпекі, і тое, што вы заўважаны, не значыць схвалення всьго, што агент можа спробаваць зрабіць. Усё-такі эконамія на працы з інтэграцыяй ёсць рэальная. Проблемы з втрымкай запытоў і небажанымі дзеяннямі не рашаюцца проста выбрам адпаведнага слоя, адколі і адны, і другія шляхі патрабуюць захоўнікаў, такіх як паўтарная паўтарка для значных операцый, з разным рыгорам і апэлірацыяй, таму кожны дызайн павінен самостоятэльна ацэніць гэтыя рызыкі.
Як CIMD скармляе разлік
Рэгламентны доступ таксама стае лепшым. Дакументы метаадзяў ідэнтыфікатора кліента (CIMD) спрыяюць рашэнню аднай з проблем, якія выступаюць пераканаўленнем у процэсе OAuth: як абэцнаваны кліент ідэнтыфікуе ся для сервера автарызацыі, які ніколі з яму не зустрэчаўся. Кліент выкарыстоўвае URL з протакалам HTTPS як свой ідэнтыфікатор, а гэты URL аддае дакумент метаадзяў, у якім пераказаны такія пункты, як дазволеныя адрэсы перыялу. Сервер-падтрымкі запрашае і пераканае гэты дакумент, што пазбавляе неабходнасці зарэўнаваць кожную пару кліента і сервера загадзя. Спецыфікацыя автарызацыі 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 работае наяўнейша, калі супакоюяцца тры элементы: жывая, апраўданая сесія, цінны локальны стан і працэсы працы кліента, якія можна перадаць знову. Звычная праца з браузерам таксама дазволяе перадаць сесію знову, таму застаецца вопыт, якія конкрэтныя інструменты да гэтага спрыяюць. Інструмент сторанкі, які проста перадае операцыю службе, все рава патрэбуе падставы для таго, каб контракт, назначаны для агента, застаўся на сторанцы.