Wanneer een AI-agent een website 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 naar multimodale modellen sturen en duizenden tokens doorzoeken om erachter te komen waar een zoekbalk zich bevindt.
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 gezamenlijk is ontwikkeld door ingenieurs van Google en Microsoft en is geïncubeerd via de W3C’s 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 hun bestaande client-side JavaScript-logica omzetten 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 de interactie tussen webagenten (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 op screenshots gebaseerde benaderingen geven agenten afbeeldingen door 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 verbruikt duizenden tokens en kan een lange latentie hebben. Met op DOM gebaseerde benaderingen nemen agenten onbewerkte HTML en JavaScript op – een vreemde taal vol verschillende tags, CSS-regels en structurele opmaak die niet relevant is voor de uit te voeren taak, maar nog steeds contextvensterruimte en gevolgtrekkingskosten in beslag neemt.
In beide gevallen vertaalt de agent tussen waarvoor de website 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 gevolgtrekking die de latentie en de kosten verhoogt.
Hoe WebMCP werkt: twee API’s, één standaard
WebMCP stelt twee complementaire API’s voor die dienen 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 traject minimaal extra werk; Door toolnamen en beschrijvingen toe te voegen aan bestaande formulieropmaak kunnen ontwikkelaars deze formulieren opvraagbaar 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 browserinteracties kan vervangen. Op een e-commercesite die een searchProducts-tool registreert, kan de agent één 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 ondernemingscase: kosten, betrouwbaarheid en het einde van fragiel schrapen
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 inferentieoproepen en iteratieve DOM-parsing te vervangen door enkele gestructureerde toolaanroepen, kunnen organisaties een aanzienlijke vermindering van het tokenverbruik verwachten.
Betrouwbaarheid verbetert omdat agenten niet langer hoeven te gissen naar de paginastructuur. Wanneer een website expliciet een toolcontract publiceert (‘hier zijn de functies die ik ondersteun, hier zijn hun parameters, hier is wat ze retourneren’) – opereert 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 grotendeels 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 op te zetten. 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 voor agentconsumenten te onderhouden.
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 coöperatieve, mens-in-de-loop-workflows – en niet op ongecontroleerde 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.
-
Mogelijkheden: Acties die de agent namens de gebruiker kan ondernemen, van het beantwoorden van vragen tot het invullen van formulieren.
-
Coördinatie: Controle van 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 bevat, zoals getDresses() en showDresses(). Wanneer Maya’s criteria verder gaan dan de basisfilters van de site, roept de agent die 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 bij te werken met alleen de relevante resultaten. Het is een vloeiende cirkel van menselijke smaak en mogelijkheden van agenten, precies het soort samenwerkend browsen waarvoor WebMCP is ontworpen.
Dit is geen standaard voor browsen zonder hoofd. De specificatie vermeldt dit expliciet 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, meekijkt en samenwerkt.
Geen vervanging van MCP, maar een aanvulling
WebMCP is geen vervanging voor het Model Context Protocol van Anthropic, 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 binnen 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 implementeren op hun consumentgerichte website, zodat browsergebaseerde agenten kunnen communiceren met hun boekingsstroom in de context van de actieve sessie van een gebruiker. De twee standaarden dienen verschillende interactiepatronen zonder conflicten.
Het onderscheid is van belang voor enterprise architecten. Back-end MCP-integraties zijn geschikt voor service-to-service-automatisering waarbij 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 bij de Chrome Early Preview-programma voor toegang tot documentatie en demo’s. Andere browsers hebben nog geen implementatietijdlijnen aangekondigd, hoewel Microsoft’s actieve co-auteurschap van de specificatie suggereert dat Edge-ondersteuning waarschijnlijk is.
Waarnemers uit de branche verwachten halverwege tot eind 2026 formele browseraankondigingen, waarbij Google Cloud Next en Google I/O waarschijnlijke locaties zullen zijn voor bredere uitrolaankondigingen. De specificatie gaat over 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 getrokken is leerzaam: WebMCP wil de USB-C worden van AI-agentinteracties met het web. Eén enkele, gestandaardiseerde interface waarop elke agent kan aansluiten, ter vervanging van de huidige wirwar van op maat gemaakte scraping-strategieën en kwetsbare automatiseringsscripts.
Of die visie gerealiseerd wordt, hangt af van de acceptatie ervan – door zowel browserleveranciers als webontwikkelaars. Maar nu Google en Microsoft gezamenlijk code leveren, het W3C de institutionele steigers levert en Chrome 146 de implementatie al achter de hand heeft, heeft WebMCP de moeilijkste hindernis genomen waar elke webstandaard mee te maken heeft: van voorstel naar werkende software komen.
