Google Chrome levert WebMCP in een vroege preview, waardoor elke website een gestructureerde tool voor AI-agents wordt

Wanneer een AI-agent een website bezoekt, is het in wezen een toerist die de lokale taal niet spreekt. Of ze nu zijn gebouwd op LangChain, Claude Code of het steeds populairder wordende OpenClaw-framework, agenten hoeven alleen maar te raden welke knoppen ze moeten indrukken: kopieer onbewerkte HTML, voer schermafbeeldingen uit naar een multimodaal model en blader door duizenden tokens om erachter te komen waar de zoekbalk is.

Dat tijdperk loopt mogelijk ten einde. Eerder deze week werd het Google Chrome-team gelanceerd WebMCP — Web Model Context Protocol — als een vroege preview in Chrome 146 Canary. WebMCP, dat mede is ontwikkeld door ingenieurs van Google en Microsoft en is geïncubeerd via het W3C Web Machine Learning-gemeenschapsgroepis een voorgestelde webstandaard waarmee elke website gestructureerde, opvraagbare tools rechtstreeks aan AI-agenten kan tonen via een nieuwe browser-API: navigator.modelContext.

De gevolgen voor bedrijfs-IT zijn aanzienlijk. In plaats van afzonderlijke back-end MCP-servers in Python of Node.js te bouwen en te onderhouden om hun webapplicaties met AI-platforms te verbinden, kunnen ontwikkelingsteams nu bestaande JavaScript-logica aan de clientzijde combineren tot door agenten leesbare tools – zonder ook maar één pagina opnieuw te hoeven ontwerpen.

AI-agenten zijn dure en kwetsbare toeristen op internet

De kosten- en betrouwbaarheidsproblemen met de hedendaagse interactiebenaderingen van webagents (browseragents) worden goed begrepen door iedereen die deze op grote schaal heeft geïmplementeerd. De twee dominante methoden – visuele screen-scraping en DOM-parsing – lijden beide onder fundamentele inefficiënties die rechtstreeks van invloed zijn op de bedrijfsbudgetten.

Met een op screenshots gebaseerde aanpak geven agenten afbeeldingen door aan een multimodaal model (zoals Claude en Gemini) en hopen dat het model niet alleen kan identificeren wat er op het scherm staat, maar ook de locatie van knoppen, formuliervelden en interactieve elementen. Elke afbeelding gebruikt duizenden tokens en kan lange latenties hebben. Met een op DOM gebaseerde aanpak nemen agenten onbewerkte HTML en JavaScript op: vreemde talen vol tags, CSS-regels en structurele markup die niet relevant zijn voor de taak die moet worden uitgevoerd, maar nog steeds contextvensterruimte en gevolgtrekkingsoverhead in beslag nemen.

In beide gevallen vertaalt de agent tussen de ontwerpdoelen van de website (het menselijk oog) en de behoeften van het model (gestructureerde gegevens over beschikbare acties). Zoekopdrachten naar afzonderlijke producten die mensen binnen enkele seconden voltooien, vereisen tientallen opeenvolgende agentinteracties (klik op filters, scrollen door pagina’s, parseren van resultaten) en elk daarvan is een gevolgtrekking die de latentie en de kosten met zich meebrengt.

Hoe WebMCP werkt: twee API’s, één standaard

WebMCP stelt twee complementaire API’s voor die dienen als brug tussen websites en AI-agents.

Dat Declaratieve API verwerkt standaardacties die rechtstreeks in bestaande HTML-formulieren kunnen worden gedefinieerd. Voor organisaties waarvan de formulieren goed gestructureerd zijn en al in productie zijn, vereist dit pad weinig extra werk; Door een toolnaam en beschrijving toe te voegen aan de opmaak van een bestaand formulier, kunnen ontwikkelaars het formulier opvraagbaar maken voor agenten. Als uw HTML-formulieren schoon en goed gestructureerd zijn, bent u waarschijnlijk voor 80% aanwezig.

