Wanneer een AI-agent een site bezoekt, is het in wezen een toerist die de lokale taal niet spreekt. Of de agent nu is gebouwd op LangChain, Claude Code of het steeds populairder wordende OpenClaw-framework, de agent hoeft alleen maar te raden welke knoppen hij moet indrukken: ruwe HTML schrapen, schermafbeeldingen maken voor multimodale modellen en duizenden tokens doorzoeken om erachter te komen waar een zoekbalk zich bevindt.
Aan dat tijdperk komt mogelijk een einde. Eerder deze week lanceerde Google het Chrome-team WebMCP – Web Model Context Protocol – als een vroeg voorbeeld in Chrome 146 Canary. WebMCP, dat gezamenlijk is ontwikkeld door ingenieurs van Google en Microsoft en is geïncubeerd via de W3C’s Web Machine Learning-groepis 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 de IT van het bedrijf 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 hun bestaande JavaScript-logica aan de clientzijde verpakken in door agenten leesbare tools, zonder ook maar één pagina opnieuw te hoeven ontwerpen.
AI-agenten zijn dure, kwetsbare toeristen op internet
De kosten- en betrouwbaarheidsproblemen met de huidige benaderingen van webagent-interactie (browseragents) worden goed begrepen door iedereen die deze op 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 voeden agenten afbeeldingen aan multimodale modellen (zoals Claude en Gemini) en hopen ze dat het model niet alleen kan identificeren wat er op het scherm staat, maar ook waar knoppen, formuliervelden en interactieve elementen zich bevinden. Elke afbeelding gebruikt duizenden tokens en kan een lange latentie hebben. Met op DOM gebaseerde benaderingen gebruiken agenten onbewerkte HTML en JavaScript: een vreemde taal gevuld met verschillende tags, CSS-regels en structurele markeringen die niet relevant zijn voor de uit te voeren taak, maar nog steeds contextvensterruimte en gevolgtrekkingsoverhead in beslag nemen.
In beide gevallen vertaalt de agent tussen waar de website voor is ontworpen (menselijke ogen) en wat het model nodig heeft (gestructureerde gegevens over beschikbare acties). Voor één enkele productzoekopdracht die een mens binnen enkele seconden voltooit, kunnen tientallen opeenvolgende agentinteracties nodig zijn (het klikken op filters, het scrollen door pagina’s, het parseren van resultaten), elk een beëindigingsgesprek dat de latentie en de kosten verhoogt.
Hoe WebMCP werkt: twee API’s, één standaard
WebMCP stelt twee complementaire API’s voor die fungeren als brug tussen websites en AI-agents.
De Declaratieve API verwerkt standaardacties die rechtstreeks in bestaande HTML-formulieren kunnen worden gedefinieerd. Voor organisaties met goed gestructureerde formulieren die al in productie zijn, vereist dit pad minimaal extra werk; Door toolnamen en beschrijvingen toe te voegen aan bestaande formulieropmaak kunnen ontwikkelaars deze formulieren toegankelijk maken voor agenten. Als uw HTML-formulieren al schoon en goed gestructureerd zijn, bent u waarschijnlijk al voor 80% op weg.
De Imperatieve API verwerkt complexere, dynamische interacties waarvoor JavaScript-uitvoering vereist is. Dit is waar ontwikkelaars rijkere toolschema’s definiëren – conceptueel vergelijkbaar met de tooldefinities die naar de OpenAI- of Anthropic API-eindpunten worden verzonden, maar die volledig aan de clientzijde in de browser worden uitgevoerd. Via registerTool() kan een website functies zoals searchProducts(query, filters) of orderPrints(copies, page_size) weergeven met volledige parameterschema’s en beschrijvingen in natuurlijke taal.
Het belangrijkste inzicht is dat één enkele toolaanroep via WebMCP tientallen browsergebruiksinteracties kan vervangen. Op een eCommerce-site die een searchProduct-tool registreert, kan de agent een gestructureerde functieaanroep doen en gestructureerde JSON-resultaten ontvangen, in plaats van dat de agent door filterkeuzemenu’s moet klikken, door gepagineerde resultaten moet scrollen en van elke pagina een screenshot moet maken.
De Enterprise Case: kosten, betrouwbaarheid en het einde van fragiele scraping
Voor IT-beslissers die agentische AI-implementaties evalueren, pakt WebMCP tegelijkertijd drie hardnekkige pijnpunten aan.
Kostenreductie is het meest direct kwantificeerbare voordeel. Door reeksen schermafbeeldingen, multimodale afsluitingsoproepen en iteratieve DOM-parsing te vervangen door eenvoudig gestructureerde tooloproepen, kunnen organisaties een aanzienlijke vermindering van het tokenverbruik verwachten.
Betrouwbaarheid verbetert omdat agenten niet langer hoeven te gissen naar de paginastructuur. Wanneer een site expliciet een toolcontract publiceert (‘hier zijn de functies die ik ondersteun, hier zijn hun parameters, hier zijn wat ze retourneren’) – werkt de agent met zekerheid in plaats van met gevolgtrekkingen. Mislukte interacties als gevolg van wijzigingen in de gebruikersinterface, het dynamisch laden van inhoud of dubbelzinnige elementidentificatie worden vrijwel geëlimineerd voor elke interactie die wordt gedekt door een geregistreerde tool.
Ontwikkelingssnelheid versnelt omdat webteams hun 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 uitvoeren, 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.
Human-in-the-loop door ontwerp, geen bijzaak
Een kritische architectonische beslissing scheidt WebMCP van het volledig autonome agent-paradigma dat de recente krantenkoppen domineert. De standaard is expliciet ontworpen rond collaboratieve, menselijke workflows – en niet op onbeheerde automatisering.
Volgens Khushal Sagar, een software-ingenieur voor Chrome, identificeert de WebMCP-specificatie drie pijlers die deze filosofie ondersteunen.
-
Context: Alle dataagenten moeten begrijpen wat de gebruiker doet, inclusief inhoud die momenteel vaak niet zichtbaar is op het scherm.
-
Vaardigheden: Acties die de agent namens de gebruiker kan uitvoeren, van het beantwoorden van vragen tot het invullen van formulieren.
-
Coördinatie: regelt de overdracht tussen gebruiker en agent wanneer de agent situaties tegenkomt die hij niet autonoom kan oplossen.
De auteurs van de specificatie 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 leveranciers voor, opent een browser naar een kledingsite en ontdekt dat de pagina WebMCP-tools zoals getDresses() en showDresses() bevat. Wanneer Maya’s criteria verder gaan dan de basisfilters van de site, roept de agent deze tools aan om productgegevens op te halen, gebruikt hij zijn eigen redenering om te filteren op ‘geschikte cocktailkleding’ en roept vervolgens showDresses() aan om de pagina te vernieuwen met alleen de relevante resultaten. Het is een vloeiende cirkel van menselijke smaak en keuzevrijheid, precies het soort samenwerkend browsen waarvoor WebMCP is ontworpen.
Dit is geen standaard voor browsen zonder hoofd. De de specificatie vermeldt dit uitdrukkelijk dat hoofdloze en volledig autonome scenario’s geen doelen zijn. Voor deze gebruiksscenario’s verwijzen de auteurs naar bestaande protocollen zoals het Agent-to-Agent (A2A)-protocol van Google. WebMCP gaat over de browser – waar de gebruiker aanwezig is, ziet en samenwerkt.
Geen vervanging voor MCP, maar een aanvulling
WebMCP is geen vervanging voor het Anthropics Model Context Protocol, ondanks dat het een conceptuele afstamming en een deel van de naam deelt. Het volgt niet de JSON-RPC-specificatie die MCP gebruikt voor client-server-communicatie. Waar MCP werkt als een back-endprotocol dat AI-platforms verbindt met serviceproviders via gehoste servers, werkt WebMCP volledig aan de clientzijde van de browser.
De relatie is complementair. Een reisorganisatie kan een back-end MCP-server onderhouden voor directe API-integraties met AI-platforms zoals ChatGPT of Claude, terwijl ze tegelijkertijd WebMCP-tools op hun consumentgerichte website kunnen inzetten, zodat browsergebaseerde agenten kunnen communiceren met de boekingsstroom in de context van de actieve sessie van een gebruiker. De twee standaarden dienen verschillende interactiepatronen zonder conflicten.
Het onderscheid is belangrijk voor enterprise architecten. Back-end MCP-integraties zijn geschikt voor service-to-service-automatisering waarbij er geen browser-UI nodig is. WebMCP is geschikt wanneer de gebruiker aanwezig is en de interactie profiteert van een gedeelde visuele context, die de meerderheid van de consumentgerichte webinteracties beschrijft waar bedrijven om geven.
Wat daarna komt: van vlag tot 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 moeten de implementatietijdlijnen nog bekendmaken, hoewel Microsoft’s actieve co-auteurschap van de specificatie suggereert dat Edge-ondersteuning waarschijnlijk is.
Waarnemers uit de branche verwachten medio tot eind 2026 formele browseraankondigingen, met Google Cloud Next en Google I/O als mogelijke locaties voor bredere uitrolaankondigingen. De specificatie verschuift van gemeenschapsincubatie binnen het W3C naar een formeel ontwerp – een proces dat historisch gezien maanden in beslag neemt, maar een teken is van serieuze institutionele betrokkenheid.
De vergelijking die Sagar heeft gemaakt is leerzaam: WebMCP wil USB-C worden voor AI-agentinteracties met het internet. Eén enkele, gestandaardiseerde interface waarmee elke agent verbinding kan maken, vervangt de huidige wirwar aan aangepaste scrapingstrategieën en kwetsbare automatiseringsscripts.
Of deze visie gerealiseerd wordt, hangt af van de adoptie door zowel browserleveranciers als webontwikkelaars. Maar nu Google en Microsoft gezamenlijk code indienen, het W3C de institutionele steigers levert en Chrome 146 de implementatie al achter de rug heeft, heeft WebMCP de moeilijkste hindernis genomen waar elke webstandaard mee te maken heeft: van voorstellen naar werkende software komen.
