WebMCP a gyakorlatban: ügynökökkel használható webhely deklarált eszközökkel

A WebMCP egy javasolt webstandard, amellyel egy oldal saját eszközeit deklarálhatja a böngészőben futó MI-ügynökök számára, ahelyett, hogy hagyná őket a DOM-ot olvasni és kitalálni, mire való egy gomb. A Chrome 149-től origin trialként szállítja, a Google pedig 2026. május 19-én bejelentette az I/O-n. 2026 szeptemberéig ez Intent to Experiment a W3C Web Machine Learning Community Groupban, nem Recommendation, ezért az alábbi részleteknél feltüntetjük, melyik Chrome-verzióval ellenőriztük őket.

Ez a cikk végigmegy mindkét WebMCP API-n a kódban: a deklaratív attribútumokon, amelyeket egy űrlapra teszel, az imperatív document.modelContext.registerTool() híváson, az eszköz-annotációkon, a két előfeltételen, amelyen az egész átmegy (origin isolation és a tools Permissions Policy), a helyi tesztelésen és egy ellenőrzőlistán. A kidolgozott példa az ezen az oldalon futó plugin, amely három oldaleszközt regisztrál: get_page_content, get_contact_details és open_page.

Mi az a WebMCP?

A WebMCP lehetővé teszi, hogy egy weblap névvel ellátott eszközöket regisztráljon, mindegyikhez egy JSON-sémával a bemenetre és egy függvénnyel, amelyet a böngésző meghívhat. Az ugyanabban a böngészőben futó ügynök látja az eszközlistát, eldönti, melyik eszköz illik a felhasználó feladatához, kitölti a bemenetet, és elolvassa az eredményt. Amit így nyer, azt három dologként írja le a Chrome dokumentációja: discovery (a checkout vagy a filter_results jellegű eszközök regisztrálásának szabványos módja), JSON-sémák a bemenetekre, és state, hogy az ügynök tudja, mit kínál az aktuális oldal.

A deployment modellje számít. Ezeket az eszközöket az oldal regisztrálja, és az oldal futtatja, azon az originen. Ez más, mint egy MCP szerver, amelyet az ügynök a hálózaton keresztül ér el, és amely a saját backendben él. A tervet a webmachinelearning/webmcp magyarázata vitatja ki, a ChromeStatus-bejegyzés pedig mutatja, hol tart az implementáció. A Google I/O-bejegyzése szerint a Gemini a Chrome-ban „soon" támogatná a WebMCP API-kat, és egy falnyi fogyasztói márkát mutatott, amely ezzel dolgozik, köztük az Expediát, a Booking.comot, a Shopifyt, az Etsy-t és a Targetet.

Miért a scraping rossz interfész az ügynökök számára

Az, ahogyan egy ügynök alapértelmezés szerint használ egy weboldalt, azt a Chrome dokumentációja actuation-nek nevezi: „the act of an agent simulating manual mouse clicks and text input, as though it were the human user engaging with your website". Ez a legrosszabb interfész, amit odaadhatsz, mert minden lépés értelmezés, amit az ügynöknek magának kell kitalálnia. Az osztálynevek váltakoznak, egy felirat ott azt írja, „Continue", ahol „pay" értendő, és egy hatszálas űrlapnak hat esélye van eltalálni rosszul.

A deklarált eszközök kiveszik a találgatást. Az ügynöknek nem kell kitalálnia, hogy a „Find flights" feliratú gomb egy keresőűrlapot küld el; ezt te mondtad el neki egy olyan sémában, amelyet el tud olvasni. A dokumentáció egy második pontot is tesz, amelyet könnyű átugratni: az eszközök „execute on your webpage visibly, so users gain trust that tasks are completed as expected", így a márkád és az emberközpontú designod megmarad, és nem cserélődik le egy olyan szkripttel, amely egy megszabdított checkouton kattal végig.

A WebMCP nem helyettesíti azt sem, hogy olvashatóvá ted a tartalmadat. A dokumentáció maga sorolja az első korlátját: „Clients and browsers must visit a site directly to know if it has callable tools." Az az ügynök, amely soha nem tölti be az oldalad, továbbra is Markdown-másolatot, llms.txt-et vagy egy egyszerű API-t igényel, erről szól az llms.txt vagy Accept: text/markdown cikk. Az eszközök azt a részt fedik le, amit egy statikus dokumentum nem tud: az akciókat, a state-et és a felhasználó aktuális oldalát.