Dat Imperatieve API verwerkt meer complexe en dynamische interacties waarvoor JavaScript-uitvoering vereist is. Dit is waar ontwikkelaars rijkere toolschema’s definiëren – conceptueel vergelijkbaar met tooldefinities die naar OpenAI- of Anthropic API-eindpunten worden verzonden, maar die volledig aan de clientzijde in de browser worden uitgevoerd. Via registerTool() kunnen websites functies weergeven zoals searchProducts(query, filter) of orderPrints(copies, page_size) met volledige parameterschema’s en beschrijvingen in natuurlijke taal.

Het belangrijkste inzicht is dat één enkele tooloproep via WebMCP tientallen browserinteracties kan vervangen. E-commercesites die de tool searchProducts registreren, stellen agenten in staat een enkele gestructureerde functieaanroep te doen en gestructureerde JSON-resultaten te ontvangen, in plaats van dat agenten door vervolgkeuzelijsten met filters klikken, door gepagineerde resultaten bladeren en schermafbeeldingen van elke pagina maken.

De bedrijfscase: kosten, betrouwbaarheid en het einde van kwetsbare erosie

Voor IT-beslissers die de inzet van AI-agenten evalueren, pakt WebMCP drie hardnekkige problemen tegelijkertijd aan.

Kostenreductie is het meest direct meetbare voordeel. Door een reeks schermafbeeldingen, multimodale inferentieoproepen en iteratieve DOM-parsing te vervangen door een enkele gestructureerde tooloproep, kunnen organisaties verwachten dat ze het tokenverbruik aanzienlijk zullen verminderen.

Betrouwbaarheid verbetert omdat agenten niet langer hoeven te gissen naar de paginastructuur. Wanneer een website expliciet een toolcontract publiceert – “hier is de functie die ik ondersteun, hier zijn de parameters, hier zijn de resultaten” – opereert de agent met zekerheid, niet door gevolgtrekkingen. Interacties die mislukken als gevolg van wijzigingen in de gebruikersinterface, het dynamisch laden van inhoud of dubbelzinnige elementidentificatie worden grotendeels geëlimineerd voor elke interactie die door de genoemde tools wordt gedekt.

Ontwikkelingssnelheid versnellen omdat webteams bestaande front-end JavaScript kunnen gebruiken in plaats van een aparte backend-infrastructuur te bouwen. De specificatie benadrukt dat elke taak die een gebruiker via de gebruikersinterface van een pagina kan voltooien, tot een hulpmiddel kan worden gemaakt door een groot deel van de bestaande JavaScript-code van de pagina te hergebruiken. Teams hoeven geen nieuwe serverframeworks te leren of aparte API-oppervlakken te onderhouden voor agentconsumenten.

Man-in-the-loop is een ontwerp en geen bijzaak

Een belangrijke architectonische beslissing scheidt WebMCP van het volledig autonome agentenparadigma dat de recente krantenkoppen domineert. Deze standaard is expliciet ontworpen rond coöperatieve, door mensen betrokken workflows – en niet op automatisering zonder toezicht.

Volgens Khushal Sagar, software-ingenieur voor Chrome, identificeert de WebMCP-specificatie drie pijlers die ten grondslag liggen aan deze filosofie.

1. Context: Alle dataagenten moeten begrijpen wat gebruikers doen, inclusief inhoud die vaak niet zichtbaar is op het scherm.

2. Vaardigheid: Acties die een agent namens een gebruiker kan ondernemen, van het beantwoorden van vragen tot het invullen van formulieren.

3. Coördinatie: regelt de overdracht tussen de gebruiker en de agent wanneer de agent een situatie tegenkomt die niet zelfstandig kan worden opgelost.

