WebMCP: a weboldalad hamarosan az AI-ügynökök eszköze lesz. Mit kell tudnod róla?

A WebMCP egy friss webes szabványjavaslat, amellyel a weboldalad géppel is érthető eszközként kínálhatja fel a funkcióit a látogatók nevében dolgozó AI-ügynököknek: a foglalási naptár, a termékkereső vagy az ajánlatkérő űrlap ugyanúgy használható lesz egy mesterséges intelligenciának, mint egy embernek, csak éppen találgatás nélkül. A Google a Chrome 149-es verziójától origin trialban teszi kipróbálhatóvá a technológiát, a WordPress Playground szeptember eleje óta 16 beépített műveletet ad az ügynökök kezébe, az OpenAI pedig a ChatGPT asztali alkalmazásának böngészőjében már meg is hívja az oldalak által felkínált eszközöket. A weboldal tehát lassan nemcsak embereket szolgál ki, hanem gépeket is.

Ha egy 5 és 50 fő közötti cég vezetője vagy, joggal kérdezheted, hogy ez most rád tartozik-e, vagy egyelőre maradhat a nagy techcégek kísérleti terepe. A 2026. szeptember 22-i állapot alapján a válasz az, hogy a szabvány még tervezet és a részletei változhatnak, az alapja viszont egy jól megírt HTML-űrlap, amelyet a legtöbb oldalnak amúgy is rendbe kellene tennie. Az alábbiakban végigmegyünk azon, mit tud pontosan a WebMCP, miben különbözik a mai, képernyőt böngésző ügynököktől és a klasszikus MCP-szerverektől, mit jelent egy webshopnak, egy panziónak vagy egy ajánlatkérésből élő szolgáltatónak, mennyi munka a bevezetése, végül azt is, mikor érdemes belefogni és mikor jobb kivárni.

Röviden

• A WebMCP a Microsoft által 2025 augusztusában javasolt, azóta a Google-lel közösen fejlesztett webes szabványtervezet, amellyel a weboldal névvel, leírással és bemeneti sémával ellátott eszközöket kínál fel az AI-ügynököknek, így azoknak nem kell képernyőképekből kitalálniuk, hová kattintsanak.
• Eszközt kétféleképpen lehet deklarálni: meglévő HTML-űrlapokon néhány új attribútummal (toolname, tooldescription, toolparamdescription) vagy JavaScriptben a document.modelContext.registerTool() hívással, amelyről a Chrome 2026. szeptember 11-én frissített dokumentációja maga is jelzi, hogy még változhat.
• 2026. szeptember 22-i állapot szerint a WebMCP a Chrome 149-től origin trialban tesztelhető élesben, a WordPress Playground 16 beépített műveletet ad az ügynököknek, az Angular v22 kísérleti támogatással érkezett, az OpenAI pedig a ChatGPT asztali alkalmazásának böngészőjében „Site tools” néven már meghívja az oldalak eszközeit.
• Egy webshopnak, szállásadónak vagy ajánlatkérésből élő szolgáltatónak a fő nyereség a pontosság, mert a látogató ügynöke nem találgatja az oldal felépítését, hanem egy leírt eszközön keresztül kér terméket, szabad időpontot vagy árajánlatot.
• A kockázat valós, hiszen az eszközök a felhasználó bejelentkezett munkamenetével futnak, ezért rendelésleadást, fizetést vagy adatmódosítást csak emberi megerősítéssel szabad ügynöknek kiadni, a beérkező adatokat pedig a szerveren mindig ellenőrizni kell.
• Saját becslésünk szerint egy rendezett űrlapokkal dolgozó KKV-oldalon a deklaratív WebMCP tesztelésestül 8 és 13 fejlesztői óra közötti munka, így most érdemes az űrlapokat rendbe tenni és kísérletezni, a teljes, JavaScript-alapú eszközkészlettel viszont a legtöbb cég megvárhatja a szabvány véglegesedését.

Mi az a WebMCP és miért nem elég a DOM-kaparás?

A WebMCP (Web Model Context Protocol) olyan javasolt webes szabvány, amellyel a weboldal maga írja le az AI-ügynököknek, milyen műveleteket kínál, milyen adatokat vár hozzájuk és mit ad vissza. A DOM-kaparás ezzel szemben utólagos találgatás: az ügynök a HTML-kódból vagy képernyőképekből próbálja kitalálni, hová kattintson, ami lassú, drága és könnyen félremegy.

Ahhoz, hogy lásd, miért számít ez, érdemes tisztázni, hogyan dolgozik ma egy ügynök. Az AI-ügynök olyan program, amely egy nagy nyelvi modell segítségével önállóan tervez meg és hajt végre több lépést egy cél érdekében: megkeres egy terméket, összehasonlít három ajánlatot, kitölt egy űrlapot vagy lefoglal egy időpontot. Amikor egy weboldalon kell dolgoznia, jelenleg két módszer közül választhat. Az egyik a képernyőalapú számítógép-használat, amelynél a modell képernyőképeket kap, ezeken felismeri a gombokat és a mezőket, majd egérkattintást és billentyűleütést szimulál. A másik a DOM (Document Object Model, vagyis a betöltött oldal fastruktúrája, amelyet a böngésző a HTML-kódból épít fel) közvetlen olvasása és piszkálása, amit a szakma DOM-kaparásnak vagy scrapingnek hív. A Chrome fejlesztői dokumentációja mindkettőt „actuation” néven, azaz a felhasználói mozdulatok utánzásaként írja le.