Hogyan működik a deklaratív API?

A deklaratív API-hoz nem kell JavaScript. Attribútumokat teszel egy szokásos HTML <form> elemre, és a böngésző eszközt vezet le belőle. Két attribútum kötelező az űrlapon: toolname és tooldescription. Vedd le az egyiket, és az eszköz nincs regisztrálva.

<form toolname="searchFlights"
      tooldescription="Search available flights between two airports for a date range."
      action="/flights">

  <label for="from">Departure airport</label>
  <input id="from" name="from" required>

  <label for="to">Arrival airport</label>
  <input id="to" name="to" required>

  <select name="cabin"
    toolparamdescription="Cabin class; economy is the default.">
    <option value="economy">Economy</option>
    <option value="premium_economy">Premium economy</option>
    <option value="business">Business</option>
  </select>

  <button type="submit">Search</button>
</form>

Az űrlapmezők eszközparaméterekké válnak. Egy <select> enum lesz, és minden <option> szövege a generált sémában az adott érték címe lesz, így az ügynök tudja, hogy egy választás „Return my purchase" vagy „Where is my package" jelent; a bemeneten lévő required a séma required tömbjébe kerül. Használj toolparamdescription-t, valahányszor a mező neve önmagában nem elég. Nélküle a böngésző az adott <label> szövegére esik vissza, majd az aria-description-re, ami sovány leírás egy olyan ügynöknek, amely sosem látta az oldalad.

Az, hogy beküld-e, a te döntésed. toolautosubmit nélkül az ügynök kitölti a mezőket, fókuszba hozza az űrlapot, és a Submit gombot az emberre hagyja. toolautosubmit-tel az ügynök is beküld, és az oldal navigál. Mindkét esetben látható marad az űrlap, amíg az ügynök dolgozik, és két ablak-esemény mondja meg, mi történt: a toolactivated akkor tüzel, amikor a mezők előtöltenek, a toolcancel akkor, amikor a felhasználó megszakítja vagy az űrlapot visszaállítják. Egyik sem szakítható meg, és toolName-et hordoznak.

Ha mégis eredményt akarsz vissza, használd a respondWith()-et a submit eseményen. A SubmitEvent egy agentInvoked boolean értéket kap, amely jelzi, hogy ügynök váltotta ki a beküldést, így ugyanaz a handler másként viselkedhet egy emberrel. Előbb preventDefault()-et kell hívnod, és az átadott promise leserializálva, az eszköz kimeneteként tér vissza a modellnek.

form.addEventListener('submit', (event) => {
  event.preventDefault()
  if (event.agentInvoked) event.respondWith(runSearch())   // resolves to the tool output
})

Hogyan működik a document.modelContext.registerTool()?

Az imperatív API egyetlen hívás: átadsz egy eszközobjektumot name-mel, description-nel, JSON-sémában megadott inputSchema-val és egy aszinkron execute függvénnyel, és a böngésző hívhatóvá teszi. Ez az ezen az oldalon futó plugin, levágva. A target() a page nevét és a nyelvet egy útvonalra, valamint az útvonal Markdown-másolatára oldja.

const pageInput = {
  type: 'object',
  properties: {
    page: { type: 'string', enum: Object.keys(PAGES), description: 'home, about, references, blog, game …' },
    language: { type: 'string', enum: ['en', 'de', 'hu'], description: 'en, de or hu. Defaults to the shown language.' },
  },
  required: ['page'],
}

await document.modelContext.registerTool({
  name: 'get_page_content',
  description: 'Returns the full text of a page of this site as Markdown.',
  inputSchema: pageInput,
  annotations: { readOnlyHint: true },
  async execute(input) {
    const response = await fetch(target(input).markdown, { headers: { accept: 'text/markdown' } })
    if (!response.ok) throw new Error(`Could not load the page (${response.status}).`)
    return { content: [{ type: 'text', text: await response.text() }] }
  },
})