Specschrijvers bij Google en Microsoft illustreren dit met een winkelscenario: een gebruiker genaamd Maya vraagt ​​haar AI-assistent om te helpen bij het vinden van een milieuvriendelijke jurk voor een bruiloft. De agent stelt een leverancier voor, opent een browser naar een kledingsite en ontdekt dat de pagina WebMCP-tools bevat, zoals getDresses() en showDresses(). Wanneer Maya’s criteria de basisfilters van de site overschrijden, roept de agent de tool aan om productgegevens op te halen, gebruikt zijn eigen redenering om te filteren op ‘geschikt voor cocktailkleding’ en roept vervolgens showDresses() aan om de pagina bij te werken met alleen relevante resultaten. Het is een huwelijk tussen menselijke smaak en de capaciteiten van agenten, precies het soort samenwerkend browsen waarvoor WebMCP is ontworpen.

Dit is geen standaard headless browsen. Dat specificaties worden expliciet vermeld dat een hoofdloos en volledig autonoom scenario niet het doel is. Voor dergelijke gebruiksscenario’s verwijzen de auteurs naar bestaande protocollen zoals het Agent-to-Agent (A2A)-protocol van Google. WebMCP gaat over de browser: de plek waar gebruikers aanwezig zijn, kijken en samenwerken.

Geen vervanging van MCP, maar een aanvulling

WebMCP is geen vervanging voor het Anthropic Model Context Protocol, ondanks zijn conceptuele afkomst en een deel van zijn naam. Het volgt niet de JSON-RPC-specificatie die MCP gebruikt voor client-server-communicatie. Terwijl MCP werkt als een back-endprotocol dat het AI-platform via een gehoste server met de serviceprovider verbindt, opereert WebMCP volledig client-side in de browser.

De relatie is complementair. Een reisorganisatie kan een back-end MCP-server onderhouden voor directe API-integratie met een AI-platform zoals ChatGPT of Claude, terwijl ze ook een WebMCP-tool op de website van de consument kunnen inzetten, zodat een browsergebaseerde agent kan communiceren met zijn boekingsstroom in de context van de actieve sessie van de gebruiker. De twee standaarden presenteren verschillende interactiepatronen zonder conflicten.

Dit onderscheid is belangrijk voor enterprise architecten. Back-end MCP-integratie is geschikt voor service-to-service-automatisering waarvoor geen browser-UI vereist is. WebMCP is geschikt wanneer gebruikers aanwezig zijn en hun interacties profiteren van een gedeelde visuele context – die de meerderheid van de consumentgerichte webinteracties vertegenwoordigt waar bedrijven om geven.

Wat er daarna gebeurde: van vlag naar standaard

WebMCP is momenteel beschikbaar in Chrome 146 Canary achter de vlag ‘WebMCP voor testen’ op chrome://flags. Ontwikkelaars kunnen zich aansluiten Chrome Early Preview-programma voor toegang tot documentatie en demo’s. Andere browsers hebben geen implementatietijdlijnen aangekondigd, hoewel Microsoft actief meewerkt aan de specificaties die de mogelijkheid van Edge-ondersteuning aangeven.

Waarnemers uit de branche verwachten dat er midden tot eind 2026 een officiële browseraankondiging zal plaatsvinden, met Google Cloud Next en Google I/O als mogelijke locaties voor een bredere uitrolaankondiging. De specificatie gaat over van gemeenschapsincubatie binnen het W3C naar formeel ontwerp – een proces dat historisch gezien maanden duurt, maar een teken is van serieuze institutionele betrokkenheid.

De vergelijking die Sagar maakt is leerzaam: WebMCP wil de USB-C zijn van AI-agentinteractie met het web. Eén enkele, gestandaardiseerde interface die door elke agent kan worden gebruikt en die de hedendaagse op maat gemaakte scrapingstrategieën en complexe automatiseringsscripts vervangt.

Het realiseren van die visie hangt af van de adoptie ervan – zowel door browserleveranciers als door webontwikkelaars. Maar nu Google en Microsoft gezamenlijk code leveren, het W3C de institutionele steigers levert en Chrome 146 al bezig is met de implementatie, heeft WebMCP de moeilijkste hindernis overwonnen waar elke webstandaard mee te maken heeft: van voorstel tot werkende software.