Mindkét módszer működik, csak éppen nem túl megbízhatóan. Az OpenAI 2026. szeptember 3-án bemutatott GPT-6 Astra modellje a cég állítása szerint jelenleg a legjobb számítógép-használó modell, a gyártó saját mérésén mégis „csak” 72,6%-ot ért el az OSWorld 2.0 nevű, valódi asztali és böngészős feladatokból álló teszten. Ez komoly előrelépés az elődje 65,7%-ához képest, ugyanakkor azt is jelenti, hogy nagyjából minden negyedik feladatnál még a csúcsmodell is elakad vagy hibázik. Minden egyes lépés újabb képernyőképet, újabb értelmezést és újabb modellhívást igényel, ami időbe és tokenbe kerül, a token pedig pénz.

Vegyünk egy képzeletbeli balatoni panziót, amelynek a foglalási oldalán egy látványos, JavaScriptben írt dátumválasztó naptár van, fölötte sütibanner, legalul egy „Ajánlatot kérek” gomb, amelyet a marketinges a múlt héten egy A/B teszt kedvéért „Szabad szobák” feliratra cserélt. Egy ember ezen három másodperc alatt átlát, egy képernyőt értelmező ügynöknek viszont minden elem külön fejtörés: először el kell tüntetnie a bannert, aztán rá kell jönnie, hogy a naptárban a szürke napok foglaltak, a halványzöldek szabadok, végül meg kell találnia az átnevezett gombot. Ha közben a panzió frissíti a sablonját, a tegnap még működő lépéssor ma már elromolhat.

A WebMCP ezt a viszonyt fordítja meg. Nem az ügynöknek kell kitalálnia, mit lehet csinálni az oldalon, hanem az oldal mondja meg neki: „van itt egy szabad_szobak nevű eszköz, amely érkezési és távozási dátumot meg a vendégek számát várja, válaszként pedig visszaadja a szabad szobákat árral együtt”. A Chrome dokumentációja szerint ez az explicit, JSON Schema alapú eszközleírás nagyobb pontosságot ad az ügynöki feladatvégzésben, mint a kattintások utánzása. A JSON Schema egy elterjedt, géppel olvasható formátum, amely leírja, milyen mezőket és milyen típusú értékeket vár egy adatstruktúra, így az ügynök pontosan tudja, hová mit kell írnia.

A javaslat nem a semmiből jött. A Spronta 2026. július 23-i összefoglalója szerint a WebMCP-t Patrick Brosset, a Microsoft munkatársa javasolta 2025. augusztus 28-án, nem sokkal később a Google is társszerzőként csatlakozott, maga az ötlet pedig Alex Nahas 2025-ös, MCP-B nevű nyílt forráskódú projektjéből nőtt ki. A specifikáció ma a W3C Web Machine Learning közösségi csoportjának tervezete (Draft Community Group Report), szerkesztői a Microsofttól Brandon Walderman, a Google-től Khushal Sagar és Dominic Farolino. Ebből két dolog következik: a Chrome és az Edge mögött álló két cég együtt dolgozik rajta, ugyanakkor ez még nem hivatalos W3C-szabvány, így a részletek menet közben változhatnak.

Azt is tisztán kell látni, mire nem való a WebMCP. A Chrome dokumentációja három korlátot emel ki: a technológia a felhasználó böngészőjében zajló munkafolyamatokra készült, a háttérben, képernyő nélkül (headless módban) futó automatizálásra nem; az összetett felületek átalakítást igényelhetnek; az eszközök pedig csak akkor fedezhetők fel, ha az ügynök ténylegesen megnyitja az oldalt. Az utolsó pont marketingszempontból különösen lényeges, mert a WebMCP nem keresőoptimalizálás. Attól, hogy eszközöket deklarálsz, a ChatGPT vagy a Gemini nem fog gyakrabban rátalálni az oldaladra, ha viszont már ott jár, sokkal ügyesebben és gyorsabban tud rajta dolgozni.

Miben különbözik a WebMCP a klasszikus MCP-szervertől?

A klasszikus MCP szerveroldali megoldás: a cég külön szervert üzemeltet, amelyhez az AI-kliens saját hitelesítéssel kapcsolódik, akár emberi jelenlét nélkül is. A WebMCP ugyanezt az eszközfogalmat a böngészőbe viszi, ahol az eszközök a megnyitott weboldalon élnek és a felhasználó meglévő bejelentkezésével futnak, külön szerver és külön integráció nélkül.

Az MCP (Model Context Protocol) az Anthropic által 2024 novemberében bemutatott nyílt protokoll, amely szabványos módot ad arra, hogy egy AI-alkalmazás külső eszközöket és adatforrásokat érjen el. Mára iparági alapnak számít: a Spronta júliusi összefoglalója szerint az MCP fejlesztői csomagjait havonta nagyjából 97 millió alkalommal töltik le. Egy klasszikus MCP-szerverrel például egy Odoo-rendszer vagy egy CRM kínálhat eszközöket egy AI-asszisztensnek, amely így lekérdezheti a nyitott ajánlatokat vagy rögzíthet egy új partnert. Az MCP július 28-án megjelent új, állapotmentes specifikációja önálló téma, amelyről külön cikkben írunk, itt elég annyi, hogy ez a világ a szerverek és a hátsó irodai integrációk terepe.

A WebMCP átveszi az MCP eszközfogalmát (név, leírás, bemeneti séma), de a futtatást a böngészőre bízza. A weboldal JavaScriptben vagy HTML-ben regisztrálja az eszközeit, az üzenetek szállítását a böngésző intézi. A legnagyobb gyakorlati különbség a hitelesítés: mivel az eszköz a felhasználó böngészőjében, az ő lapján fut, ugyanazokat a sütiket és ugyanazt a bejelentkezett munkamenetet használja, mint ő maga. Egy képzeletbeli B2B viszonteladói portálon így a partner asszisztense API-kulcs és külön OAuth-beállítás nélkül lekérdezheti a partner saját rendeléseit, pontosan azokkal a jogosultságokkal, amelyekkel a partner is látja őket.