Három részlet teszi ebből eszközt, nem pedig csak egy fetch wrappert. Először az eszköz Markdownot ad vissza, nem HTML-t: az oldal .md másolatát kéri Accept: text/markdown fejléccel, így az ügynök néhány kilobájt tiszta szöveget kap egy script-dús dokumentum helyett. Másodszor a sémában lévő enum nem engedi, hogy az ügynök kitalálja az oldalneveket, a description pedig megmondja neki, mire való mindegyik. Harmadszor az open_page ezen az oldalon a Nuxt routert használja, nem a navigateTo-t, mert az eszközök jóval a setup után, a Nuxt kontextuson kívül futnak.

Az eszközök visszaolvasása szimmetrikus. A document.modelContext.getTools() betűrendben listázza, mit láthat a hívó dokumentum, az executeTool(tool, input) pedig lefuttat egyet, és null-t ad vissza, ha az eszköz eredmény helyett navigációt váltott ki. Egy toolchange esemény a document.modelContext-en azt jelzi egy frame-nek, hogy a lista megmozdult. Az eszközöket AbortSignal-lel lehet leiratkoztatni, és Chrome 153-tól a leiratkoztatás nem töri meg a már futó végrehajtásokat. Az execute második argumentumként megkapja ezt a jelet, ezért add tovább minden fetch-nek, amelyet indít.

Az execute belsejében egy egyszerű hurok fut egy modellhívás körül, ugyanaz a hurok, amelyet egy szerveroldali ügynök futtatna, csak itt az állapot a DOM. Ezt az ügynökhurok magyarázata írja le.

Mit mondanak az ügynöknek az eszköz-annotációk?

Az annotációk opcionális boolean értékek az eszköz annotations objektumában. Mindegyik alapértelmezetten false, ezek tanácsoló jelek, nem biztonsági határ, és azért léteznek, hogy az ügynök a hívás előtt eldönthesse, mit tegyen.

Az ezen az oldalon futó plugin a két, szöveget visszaadó eszközön readOnlyHint: true értéket állít, az open_page-en pedig nem, mert a navigálás állapotváltozás, még ha nem is pusztít el semmit. Ezt a mércét tartanám: annotálj őszintén, mert a hibás readOnlyHint olyan hazugság, amelyre az ügynök reagál, és a következményes eszköz annotáció nélkül olyan vásárlás, amelyet az ügynök megkérdezés nélkül végbevihet. Mindent, ami a felhasználóid által írt tartalmat renderel, untrustedContentHint-et viseljen; hogy ez miért biztonsági döntés és nem címke, azt a prompt injection mint architekturális probléma cikk tárgyalja.

Milyen biztonsági előfeltételei vannak a WebMCP-nek?

Két, és a böngésző mindkettőt ellenőrzi, mielőtt a kódod fut. Az első az origin isolation: a WebMCP csak origin-isolált dokumentumokban érhető el, hogy a dokumentum originje a tool élettartama alatt stabil maradjon. Ha a document.domain engedélyezett, például mert egy válasz Origin-Agent-Cluster: ?0 fejlécet küld, a WebMCP API-k le vannak tiltva. Nézd meg a saját headereidet, mielőtt egy délutánt pazarolsz egy eszközzel, amely sosem regisztrálódik.

A második a toolsPermissions Policy, amelynek alapértéke self. A legfelső szintű és azonos originű dokumentumok regisztrálhatnak eszközöket, a kereszt-origin iframe-ek nem, kivéve, ha a beágyazó oldal hozzáadja az allow="tools" attribútumot. A regisztrálás ráadásul külön van szabályozva, mint a láthatóság: egy eszköznek az exposedTo listában kell szerepelnie, hogy kereszt-origin látható legyen, és a hívónak még getTools({ fromOrigins }) paraméterrel is kérnie kell.

A többi a te saját designod. A következményes akciókhoz ember kell, és az API két utat ad, hogy hozzájuss: a deklaratív utat, ahol az űrlap látható marad, és a Submit gomb a felhasználónál marad, valamint a consequentialHint-et, amellyel a böngésző megerősítést követelhet. A saját szabályom, és amit a kódot író ügynökökre is alkalmazok, itt is ugyanaz: az eszköz előkészíti, az ember végrehajtja. Semmi, ami pénzt költ, üzenetet küld vagy nem vonható vissza, ne fejeződjön be egy modell egyetlen szavára.

