WebMCP: a láthatatlan internet új nyelve
A WebMCP miatt a webes termékeket már nemcsak embereknek, hanem AI-ágenseknek is olvashatóvá kell tervezni.
WebMCP: a láthatatlan internet új nyelve
A webet embereknek terveztük. Szemnek, kéznek, egérnek, érintésnek.
Gombok, menük, naptár widgetek, kosárfolyamatok, checkout lépések: minden abból indul ki, hogy valaki ránéz a felületre, megérti, majd interakcióba lép vele: kattint, görget, gépel.
Az AI-ágensek viszont nem így használják a webet. Ők nem „látják” a terméket úgy, ahogy mi. DOM-ot olvasnak, HTML-t kaparnak, accessibility tree-t értelmeznek, néha képernyőképekből próbálják kitalálni, melyik gomb mire való, ez demózáskor látványos, de valódi termékben törékeny.
Ha átkerül egy gomb, megváltozik egy label, bekerül egy modal, vagy másképp tölt be a naptár, az AI Agent máris rosszabbul dönthet. És közben sokszor feleslegesen nagy mennyiségű oldaltartalmat kell feldolgoznia egy olyan művelethez, amit egy ember két kattintással elintézne.
Erre ad választ a WebMCP, vagyis a Chrome jelenlegi dokumentációja szerint a Web Model Context Protocol. Röviden: egy javasolt webes szabvány, amely lehetővé teszi, hogy a weboldalak ne csak vizuális felületként, hanem gépileg olvasható képességcsomagként is megmutassák magukat az AI-ágenseknek.
Nem jobb kattintás kell, hanem jobb nyelv
Vegyünk egy repülőjegy-keresőt: WebMCP nélkül az AI Agentnek meg kell találnia az indulási mezőt, be kell írnia a várost, át kell lépnie az érkezési mezőre, meg kell küzdenie a naptár komponenssel, utasszámot és utastípust kell választania, majd meg kell nyomnia a keresés gombot.
WebMCP-vel a weboldal felkínálhat egy strukturált toolt:
searchFlights(origin, destination, date, passenger_number, passenger_type)
Ez nem apró technikai kényelmi funkció. Ez nyelvváltás.
Az ágensnek nem kell találgatnia, hogy a felületen mi történik. Látja, milyen művelet érhető el, milyen inputot vár, és milyen állapotban van az oldal.
A jövő weboldalainak ezért két rétege lesz:
- egy vizuális UI az emberi felhasználóknak,
- és egy ún. szemantikai interfész az AI Agenteknek.
Fontos: a WebMCP nem azt jelenti, hogy a humán felület eltűnik, hanem inkább azt, hogy a felület mellé kerül egy másik, strukturált réteg. A Chrome és a W3C explainer alapján a cél az, hogy az ágens a böngészőben, a felhasználó kontextusában, látható és kontrollálható módon tudjon együttműködni a weboldallal.
Ez különbözik a klasszikus backend MCP-integrációktól. Ott az agent gyakran a webes felületet megkerülve beszél a szolgáltatás backendjével. A WebMCP kliensoldalon dolgozik: az aktuális oldalt, a böngésző-munkamenetet, a meglévő JavaScript-logikát és a felhasználó kontextusát használja.
A WebMCP lényege nem az, hogy az AI ügyesebben kattintson, hanem az, hogy a weboldalból végre ki tudja olvasni, hogy az mire képes.
UX mellé AX
UX-tervezőként eddig azt kérdeztük: mit lát, ért és tud megtenni a felhasználó? De most jön mellé egy másik kérdés: mit lát, ért és tud biztonságosan végrehajtani az AI agent?
Ezt hívhatjuk AX-nek, vagyis Agentic Experience-nek. De nem azért, mert kell még egy új rövidítés a falra, hanem mert tényleg másik tervezési problémáról beszélünk: az AX annak a megtervezése, hogyan tesszük olvashatóvá a termék képességeit gépi szereplők számára.
Product és UX oldalon ez nagyon konkrét döntéseket jelent:
- mely műveleteket érdemes toolként kitenni,
- melyikhez kell emberi jóváhagyás,
- milyen kontextust kapjon az ágens,
- hogyan nézzen ki egy gép számára is hasznos hibaüzenet,
- mikor legyen egy művelet elérhető, és mikor ne.
A WebMCP két fő utat ad ehhez:
Az egyik a deklaratív API. Itt meglévő HTML formokat lehet olyan attribútumokkal kiegészíteni, amelyekből a böngésző toolt tud előállítani. Ez jó belépő keresőkhöz, jelentkezési űrlapokhoz, egyszerűbb szűrőkhöz, support-folyamatokhoz.
A másik az imperatív API, ahol JavaScriptből regisztrálunk toolokat, például
document.modelContext.registerTool()segítségével. Ez több munka, de több kontrollt is ad. Egycheckouttool például csak akkor legyen látható az ágensnek, ha tényleg van valami a kosárban.
Ez a next level UX-es gondolkodás, csak most nem vizuális hierarchiát tervezünk, hanem cselekvési hierarchiát.
A hatékonyság itt nem elméleti érv
A WebMCP melletti legerősebb érv, hogy sokkal kevesebb találgatásra ad okot az AI agent számára.
Egy 2025-ös webMCP-kutatás 1 890 API-híváson keresztül vizsgálta az agent-ready webes interakciókat online vásárlási, autentikációs és tartalomkezelési folyamatokban. A tanulmány szerint a strukturált interakciós réteg átlagosan 67,6%-kal csökkentette a feldolgozási igényt, miközben a feladatvégzés minősége magas maradt. A mért költségcsökkenés a forgatókönyvtől függően 34-63% között mozgott.
Ezeket a számokat nem érdemes minden termékre egy az egyben ráhúzni, de a minta mégis elég beszédes.
Ha az ágensnek nem kell az egész oldalt értelmeznie, hanem célzott, jól leírt műveleteket kap, gyorsabban dönt, kevesebb tokent használ, és kisebb eséllyel téved el. Terméktervezési szempontból ez nem egy technikai lábjegyzet: ez kőkeményen hat a konverzióra, csökkenti a support-költség, megteremti a megbízhatóság érzését és egy jó márkaélménnyel jár.
Egy AI agent nem fogja értékelni, hogy a második modalban milyen szép a szövegezés, ha közben nem tudja, melyik művelet állapotváltoztató, melyik csak információt kér le, és mikor kell megállnia jóváhagyásért.
A rossz UX hamarosan rossz AX is lesz.
A láthatatlan interfész is támadható
Minél több műveletet adunk át az AI agenteknek, annál kevésbé lehet a biztonság megtervezését a végére hagyni, itt nem elég annyi, hogy „majd a modell eldönti”, mert nem fogja mindig jól eldönteni.
A Chrome WebMCP security guidance külön ír az indirekt prompt injection kockázatáról. Az LLM-ek a szöveget, az utasításokat és a felhasználói adatokat egy tokenfolyamként kezelik, ezért egy rosszindulatú tartalom képes félrevezetni az agentet.
Egy 2026 júniusában publikált kutatás ennél konkrétabb WebMCP-kockázatot is leír: a Mid-Session Tool Injection jelenséget. Ebben a támadási modellben egy harmadik féltől származó script, például egy kompromittált SDK, a munkamenet közben módosíthatja vagy félrekeretezheti az agent által látott toolokat.
Két támadási minta különösen fontos:
- Tool Hijacking: a látható toolkészlet manipulálása.
- Tool Framing: a tool nevének, leírásának vagy metadata mezőinek torzítása.
Ez utóbbi az igazán érdekes tervezői szemmel. Egy tool descriptionből érti meg az AI Agent, mire való a művelet. Ha ezt valaki manipulálni tudja, akkor maga az agentic interface válik támadási felületté.
AX-ben a tool description olyan, mint UI-ban a gombfelirat. Csak itt nem egy ember dönt belőle, hanem egy AI Agent.
Guardrail nélkül nincs agent-ready termék
A WebMCP-ben ezért a guardrail a termék része és nem egy választható feltét.
A Chrome irányelvei például javasolják a readOnlyHint és az untrustedContentHint használatát. Az előbbi jelzi, ha egy tool nem változtat állapotot. Az utóbbi akkor fontos, ha a tool külső vagy felhasználók által generált tartalmat ad vissza, például kommenteket, review-kat vagy piactéri leírásokat.
Kicsi mezőknek tűnnek, de sokat számítanak. Azt mondják az Agentnek: ezt olvashatod, de kezeld óvatosan; ezt végrehajthatod kisebb kockázattal; itt kérj embertől megerősítést.
A WebMCP emellett origin isolation és permissions policy követelményekkel is dolgozik. Vagyis nem mindegy, milyen eredetű kód, milyen iframe-ből, milyen jogosultsággal regisztrálhat vagy érhet el toolokat.
Egy agent-ready terméknél ezért az az igazán fontos, hogy:
- az ágens pontosan mit láthat,
- mit hívhat meg,
- mikor kell megállnia,
- hogyan különböztetjük meg a megbízható és nem megbízható tartalmat,
- hogyan naplózzuk a tool-hívásokat,
- hogyan akadályozzuk meg, hogy harmadik féltől származó kód átírja a jelentést.
Ez fejlesztési kérdés is, de a termék AI governance nélkül félkarú lesz.
A terméked képességcsomag lesz
Egy digitális termék 2026-ban már nem weboldalakból áll, hanem képességekből:
Keresés. Szűrés. Ajánlás. Vásárlás. Időpontfoglalás. Dokumentumfeltöltés. Jogosultságkezelés. Hibakeresés. Visszatérítés.
Eddig ezeket főleg UI-elemek mögé rejtettük, a felhasználó megtanulta (lehetőleg könnyen), hol vannak és hogyan használja őket. Az AI agent viszont nem akar minden weboldalt emberként újratanulni.
A WebMCP arra kényszerít (és ez jó), hogy a termék valódi műveleteit tisztán megnevezzük.
Ez kényelmetlen, mert láthatóvá teszi a termék belső logikáját, de pont ezért hasznos. Ha nem tudod megmondani, milyen toolokat adna a terméked egy Agentnek, valószínűleg az emberi UX-ben is van zaj (és baj):
Készen áll a terméked arra, hogy az emberek mellett az AI Agentek legyenek ugyanolyan fontos felhasználói?
Mert ha a web egyre nagyobb részét algoritmusok olvassák, értelmezik és működtetik helyettünk, akkor a gépek számára olvashatatlan termék üzletileg is egyre nehezebben lesz látható. Nem azért, mert eltűnik, csak az új, láthatatlan interfészen nem mond semmit.
Források
További írások az archívumból
Open Knowledge Format: az AI-agentek közös nyelve
Az OKF azt mutatja meg, miért nem elég az erősebb modell: az AI-agenteknek közös, hordozható kontextus kell.
Miért nem éri utol az AI Agent az emberi teknőst?
Az AI Agent gyors, de a valódi munka célból, kontextusból, ítéletből és felelősségből áll. Ez továbbra is emberi szerep.
Ehhez a gondolathoz kapcsolódó projektek
Raiffeisen Bank: End-to-End Online Account Opening
Raiffeisen Bank: End to End Online Account Opening When Raiffeisen Bank decided to let customers open a bank account entirely online — no branch visit required — they kne…
Open Brain: Building a Personal Knowledge Backend with AI
Open Brain: Building a Personal Knowledge Backend with AI What if your notes could think? Not in a sci fi way — but in a practical, "I wrote something three months ago th…