Meglátásunk szerint a legtöbb KKV-nak hosszabb távon mindkét világra szüksége lesz, csak más célra. A vállalatirányítási rendszer vagy a CRM MCP-szerveren keresztül szolgálhatja ki a belső automatizálásokat, míg a nyilvános weboldal WebMCP-vel segítheti a látogatók ügynökeit. A kettő nem versenytársa egymásnak, hiszen a klasszikus MCP a hátsó irodát köti be, a WebMCP pedig a kirakatot és a pultot.

Van a böngészőhöz kötöttségnek egy kevésbé nyilvánvaló előnye is. Mivel a WebMCP-eszközök csak nyitott lapon, a felhasználó szeme előtt működnek, a folyamatban szinte mindig ott ül egy ember, aki látja, mit tölt ki az ügynök, a végén pedig ő nyomja meg a gombot. Ez egy fiatal, még formálódó technológiánál inkább biztonsági öv, mint hiányosság.

Kétféle deklaráció: JavaScript API és HTML-annotáció

A WebMCP két utat kínál az eszközök leírására. A deklaratív API-val a meglévő HTML-űrlapokat látod el néhány új attribútummal, míg az imperatív API-val JavaScriptben regisztrálsz tetszőleges logikájú eszközöket. Az eredmény mindkét esetben ugyanaz: az ügynök egy névvel, leírással és bemeneti sémával ellátott eszközt lát, amelyet meghívhat.

A deklaratív út: néhány attribútum a meglévő űrlapon

A Chrome 2026. május 18-án közzétett deklaratív API-leírása négy új attribútumot vezet be. A form elemen a toolname adja az eszköz nevét, a tooldescription írja le, mire való, a toolautosubmit pedig azt jelzi, hogy az ügynök meghívásakor az űrlap magától elküldhető. Az egyes mezőkön a toolparamdescription attribútummal adhatsz leírást, amely a bemeneti séma megfelelő tulajdonságához kerül. Vegyünk egy képzeletbeli kecskeméti asztalosüzemet, amelynek ajánlatkérő űrlapja így nézhet ki WebMCP-annotációkkal:

<form toolname="ajanlatkeres"
  tooldescription="Árajánlat kérése egyedi bútorra. A méreteket centiméterben kéri."
  action="/ajanlatkeres" method="post">
  <label for="butortipus">Bútor típusa</label>
  <select id="butortipus" name="butortipus" required
    toolparamdescription="A kért bútor típusa. Egyedi darabnál az Egyéb opció.">
    <option value="konyha">Konyhabútor</option>
    <option value="gardrob">Gardrób</option>
    <option value="egyeb">Egyéb</option>
  </select>
  <label for="szelesseg">Szélesség (cm)</label>
  <input type="number" id="szelesseg" name="szelesseg"
    toolparamdescription="A bútor teljes szélessége centiméterben.">
  <label for="email">E-mail-cím</label>
  <input type="email" id="email" name="email" required>
  <button type="submit">Ajánlatot kérek</button>
</form>

A böngésző az űrlap mezőiből állítja elő az eszköz bemeneti sémáját, a toolparamdescription szövege pedig a megfelelő mező leírása lesz. Ebből az is következik, hogy minél tisztább a HTML, annál jobb az eszköz: a beszédes name attribútumok, a helyes mezőtípusok (email, number, date) és a required jelölés mind az ügynök munkáját könnyítik. Ha egy mező leírása egyértelművé teszi a mértékegységet vagy a formátumot, sokkal kisebb az esélye, hogy az ügynök milliméterben adja meg a szélességet, amikor te centimétert vársz.

A toolautosubmit attribútummal óvatosan bánj. Ha hiányzik, az ügynök kitölti a mezőket, de az elküldés a felhasználóra marad, aki így átnézheti az adatokat. Kereső űrlapnál nyugodtan bekapcsolhatod, egy rendelést vagy foglalási kérést indító űrlapnál viszont jobb, ha az utolsó kattintás emberi marad.

A deklaratív API néhány eseményt és jelzést is hoz. A window objektumon a toolactivated esemény akkor sül el, amikor az ügynök előre kitöltötte az űrlap mezőit, a toolcancel pedig akkor, ha a felhasználó megszakítja a folyamatot vagy az űrlapon reset() hívás történik. Egyik esemény sem tiltható le, mindkettő tartalmazza az érintett eszköz nevét (toolName). A SubmitEvent, vagyis az elküldéskor keletkező esemény két újdonságot kap: az agentInvoked logikai érték megmutatja, hogy a beküldést ügynök indította-e. A respondWith() metódussal egy Promise-on keresztül visszaküldhetsz az ügynöknek egy választ, például egy validációs hibaüzenetet vagy egy visszaigazolást. Végül két új CSS-pszeudoosztály is érkezik, a :tool-form-active és a :tool-submit-active, amelyekkel vizuálisan kiemelheted az ügynök által épp kezelt űrlapot és gombot. Ez apróságnak tűnik, de a felhasználói bizalom szempontjából sokat ér, ha a látogató látja, melyik űrlapon dolgozik éppen a gépi segítője.

Az imperatív út: eszközök JavaScriptből

Amikor a művelet nem egy egyszerű űrlap, hanem például egy adatbázis-lekérdezés vagy egy több lépésből álló kosárművelet, az imperatív API a jobb választás. A Chrome 2026. szeptember 11-én frissített dokumentációja szerint az eszközt a document.modelContext.registerTool() hívással lehet regisztrálni, ám a dokumentáció külön jelzi, hogy az API aktív vita tárgya, így a jövőben változhat. A balatoni panzió szabadszoba-lekérdezése a jelenlegi leírás szerint nagyjából így festene:

const controller = new AbortController();
await document.modelContext.registerTool({
  name: 'szabad_szobak',
  description: 'Szabad szobák és árak lekérdezése érkezési és távozási dátum alapján.',
  inputSchema: {
    type: 'object',
    properties: {
      erkezes: { type: 'string', format: 'date' },
      tavozas: { type: 'string', format: 'date' },
      vendegek: { type: 'integer', minimum: 1 }
    },
    required: ['erkezes', 'tavozas']
  },
  annotations: { readOnlyHint: true },
  execute: async ({ erkezes, tavozas, vendegek }, { signal }) => {
    const valasz = await fetch(
      `/api/szabad-szobak?erkezes=${erkezes}&tavozas=${tavozas}&vendegek=${vendegek ?? 2}`,
      { signal }
    );
    return JSON.stringify(await valasz.json());
  }
}, { signal: controller.signal });

Az eszköz négy fő részből áll. A name a gépi azonosító, a description az ügynöknek szóló, emberi nyelvű leírás, az inputSchema a JSON Schema formátumú bemeneti séma, az execute pedig az a függvény, amely ténylegesen elvégzi a munkát, megkapja a bemenetet és egy megszakításra szolgáló jelet (signal), majd szöveges választ ad vissza. A regisztráció második paraméterében átadott signal arra jó, hogy később visszavond az eszközt: ha a controller.abort() lefut, az eszköz eltűnik az ügynök elől. Egy webshopban így megoldható, hogy a rendelés véglegesítésére szolgáló eszköz csak akkor létezzen, amikor a kosárban már van valami.

Az annotations mező három jelzést ismer. A readOnlyHint azt mondja, hogy az eszköz csak olvas, semmit nem változtat, a consequentialHint azt, hogy a meghívásának következménye van (például rendelés vagy foglalás jön létre), az untrustedContentHint pedig azt, hogy a válasz olyan tartalmat is hordozhat, amely nem a te ellenőrzésed alatt születik, például vásárlói véleményeket. Ezek a jelzések segíthetnek az ügynöknek eldönteni, mikor kérjen megerősítést a felhasználótól, a döntést azonban nem helyettesítik, ezért a kockázatos műveleteket a saját oldaladon is védeni kell.

A dokumentáció további elemeket is leír: a getTools() visszaadja az elérhető eszközöket, az executeTool() pedig kézzel is meghív egyet. Más originről (vagyis másik domainről) beágyazott iframe csak akkor kínálhat eszközt, ha a beágyazó oldal az iframe allow attribútumában engedélyezi a tools jogosultságot. Az exposedTo lista azt határozza meg, mely originek érhetik el az adott eszközt. Hogy mennyire mozgó célpontról van szó, azt jól mutatja egy friss változás: a Spronta szerint a Chrome 150-ben a korábbi navigator.modelContext objektumot elavultnak jelölték és a document.modelContext váltotta. Ha tehát egy tavaszi blogbejegyzésből másolsz kódot, jó eséllyel már nem a jelenlegi formát kapod.

Melyiket válaszd?

Egyszerű ökölszabály, hogy ahol már van működő HTML-űrlap, ott a deklaratív út a kezdés. A kapcsolatfelvételi, ajánlatkérő, hírlevél- és keresőűrlapok néhány attribútummal eszközzé válnak, miközben a meglévő szerveroldali feldolgozás változatlan marad. Az imperatív API akkor kell, amikor dinamikus adatot kell visszaadni (készlet, szabad időpont, szállítási idő), amikor a művelet nem köthető egyetlen űrlaphoz, vagy amikor az oldal egy JavaScript-keretrendszerre épülő alkalmazás, amelyben klasszikus űrlapok alig vannak. A két megközelítés jól megfér egymás mellett ugyanazon az oldalon.

Hol tart ma a WebMCP: Chrome 149 origin trial, WordPress Playground és Angular?

• szeptember 22-én a WebMCP a Chrome 149-es verziójától origin trialban, vagyis regisztrált oldalakon valódi látogatóknál is kipróbálható, a Spronta összefoglalója szerint egészen a Chrome 156-ig. A WordPress Playground szeptember 5. óta 16 beépített eszközt kínál ügynököknek, az Angular v22 kísérleti támogatással érkezett, a specifikáció pedig továbbra is közösségi tervezet.

Chrome: origin trial, fejlesztői flag, DevTools és Lighthouse

Az origin trial a Chrome olyan mechanizmusa, amellyel egy fejlesztő regisztráció után kapott tokennel, időkorlátosan kapcsolhat be egy még kísérleti funkciót a saját éles oldalán. A Drop Times nevű szakportál 2026. június 15-i beszámolója szerint a Google május 18-án tette közzé a WebMCP dokumentációját és az origin trial a Chrome 149-cel indult. Helyi fejlesztéshez nem kell regisztrálni, elég a chrome://flags/#enable-webmcp-testing kapcsolót bekapcsolni. Ugyanez a beszámoló kiemeli, hogy a Chrome DevTools kísérleti WebMCP-támogatást kapott: megmutatja az oldalon regisztrált eszközöket, lehetővé teszi a kézi meghívásukat, ellenőrzi a JSON Schema érvényességét, végül a visszaadott eredményt és a hibákat is megjeleníti. A Google élő oldalak tesztelésére a Model Context Protocol Inspector nevű böngészőbővítményt ajánlja.

A legbeszédesebb jel talán a Lighthouse új auditkategóriája. A Lighthouse a Chrome beépített, ingyenes oldalelemző eszköze, amelyet sokan a sebességmérésből ismernek, a 2026. július 1-jén frissített dokumentáció szerint viszont már „Agentic browsing” (ügynöki böngészés) kategóriája is van. Ebben szerepel a regisztrált WebMCP-eszközök listája, az ellenőrzés, hogy mely űrlapokról hiányzik a deklaratív WebMCP, a sémák érvényessége, az llms.txt fájl megléte, az ügynököknek szóló akadálymentesség és az elrendezés stabilitása. A lista jól mutatja a Google gondolkodását: az ügynökbarát oldal ugyanazokon az alapokon áll, mint az akadálymentes és stabil oldal.

