> A WebMCP lehetővé teszi, hogy egy oldal tipizált, hívható eszközöket adjon át a böngészőben futó ügynöknek. Mit tesz a szabvány, mennyi érhető el belőle ma, és mikor marad jobb egy MCP-szerver. > > Web page: https://balazscsorba.com/hu/blog/webmcp · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/webmcp.md) · [Deutsch](https://balazscsorba.com/de/blog/webmcp.md) > Author: Balázs Csorba · Published: 2026-09-30 · Keywords: webmcp, webmcp vs mcp, document.modelContext registerTool, webmcp declarative api, browser agent tools, webmcp origin trial, webmcp chrome 149 [Blog](https://balazscsorba.com/hu/blog)/Webfejlesztés # WebMCP: eszközöket publikálni pixelek helyett A WebMCP lehetővé teszi, hogy egy oldal tipizált, hívható eszközöket adjon át a böngészőben futó ügynöknek. Mit tesz a szabvány, mennyi érhető el belőle ma, és mikor marad jobb egy MCP-szerver. [Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. szeptember 30.·11 perc olvasás - WebMCP - Agent tools - JSON Schema - Chrome - MCP ![Széles panel apró négyzetekből, a szélén rés ad át egy formált blokkot a fogadóhoz.](https://balazscsorba.com/images/blog/webmcp/cover.webp?v=026ce075d9) ## A lényeg röviden - A WebMCP böngészős API-javaslat, nem könyvtár: a Chrome 149 és az Edge 150 origin trialként szállítja, a Firefox és a Safari csak a standards-position szakaszban tart. - Az eszközök a tabhoz kötöttek, az oldal saját kódjában futnak, és a tools Permissions Policy szabályozza őket, nem az ügynök DOM-ból való tippelése. - A Chrome útmutatója 500 karakterre korlátozza az eszköz leírását és 1,5 KB-ra a kimenetét, tehát az eszközkatalógus kontextusablak-büdzsé. - Mind a négy annotáció alapértelmezés szerint hamis, így egy eszköz biztonsági tulajdonságai annyira őszinték, amennyire az őket regisztráló oldal. - Nincs felfedezési mechanizmus: a kliensnek meg kell látogatnia az oldalt, hogy tudja, vannak-e eszközei. Ez megváltoztatja a szabvány üzleti értékét. Ezen az oldalon 1. [Mi ez](https://balazscsorba.com/#what-it-is) 2. [Hogyan működik](https://balazscsorba.com/#how-it-works) 3. [Első lépések](https://balazscsorba.com/#getting-started) 4. [Eszközök, amelyeket az ügynök kiválaszt](https://balazscsorba.com/#tool-design) 5. [Biztonság és annotációk](https://balazscsorba.com/#security) 6. [Hol marad el](https://balazscsorba.com/#where-it-shingles) 7. [Ítélet](https://balazscsorba.com/#verdict) 8. [Források](https://balazscsorba.com/#sources) Cikk meghallgatása 0:000:00 A WebMCP javasolt webes szabvány, amely lehetővé teszi, hogy egy oldal tipizált, hívható eszközöket publikáljon egy KI-ügynöknek, ahelyett hogy az ügynök a DOM-ból találgatná a szándékot. A javaslat kicsi, a böngészőtámogatás vékony, a tervezési döntés viszont helyes. Kezeld specifikációként, amit figyelni kell, és progresszív enhancementként feature detection mögött, nem pedig függőségként erre a negyedévre. A Model Context Protocol mellett áll, nem ellene. Egy MCP-szerver bármely kliensnek, bárhol ad backend képességeket; a WebMCP egy bejelentkezett oldal élő, tabon belüli állapotát adja át egy böngészőbe integrált ügynöknek, és eltűnik, ha a tab bezáródik. Az érdekes mérnöki kérdés nem az, melyik protokoll nyer. Az, melyik teszi elérhetővé a meglévő frontend-logikát anélkül, hogy hozzá kellene írni egy szervert. ## Mi ez A specifikáció a W3C Web Machine Learning Community Groupban él, és a WebMCP explainer dokumentálja a GitHubon, ahol a Chrome és az Edge csapatai a látható implementálók. A Chrome 149-től origin trial mögött szállítja, helyi fejlesztési kapcsolóval a `chrome://flags/#enable-webmcp-testing` címen. Az API egy objektum a `Document` interfészen, és két formában létezik. - `document.modelContext` biztosítja a `registerTool()`, `getTools()`, `executeTool()` függvényeket és egy `toolchange` eseményt. - Egy eszköz egy névből, természetes nyelvű leírásból, a bemenetre szóló JSON sémából és az oldalon belül futó execute függvényből áll. - A deklaratív API egy annotált űrlapot alakít eszközzé a `toolname`, `tooldescription`, `toolparamdescription` és `toolautosubmit` attribútumokkal. - Az eszközök efemerek. Csak addig léteznek, amíg az oldal nyitva van, és az oldal saját sütijeivel és sessionjével futnak. - Mindkét API a `tools` Permissions Policy alá esik, amely alapértelmezés szerint `self`, így a cross-origin iframe-ek kikapcsolnak, amíg a hoszt be nem állítja az `allow="tools"` attribútumot. - Az eszközök metaadatai a modell kontextusablakában vannak, ezért a regisztrált eszközök száma oldalankénti büdzsé, nem csak kódkérdés. ## Hogyan működik A regisztrálás egy hívás az oldalszkriptből; a meghívást a böngésző közvetíti az ügynök és az oldal között. A böngésző soha nem ad DOM-kezelőt az ügynöknek. Parszolja az argumentumokat, meghívja az execute függvényt, és a visszatérési értéket tool eredményként adja vissza. Ez az egész ergonómiai történet egy mondatban: az oldal dönti el, mi hívható, a böngésző pedig azt, ki hívhatja. ![WebMCP tool lifecycle A page registers a tool on document.modelContext. The browser mediates: it lists the tools to the agent, the agent invokes one, the execute function runs in the page, the page updates its own DOM and state, and the result travels back through the browser to the agent.](https://balazscsorba.com/images/blog/webmcp/diagram-7.webp?v=517519f667) A böngésző az ügynök és az oldal között ül. A hurokban semmi más nem bővítheti ezt a határt. A gyakorlati különbség az aktuáláshoz képest a hibakezelési ágon látszik. Egy kattintás egy rosszul renderelt elemen csendben elbukik, vagy a rossz handlert hívja meg. Egy rossz argumentummal érkező eszközhívás a saját validációnkba ütközik, és olyan üzenetet ad vissza, amit a modell el tud olvasni és használni. A Chrome útmutatója ezt kimondja, és azt javasolja, hogy a kódban szigorúan validáljunk, a séma viszont legyen laza, mert a séma elutasítása zsákutca az ügynök számára. ## Első lépések Az imperatív API az, amivel érdemes dolgozni, mert csak ez tud alkalmazásállapothoz nyúlni. Egy minimális read-only eszköz így néz ki. ``` // Feature-detect: the API is behind a flag or an origin trial. if (typeof document.modelContext?.registerTool !== 'function') return; const controller = new AbortController(); await document.modelContext.registerTool({ name: 'get_order_status', description: 'Return the shipping status of one order for the signed-in customer.', inputSchema: { type: 'object', properties: { orderNumber: { type: 'string', description: 'Order number as shown in the order list.' }, }, required: ['orderNumber'], additionalProperties: false, }, annotations: { readOnlyHint: true }, execute: async ({ orderNumber }) => { const order = await orders.findForCustomer(orderNumber); // A message the model can act on beats a thrown Error. if (!order) return `No order ${orderNumber} is visible to this account.`; return `Order ${orderNumber}: ${order.status}, arriving ${order.eta}.`; }, }, { signal: controller.signal }); // Unregister on route change. From Chrome 153 aborting no longer breaks a // call that is already running. controller.abort(); ``` Három részlet fontosabb a többinél. A leírás az, amit a modell olvas el annak eldöntésére, hogy meghívja-e az eszközt, és a Chrome útmutatója 500 karakterre korlátozza. Az execute függvénynek azt a függvényt kellene újrahasznosítania, amit a látható gomb már meghív, hogy egyetlen kódút legyen, és a felület meg az eszköz ne mondjon ellent egymásnak. Az `AbortSignal` a leiratkozás útja, nem időzítő. ### Deklaratív űrlapok A deklaratív API egyszerű űrlapokra való, semmi másra. Annotáld az űrlapelemet, és a böngésző levezeti az eszköz definícióját a markupból és a mezőnevekből. ```
``` A `toolautosubmit` nélkül az ügynök kitölti az űrlapot, és az ember megnyomja a küldést. Ez a helyes alapértelmezés mindenki számára, akinek költsége van a műveletnek. A attribútummal a böngésző küld és navigál, a `respondWith()` pedig a `SubmitEvent` eseményen lehetővé teszi, hogy az oldal eredményt adjon vissza a modellnek. Az `agentInvoked` jelzőflag megmondja az oldalnak, hogy melyik úton fut a folyamat. **A szabvány olcsóbb fele** A deklaratív API nem ér el JavaScript-only funkciót, mert az eszközdefinícióban nincs JavaScript. Az OpenAI site-tools dokumentációja kimondja, hogy a beépített böngésző egyáltalán nem implementálja a deklaratív API-t, így egy kizárólag űrlapokra épülő integráció ma láthatatlan a ChatGPT Work és a Codex számára. ## Eszközök, amelyeket az ügynök kiválaszt A közzétett best practice útmutató szokatlanul előíró, és érdemes szó szerint követni. A gondolatmenet: az eszköz leírása olyan kód, amelyet egy valószínűségi olvasó minden munkamenetben egyszer értelmez. A karakterbüdzsék azért léteznek, hogy a teljes katalógus ezen olvasó figyelmén belül maradjon. Büdzsé Ajánlott határ Eszköz leírása 500 karakter Paraméter leírása 150 karakter Eszköznév és paraméternév 30 karakterenként Egy eszköz kimenete 1,5 KB karakter A táblázat feletti tanács a nehezebbik fel: egy funkció eszközönként, ne legyenek átfedő eszközök, és a regisztrálás kötődjön az oldal állapotához egy minden oldalon betöltött statikus katalógus helyett. Az átfedő eszközök a leggyakoribb okai annak, hogy az ügynök a rosszat választja. - **Egy felelősség.** Egy funkció eszközönként, és ne legyen második eszköz, ami szinte ugyanezt teszi. - **Regisztrálás az aktuális állapothoz.** Szakítsd meg a controllert, amikor az útvonal vagy a dialógus változik, hogy az ügynök ne lásson már érvénytelen eszközöket. - **Fogadj nyers bemenetet.** Ha valaki azt mondja 11:00 és 15:00 között, vedd a stringet, és normalizáld kódban. Ne a modell számoljon. - **Olvasható enum értékek.** Az "express" jobb, mint a `shipping_id = 1`, mert a modell az értéket olvassa, nem az adatbázisodat. - **Használható hibát adj vissza.** Írd le, mit kell tenni, nem azt, mi történt bent. Egy elbukó eszköznek is használhatónak kell maradnia. ## Biztonság és annotációk Az annotációk a fő határvonal, amivel egy oldal szabályozhatja, hogyan bánnak a hosztok az eszközeivel, és mind a négy alapértelmezés szerint hamis. Ez a biztonságos alapértelmezés, de azt is jelenti, hogy egy eszköz biztonsági tulajdonságai annyira őszinték, amennyire az őket regisztráló oldal. - `readOnlyHint` az eszköz csak olvas, nem változtat semmit. Tedd rá minden kereső funkcióra. - `untrustedContentHint` a visszatérési érték felhasználó által generált vagy külső adatot tartalmaz, és korlátozni kell, mielőtt eléri a modellt. - `consequentialHint` a hívás foglal, fizet, küld vagy töröl. A kliensek megerősítést kényszeríthetnek ki vele. - `debugging` Chrome 156-tól jelöli fejlesztői eszköznek, hogy az általános ügynökök kiszűrhessék. A Chrome biztonsági útmutatója a közvetett prompt injekciót megoldatlannak tekinti. A modellek valószínűségiek, dokumentáltak az agentikus rendszerek elleni ismételhető támadások, és egy eszköz visszatérési értéke olyan csatorna, amelyet egy támadó írhat. Az ajánlott mitigációk az annotációk, a karakterbüdzsék és az origin izoláció, vagyis kárcsökkentés, nem megoldás. Ugyanez az oldal megjegyzi, hogy egy host engedélyekkel rendelkező extension az oldalt WebMCP nélkül is tetszőleges JavaScripttel irányíthatja. **Az exposedTo az éles él** Az `exposedTo` opció azokat a biztonságos origineket sorolja fel, amelyek felfedezhetik és futtathatják az eszközt, és az útmutató egyértelmű: egy read-only eszköz is kiszivárogtathat felhasználói adatot, az író eszköz pedig a felhasználó nevében jár el. Csak olyan origineket tegyél szabaddá, amelyeknek a hitelesítő adatokat is átadnád. ## Hol marad el A gyengeségek jönnek először, mert ezek miatt ez figyelendő tétel, nem függőség. A támogatás gyakorlatilag egyetlen motorkészülékcsaládra korlátozódik. A specifikáció saját állapotfájlja origin trialt sorol fel a Chrome 149-ben és az Edge 150-ben, kísérleti támogatást a Brave Leo chatben, támogatást a ChatGPT Desktopban, valamint standards-position bejegyzéseket a Firefoxban és a WebKitben, implementáció nélkül. Emellett a Chrome dokumentációja a headless böngészős munkát a hatókörön kívül helyezi, figyelmeztet, hogy az összetett felületeket át kell alakítani az alkalmazás- és felületállapot szinkronban tartásához, és megjegyzi, hogy a klienseknek meg kell látogatniuk egy oldalt, hogy felfedezzék az eszközeit. Nincs nyilvántartás, nincs manifest, nincs index. WebMCP MCP-szerver DOM-aktuálás Életciklus Tabhoz kötött, navigáláskor megszűnik Folyamatos daemon Egy kérés Lát Élő DOM, sütik, session Csak amit te kitálsz Amit az ügynök lekapar Futtatja a kódodat Igen, az oldalon belül Nem, csak szerveroldalon Nem Elérhető Ma egy motorcsaládtól Bármely MCP-kliensről Bármely böngészőből A felfedezhetőségi pont megérdemli a kiemelést, mert lerombolja a szokásos üzleti érvelést. Egy backend MCP-szervert megtalálhat egy olyan ügynök is, amely soha nem látja az oldalt. Egy WebMCP eszközt nem. Az egyetlen reális felfedezési út ma egy felhasználó, aki megnyitja az oldalt. A WebMCP tehát egy már elkezdődött munkamenet minőségéért verseng, nem a hatókörért. ## Ítélet A WebMCP egy jól rajzolt API egy valós problémára, és jobban rajzolva, mint ahogy a legtöbb csapat maga megépítené. Még nem függőség. Építsd az eszközréteget feature check mögé, tartsd a emberi felületet elsődleges útként, és térj vissza, ha megjelenik a második motor, vagy ha a deklaratív fele már nem csak Chromium-egyedüli. A részletekhez az oldal [ügynékkészített weboldal deklarált eszközökkel](https://balazscsorba.com/hu/blog/webmcp-agent-ready-website-guide) című útmutatója ad részletes betekintést. 1. Vedd fel termékfelületeken, ahol egy bejelentkezett felhasználó és egy ügynök ugyanazt az oldalt látja: foglalás, checkout, támogatási kérelmek, beállítások. 2. Hagyd ki az egyszerű olvasási feladatoknál. Az oldal Markdown-másolata olcsóbb, és nem is kell böngésző. 3. Hagyd ki, ha a folyamatid túlnyomórészt olyan űrlapok, amelyeket nem tudsz annotálni, vagy ha nem tudod szinkronban tartani a felületet az eszközúttal. 4. Ne építs MCP-szervert arra az elvárásra, hogy a WebMCP lecseréli. Különböző rétegek, és a hasznos architektúra mindkettőt használja. 5. A karakterbüdzséket és az egy-funkció-egy-eszköz szabályt kemény korlátnak kezeld a katalógusra, nem javaslatnak. **A legolcsóbb első kísérlet** Vegyél egy meglévő gombkezelőt, csomagold be őszintén beállított annotációkkal a `registerTool()` hívásba, és mérd meg, hogy az ügynök az eszközútat választja-e a kattintási út helyett. Ez az egyetlen mérés gyorsabban megválaszolja az adaptációs kérdést, mint a specifikáció olvasása. ## Források 1. [Chrome for Developers: WebMCP (get started)](https://developer.chrome.com/docs/ai/webmcp) 2. [Chrome for Developers: Imperative API](https://developer.chrome.com/docs/ai/webmcp/imperative-api) 3. [Chrome for Developers: Declarative API](https://developer.chrome.com/docs/ai/webmcp/declarative-api) 4. [Chrome for Developers: WebMCP versus MCP](https://developer.chrome.com/docs/ai/webmcp/compare-mcp) 5. [Chrome for Developers: WebMCP tool security](https://developer.chrome.com/docs/ai/webmcp/secure-tools) 6. [Chrome for Developers: Build effective tools](https://developer.chrome.com/docs/ai/webmcp/build-tools) 7. [WebMCP explainer and specification draft](https://github.com/webmachinelearning/webmcp) 8. [WebMCP implementation status](https://github.com/webmachinelearning/webmcp/blob/main/implementation-status.md) ## Gyakori kérdések Mi a WebMCP? A WebMCP javasolt webes szabvány, amely lehetővé teszi, hogy egy oldal tipizált, hívható eszközöket adjon át a böngészőben futó KI-ügynöknek. Az oldal regisztrál egy nevet, egy természetes nyelvű leírást, egy JSON sémát a bemenetre és egy execute függvényt, a böngésző pedig közvetíti az ügynök és a függvény közötti hívásokat. Az eszközök csak addig élnek, amíg a nyitott lap megvan. A WebMCP az MCP helyettesítője? Nem. A Chrome saját összehasonlító oldala mindkettőt partnernek tekinti, nem riválisnak: az MCP tartósan, bármely kliensnek ad backend képességeket, a WebMCP pedig efemeren adja egy oldal élő állapotát a böngészőbe integrált ügynöknek. A legtöbb éles rendszernél mindkettő megjelenik: MCP az üzleti logikára, WebMCP a felhasználó előtti felületre. Kell a Chrome origin trial a helyi WebMCP-használathoz? Nem. Helyi fejlesztéshez a chrome://flags/#enable-webmcp-testing jelzőkapcsoló token nélkül is bekapcsolja. Valódi felhasználóknak Chrome 149-től felfelé regisztrálni kell az origin trialba, az Edge 150 pedig külön trialt futtat, saját regisztrációval. Mi a legnagyobb korlát ma? A böngészőtámogatás, majd a felfedezhetőség. A specifikáció repository implementációs állapotfájlja Chrome- és Edge-origin trialokat, kísérleti támogatást a Brave Leo chatben és támogatást a ChatGPT Desktopban sorol fel, Firefoxban vagy Safariban viszont nincs szállított implementáció. Ehhez hozzájárul, hogy az API nem headless böngészős munkára készült, és a kliens csak egy látogatással tudja meg, hogy egy oldalnak vannak eszközei. Írta: Csorba Balázs Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket. [AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about) ## További cikkek - [Schema.org strukturált adatok B2B webshopokhoz: bejelentkezés mögötti árak, egységek és változatok](https://balazscsorba.com/hu/blog/schema-org-structured-data-b2b-shop) - [AI-asszisztens a B2B webshop ügyfélszolgálatához: eszközök, jogosultságok és átadás embernek](https://balazscsorba.com/hu/blog/ai-assistant-b2b-shop-customer-support) - [AI-csevegő UI Vue-ban és Nuxtban: akadálymentes streaming](https://balazscsorba.com/hu/blog/vue-ai-chat-ui-streaming-accessibility) - [LLM-fordítási pipeline i18n-hez: glosszárium, helyőrzők és review](https://balazscsorba.com/hu/blog/llm-translation-pipeline-i18n) ## Pont erre van szükséged? Írj a projektedről vagy a pozícióról – szívesen hallok felőled. [Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)