Hogyan tesztelhető a WebMCP lokálisan?

Egy flaggel. A dokumentáció lokális beállítása a chrome://flags/#enable-webmcp-testing: állítsd Enabledre, indítsd újra, és az API-k a gépeden elérhetők regisztráció nélkül. A valódi felhasználók gépén való teszteléshez vegyél részt az origin trialban; a Chrome csapata időben korlátozott, használati limitekkel járó early accessnek nevezi, és ez az ára annak, hogy egy kísérletet éles forgalomra küldesz.

Ellenőrzéshez telepítsd a Model Context Tool Inspector kiterjesztést. Megmutatja, mely eszközöket regisztrált egy oldal, kézzel meghívja őket, ellenőrzi, hogy a böngésző tudja-e parszolni a bemeneti sémádat, és megmutatja a strukturált kimenetet vagy a hibaüzenetet – a legtöbb sémahiba itt válik nyilvánvalóvá. Ez más dolog, mint a Gemini a Chrome-ban.

Ismerd a korlátokat, mielőtt elköteleződsz. A dokumentáció szerint az API „primarily designed for local browser workflows with a human in the loop", tehát a headless futtatások nem célpontok. Az összetett interfészöket előbb refaktorálni kell, vagy extra JavaScript kell hozzá, mielőtt az állapotuk kikerülhet. A felfedezhetőséghez látogatás kell. És érvényes a dokumentáció saját státuszsora is: a WebMCP „is under active discussion and subject to change in the future". A keretrendszerek pótolnak: az Angularnak kísérleti támogatása van, a Reactnek pedig `usewebmcp` csomagja.

Innen adódik a kérdés: mikor érdemes várni? Ha az ügynökeid vásárlóügynökök, nem böngészőügynökök, akkor a szerveroldali protokollok messzebb jutottak, és ezt az UCP, ACP, AP2 és WebMCP összehasonlítása végigmegy. A WebMCP akkor érdemli ki a helyét, ha az, amit az ügynökkel szeretnél, az oldal, amelyen épp vagy.

WebMCP-ellenőrzőlista

1. Döntsd el, kell-e egyáltalán eszköz. Ha az ügynöknek csak olvasnia kell, az oldal Markdown-másolata olcsóbb, és böngésző nélkül is működik.
2. Előbb szerezz hozzáférést: a lokális Chrome flag fejlesztéshez, az origin trial valódi felhasználókhoz.
3. Egyszerű űrlapokhoz attribútumokat, minden máshoz registerTool()-t. Csak az imperatív API tud elérni az alkalmazásállapothoz.
4. Írd le minden paramétert toolparamdescription-nel vagy egy valódi <label>-lel, és az enumokat preferáld a szabad szöveges bemenetnek.
5. Gondosan döntsd el a beküldést. Hagyd a Submitot az embernél, vagy adj toolautosubmit-et, és respondWith()-tel adj vissza eredményt.
6. Annotálj őszintén: readOnlyHint csak akkor, ha semmi sem változik, untrustedContentHint felhasználói tartalomra, consequentialHint minden visszafordíthatatlan műveletre.
7. Nézd meg a headereidet. Tartsd meg az origin isolation feltételét, és tartsd szem előtt, hogy az tools policy az iframe-ek kapuja.
8. Tartsd az embert a hurkon belül pénz, üzenetek és törlések esetén. Előkészítés, aztán kérdés.
9. Feature detectiontel vizsgáld az API-t, és tűrj el az átnevezéseket, hogy egy böngésző, amely eldobja, ne okozzon kárt.

Ha ezt egy alkalmazásba építed, nem egy marketingoldalba, ugyanez a munka jelenik meg a Vue.js és Nuxt fejlesztés területén.

Források

1. Chrome for Developers: WebMCP (első lépések)
2. Chrome for Developers: WebMCP Imperative API
3. Chrome for Developers: WebMCP Declarative API
4. Chrome for Developers: Join the WebMCP origin trial (2026. június 9.)
5. Chrome for Developers: 15 updates from Google I/O 2026 (2026. május 19.)
6. WebMCP magyarázat: webmachinelearning/webmcp
7. ChromeStatus: a WebMCP feature bejegyzése