A többi böngésző óvatosabb. A Spronta júliusi összefoglalója szerint a Microsoft Edge a 147-es verziótól kapcsoló mögött, kísérleti jelleggel támogatja a WebMCP-t, a Firefox és a Safari fejlesztői részt vesznek a specifikációs vitákban, de implementációt nem vállaltak. A Drop Times szerint a Cloudflare is foglalkozik a technológiával, nála a Browser Run szolgáltatás kísérleti, éles használatra nem szánt funkciójaként szerepel. Biztonsági alapfeltétel, hogy a WebMCP csak origin-izolált dokumentumokban működik. A Chrome emellett a tools nevű Permissions Policy jogosultsághoz köti, amely alapértelmezetten csak a legfelső szintű és az azonos originről származó tartalomra érvényes.

WordPress Playground: 16 eszköz a böngészőben futó WordPressben

A WordPress Playground a WordPress projekt eszköze, amely egy teljes WordPress-oldalt futtat közvetlenül a böngészőben: a PHP WebAssemblyre fordítva fut, így külső szerverre nincs szükség. Fellyph Cintra 2026. szeptember 5-i bejegyzése szerint a Playground mostantól WebMCP-eszközöket is kínál, szám szerint 16-ot, négy csoportban. Az oldalkezelő eszközök között van a webhely címének lekérdezése, az oldalak listázása, átnevezése és a böngészőbe mentése, a PHP-csoportban kódfuttatás (playground_execute_php) és HTTP-kérés, a navigációs csoportban oldalváltás és az aktuális webhely adatainak lekérése, a fájlrendszer-csoportban pedig olvasás, írás, listázás, mappa létrehozása és törlés.

A bejegyzés bemutatója szerint egy ügynök a ChatGPT asztali alkalmazásának beépített böngészőjében, természetes nyelvű kérésre épített fel egy reszponzív landing page-et a WordPress alapblokkjaiból (Cover, Columns, Button). Közben egy tanulságos technikai akadály is felszínre került: az OpenAI böngészője a bejegyzés szerint egyelőre csak a legfelső szintű oldalon keresi az eszközöket, az iframe-ekben nem. Mivel a Playground a WordPresst egy beágyazott keretben futtatja, a csapat szeptember 3-án egy proxyt olvasztott be, amely továbbítja az eszközöket a külső oldalra.

Egy élő WordPress-oldal tulajdonosának mindez egyelőre közvetett hír, mert a bejegyzés maga is rögzíti, hogy a bővítményeknek maguknak kell regisztrálniuk a WebMCP-eszközeiket, a WordPress képességei nem válnak automatikusan eszközzé. Az irány viszont egyértelmű: a Gutenberg Times beszámolója szerint a WordPress Core AI csapata szeptember elején jelentette, hogy az MCP Adapter beküldésre kész a bővítménytárba. Valószínűnek tartjuk, hogy az űrlap- és webshopbővítmények fejlesztői idővel megjelennek a saját WebMCP-megoldásaikkal, ezért figyeld a használt bővítmények változásnaplóit.

Angular: kísérleti támogatás a keretrendszerben

Az InfoQ 2026. augusztus 10-i cikke szerint a 2026. június 5-én megjelent Angular v22 kísérleti WebMCP-támogatást hoz, amely az alkalmazás eszközeit és az új Signal Forms űrlapjait teszi elérhetővé a böngészőben futó ügynököknek. A Drop Times összefoglalója szerint az Angular függőséginjektálással és útvonalhoz kötött eszközökkel oldja meg a regisztrációt, vagyis egy eszköz csak azon az aloldalon létezik, ahol értelme van. Ez leginkább annak fontos, akinek egyedi ügyfélportálja, foglalási rendszere vagy belső webalkalmazása Angularban készült, mert ott a keretrendszer adta úton lehet haladni ahelyett, hogy kézzel kellene mindent összedrótozni.

Ki hívja meg ma ténylegesen a WebMCP-eszközöket?

2026 szeptemberében még kevés ügynök használja a WebMCP-eszközöket. A WordPress Playground csapata szerint az OpenAI a ChatGPT asztali alkalmazásának beépített böngészőjében már támogatja őket, a Google pedig a Spronta összefoglalója szerint bejelentette, hogy a Gemini in Chrome is használni fogja, a széles körű ügyféloldali elterjedés tehát még hátravan.

A helyzet ugyanakkor hétről hétre változik: a Spronta július 23-i összefoglalója még azt írta, hogy egyetlen elterjedt AI-ügynök sem használja a WebMCP-eszközöket, a Claude, a ChatGPT Agent, a Perplexity és a Gemini is a DOM értelmezésére vagy képernyőképekre támaszkodott. Ugyanez az elemzés csípősen megjegyezte, hogy a demókon kívül a bevezetések száma gyakorlatilag nulla, miközben a WebMCP-validátorok száma már meghaladja a tényleges implementációkét. Több nagy utazási és kereskedelmi szereplő neve is felmerült lehetséges pilotpartnerként, az éles bevezetést azonban a cikk szerint egyikük sem erősítette meg.

Hat héttel később, szeptember 5-én a WordPress Playground bejegyzése már arról számolt be, hogy az OpenAI a ChatGPT asztali alkalmazásának böngészőjében „Site tools” néven támogatja az oldalak eszközeit. A felhasználó a címsorban a „Site tools”, majd az „Available site tools” menüpontot választva látja, milyen eszközöket kínál az adott oldal. A bejegyzés szerint a funkció a GPT-5.6 Sol és a GPT-5.6 Terra modellel működik, a GPT-5.6 Lunával nem, ahogy az Enterprise és az Edu munkaterületeken sem érhető el. Ez a klasszikus tyúk-tojás probléma első repedése: amíg nincs ügynök, amely használná az eszközöket, az oldalak nem fejlesztenek, amíg pedig nincsenek eszközök, az ügynökök gyártói nem sietnek a támogatással.

A vásárlói oldalt is tágabban kell nézni, mert az ügyfeleid egyre több ügynökkel érkeznek: a Meta Muse személyi ügynöke például macOS-en kezel alkalmazásokat és naptárat, a Google szeptember 17-én korai hozzáférésben megnyitotta a Google Home MCP-t. Ezekről az ügynökökről külön cikkben írunk, ide annyi tartozik, hogy minden ilyen asszisztens előbb-utóbb eljut egy weboldalra, ahol vagy talál leírt eszközt, vagy kattintgatni kezd.

Mit jelent a WebMCP egy webshopnak: foglalás, rendelés, ajánlatkérés ügynökön keresztül?

Egy webshopnak vagy szolgáltatónak a WebMCP azt jelenti, hogy a vásárló ügynöke megbízhatóan tud keresni, készletet és szállítási időt lekérdezni, kosarat összeállítani, időpontot foglalni vagy ajánlatot kérni. A pénzzel járó utolsó lépést viszont jobb a vásárlónál hagyni, amit a WebMCP eszközei kifejezetten támogatnak.

Vegyünk egy képzeletbeli debreceni webshopot, amely kerti bútorokat árul. A vásárló ezt mondja az asszisztensének: „keress nekem egy legalább 180 centis fenyő kerti asztalt 120 000 Ft alatt, ami jövő szerdáig megérkezik”. DOM-kaparással az ügynöknek végig kell nyomkodnia a szűrőket, ki kell várnia a lassan betöltődő termékkártyákat és lapoznia kell, miközben a szállítási időt jó eséllyel csak a termékoldalon, egy lenyíló fül mögött találja meg. Ha a webshop egy termek_kereses és egy szallitasi_ido eszközt kínál, az ügynök két hívással pontos, strukturált választ kap, így a vásárló pár másodperc múlva látja a három megfelelő terméket a kosárba tétel lehetőségével.

A kulcskérdés az, melyik műveletet milyen feltételekkel adod ki az ügynöknek. Az alábbi táblázat egy lehetséges kiindulópont, amelyet a saját kockázatvállalásodhoz igazíthatsz.

A foglalásnál a korábbi balatoni példa mutatja a mintát. A szabad szobák lekérdezése csak olvasó eszköz, amelyet az ügynök bármikor hívhat, a tényleges foglalási kérés viszont egy toolautosubmit nélküli deklaratív űrlap. Az ügynök kitölti a dátumokat, a létszámot és a vendég nevét, az űrlapot a :tool-form-active pszeudoosztállyal kiemeled, a vendég átnézi az adatokat, majd ő maga nyomja meg a küldés gombot. Az előleg kifizetése ugyanúgy történik, mint eddig, a vendég saját kezével és a fizetési szolgáltató megszokott felületén.

Az ajánlatkérésnél a WebMCP legnagyobb haszna a teljesség. Tegyük fel, hogy a kecskeméti asztalosüzemhez érkező ajánlatkérések fele méretek nélkül fut be, ilyenkor pedig telefonálni vagy újabb e-mailt kell írni. Ha a toolparamdescription egyértelműen kéri a centiméterben megadott szélességet és a kívánt anyagot, az ügynök ezeket a felhasználóval folytatott beszélgetésből vagy közvetlen visszakérdezéssel pótolhatja. Ha mégis hiányzik valami, a respondWith() metódussal visszaküldött hibaüzenet („a szélesség megadása kötelező”) alapján az ügynök maga javíthatja a kérést, így az asztalos már egy használható, egységes szerkezetű ajánlatkérést kap.

Nem árt elhatárolni a WebMCP-t a Shopify Winter ’26 Edition részeként bejelentett Agentic Storefronts megoldástól. A Shopify megoldása azt célozza, hogy a bolt termékei magukban az AI-beszélgetésekben jelenjenek meg, vagyis a webshopon kívül, a WebMCP viszont akkor lép színre, amikor az ügynök már a te oldaladon dolgozik. A kettő kiegészíti egymást, ezért egy komolyabb webshop idővel mindkettővel foglalkozni fog.

Milyen biztonsági és adatvédelmi kockázatokkal jár a WebMCP?

A WebMCP legnagyobb kockázata, hogy az eszközök a felhasználó bejelentkezett munkamenetével futnak, így egy megtévesztett ügynök valódi jogosultsággal indíthat valódi műveleteket. Ez jól kezelhető szűkre szabott eszközökkel, emberi megerősítéssel a következményes lépéseknél, szerveroldali ellenőrzéssel és alapos naplózással.

A Spronta elemzése két kockázati mintát emel ki. Az első a promptinjekció, vagyis az a manipuláció, amelynél egy szövegbe rejtett utasítás téríti el a nyelvi modellt az eredeti feladatától. Ilyen lehet például egy termékvéleménybe vagy egy harmadik fél oldalára írt, az ügynöknek szóló üzenet. A második a „megtévesztett helyettes” (confused deputy) problémája, amikor egy jogosultsággal rendelkező szereplőt, jelen esetben az ügynököt, valaki ráveszi, hogy a saját jogosultságával olyasmit tegyen, amit a felhasználó nem akart, akár több weboldalon átívelő láncban. A Chrome beépített védelmei ebben segítenek, de nem oldanak meg mindent: az eszközök csak origin-izolált oldalon működnek, a tools jogosultság alapértelmezetten nem terjed ki a más originről beágyazott iframe-ekre, valamint az exposedTo lista szűkíti, ki érheti el az eszközt.

A saját oldaladon ezekkel a szabályokkal csökkentheted a kockázatot:

• Egy eszköz egyetlen, jól körülírt dolgot csináljon. A WordPress Playground PHP-futtató eszköze egy böngészőben futó homokozóban rendben van, egy éles webshopban viszont semmilyen általános „futtass bármit” jellegű eszköznek nincs helye.
• A következményes műveleteket jelöld a consequentialHint annotációval, a hozzájuk tartozó űrlapokon pedig hagyd el a toolautosubmit attribútumot, hogy az utolsó kattintás a felhasználóé maradjon.
• Minden bemenetet a szerveren is ellenőrizz, pontosan úgy, mintha ismeretlen küldte volna, beleértve a jogosultság-ellenőrzést és a kérések számának korlátozását.
• Ha az eszköz válasza vásárlói véleményt, üzenetet vagy más, általad nem ellenőrzött szöveget tartalmaz, jelöld az untrustedContentHint annotációval.
• Az adatvédelmi hozzájárulást kérő jelölőnégyzetet (például hírlevélhez) ne tedd az eszköz paraméterévé, hanem hagyd, hogy a felhasználó maga pipálja ki, így nem lesz kérdéses, hogy a hozzájárulás tőle származik.

A tágabb környezet is az óvatosság mellett szól. Az ENSZ 40 tagú független tudományos panelje szeptember 21-én az elővigyázatosság elvére hivatkozva azt javasolta a kormányoknak, hogy fékezzék meg az AI-ügynököket. A spanyol adatvédelmi hatóság szeptember 17-én egy lehetséges, ügynök által végrehajtott adatszivárgásról számolt be, amelynek kiváltó okát még vizsgálják, szeptember 7-én pedig a LiteLLM nevű eszköz MCP-hitelesítésében találtak aktívan kihasznált bejelentkezés-megkerülési hibát. Egyik eset sem a WebMCP-hez kötődik, együtt viszont jól mutatják, hogy az ügynökök hitelesítési és jogosultsági rétege lett az egyik legérzékenyebb pont.

Mennyi munka és mennyibe kerül a WebMCP bevezetése egy KKV-oldalon?

Saját becslésünk szerint egy rendezett HTML-űrlapokkal dolgozó KKV-oldalon a deklaratív WebMCP bevezetése tesztelésestül és méréssel együtt 8 és 13 fejlesztői óra, ami 10 000 Ft-os óradíjjal számolva 80 000 és 130 000 Ft közötti tétel. Egy webshop JavaScript-alapú eszközkészlete ennek többszöröse lehet.

A becslés feltételezi, hogy három-öt űrlapról van szó, a HTML nagyjából szabályos és a szerveroldali feldolgozás nem változik. A 10 000 Ft-os óradíj számítási egyszerűsítés: ha a fejlesztőd drágábban dolgozik, arányosan szorozd fel az összegeket. Jelentősen drágíthat, ha az űrlapokat egy oldalépítő bővítmény div-ekből rakja össze, ha egyedi JavaScript-vezérlőket kell natív elemekre cserélni, vagy ha a foglalás egy külső szolgáltató beágyazott iframe-jében fut. Ez utóbbi esetben a WebMCP-támogatás nem is rajtad, hanem a szolgáltatón múlik, hiszen a más originről beágyazott tartalom csak külön engedéllyel kínálhat eszközt, ráadásul az OpenAI böngészője a Playground bejegyzése szerint egyelőre csak a legfelső szintű oldalon keresi őket.

Arról, hogy a WebMCP a Google keresési rangsorolását befolyásolná, tudomásunk szerint 2026. szeptember 22-ig nem jelent meg hivatalos közlés, ezért rangsorolási előnyt ne várj tőle. A befektetés ettől függetlenül nem vész el, mert a szabályos, jól címkézett űrlap az emberi látogatóknak, a képernyőolvasót használóknak és a konverziós aránynak is jót tesz.

Hogyan készítsd fel a weboldaladat a WebMCP-re lépésről lépésre?

A felkészülés a meglévő űrlapok rendbetételével kezdődik, nem kódírással. Készíts leltárt, tedd szabályossá a HTML-t, válassz ki egy-két alacsony kockázatú műveletet, lásd el őket deklaratív annotációval, teszteld helyben a Chrome kapcsolójával és a Lighthouse-szal, az éles origin trialra pedig csak ezután jelentkezz.

• Készíts leltárt. Írd össze az oldal összes űrlapját és fontos műveletét (keresés, ajánlatkérés, foglalás, hírlevél, kapcsolatfelvétel, kosár), mellé pedig azt, hogy melyiknek van következménye pénzben, foglalásban vagy személyes adatban.
• Tedd szabályossá a HTML-t. Használj natív form, input, select és button elemeket, minden mezőhöz tartozzon label, beszédes name és helyes típus (email, number, date), a kötelező mezőkön pedig szerepeljen a required jelölés. A div-ekből összerakott egyedi vezérlők az ügynököknek és a képernyőolvasót használó embereknek egyaránt nehezek.
• Válassz egy-három kezdő műveletet. Olyat keress, amelynek kicsi a kockázata és nagy a haszna, például a termékkeresést, az ajánlatkérést vagy a szabad időpontok lekérdezését.
• Írj jó leírásokat. A tooldescription egy-két mondatban mondja meg, mire való az eszköz és mire nem, a toolparamdescription pedig tartalmazza a mértékegységet, a formátumot és a megkötéseket. A leírás lehet magyar, a toolname esetében viszont az ékezet nélküli, kisbetűs, aláhúzással tagolt azonosító a biztonságosabb választás.
• Döntsd el, mi küldhető automatikusan. A toolautosubmit attribútumot kizárólag a csak olvasó műveleteknél, például keresésnél használd, minden másnál maradjon emberi az elküldés.
• Teszteld helyben. Kapcsold be a chrome://flags/#enable-webmcp-testing kapcsolót, nézd meg az eszközöket a DevTools kísérleti WebMCP-nézetében vagy a Model Context Protocol Inspector bővítményben, majd hibás bemenettel is próbáld ki, mit válaszol az oldal.
• Futtasd a Lighthouse ügynöki auditjait. Az Agentic browsing kategória megmutatja, mely űrlapokról hiányzik a deklaratív WebMCP, érvényesek-e a sémák, illetve hogyan áll az oldal az ügynököknek szóló akadálymentesség és az elrendezés stabilitása terén.
• Jelentkezz az origin trialra, ha élesben is kísérleteznél. A regisztráció után kapott tokent egy meta címkében vagy HTTP-válaszfejlécben kell elhelyezni. Mivel a próbaidőszak időkorlátos, jegyezd fel a lejáratát.
• Mérj, naplózz és kövesd a változásokat. Az ügynöki beküldéseket jelöld külön az analitikában és a szervernaplóban, a Chrome négyhetes kiadási ciklusában pedig minden új verziónál nézd át, módosult-e az API.

Így méred az ügynöki kitöltéseket

Mérés nélkül nem fogod tudni, hoz-e bármit a WebMCP. A Chrome dokumentációja szerinti agentInvoked tulajdonság és toolactivated esemény alapján az ügynöki kitöltéseket külön eseményként küldheted a Google Tag Manager adatrétegébe, ahonnan a Google Analytics 4-be továbbíthatod őket:

document.querySelector('form[toolname="ajanlatkeres"]')
  .addEventListener('submit', (e) => {
    if (e.agentInvoked) {
      window.dataLayer = window.dataLayer || [];
      window.dataLayer.push({ event: 'ugynoki_bekuldes', eszkoz: 'ajanlatkeres' });
    }
  });
window.addEventListener('toolactivated', (e) => {
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({ event: 'ugynoki_kitoltes', eszkoz: e.toolName });
});

A két szám összevetése többet mond bármilyen iparági előrejelzésnél. Ha a toolactivated események száma magas, a tényleges beküldéseké viszont alacsony, akkor a felhasználók valószínűleg elvetik, amit az ügynök kitöltött, ez pedig rossz leírásra vagy félreérthető mezőre utalhat. Mivel az API még változhat, a mérőkódot is ellenőrizd időnként a Chrome-verziókkal együtt.

Megéri most foglalkozni a WebMCP-vel, vagy várj vele?

Ha a bevételed nagy része űrlapon, foglaláson vagy webshopon keresztül érkezik, most érdemes rendbe tenni az űrlapokat és kísérleti jelleggel kipróbálni a deklaratív WebMCP-t. A drágább, JavaScript-alapú eszközkészlettel a legtöbb KKV nyugodtan kivárhat, amíg a szabvány és az ügynökök oldali támogatás beérik.

Üzlettípusonként így látjuk a helyzetet:

• Webshop: a csak olvasó termékkeresés és készletlekérdezés jó első lépés, a kosár és a rendelés ráér később. Ha platformon (Shopify, WooCommerce) fut a bolt, érdemes megvárni a platform vagy a bővítmények támogatását, mert a sablonba épített saját megoldást egy frissítés felülírhatja.
• Szállás, vendéglátás, időpontfoglalás: ha a foglalás saját űrlapon fut, a deklaratív annotáció gyorsan megvan. Ha viszont egy külső foglalómotor iframe-jében, kérdezd meg a szolgáltatót a WebMCP-terveiről.
• B2B ajánlatkérés (gyártó, asztalos, építőipar): itt a legjobb az ár-érték arány, mert egyetlen űrlap néhány órás munkával teljesebb és egységesebb ajánlatkéréseket hozhat.
• Bemutatkozó oldal kapcsolatfelvételi űrlappal: nincs sürgetés, elég, ha a következő átdolgozáskor szabályos HTML-t és WebMCP-attribútumokat is kérsz a fejlesztődtől.
• Egyedi webalkalmazás, ügyfélportál: most érdemes az architektúrát úgy tervezni, hogy a műveletek később eszközként is kiadhatók legyenek, Angular alapon a keretrendszer kísérleti támogatásával.

Egy helyzetben biztosan nem a WebMCP a prioritás: ha az oldal alapjai nincsenek rendben. A WordPress.org szeptember 17-i bejelentése szerint a WordPress 7.1.1 tizenegy biztonsági hibát javított, egy frissítetlen oldalon tehát először a frissítés, a mentés és a sebesség jön, az ügynökbarát űrlapok csak utána.

Miben segít a Convergo?

A Convergónál abban segítünk, hogy a weboldalad az emberek mellett az AI-ügynököknek is jól használható legyen. Webdesign és weboldalkészítés szolgáltatásunkban eleve szabályos, jól címkézett űrlapokkal dolgozunk, amelyekre a WebMCP-attribútumok néhány óra alatt felkerülhetnek. Webshop és online értékesítés projektekben a termékkeresést és a készletlekérdezést is fel tudjuk készíteni az ügynökökre, a programozás és egyedi fejlesztés keretében pedig 10 000 Ft-os óradíjjal vállaljuk az imperatív eszközök kiépítését, tesztelését és mérését. Az első lépés egy ingyenes egyeztetés, ahol átnézzük az űrlapjaidat és a Lighthouse ügynöki auditjainak eredményét, majd közösen eldöntjük, megéri-e most belefogni.